Why your ITSM Tool is the wrong Choice for cloud-native Cloud Management

By Christina Kraus18. March 2020

ITSM tools have been used by large enterprises for ordering and workflow processes for a long time. They provide an easy way to order phones, monitors and other IT gadgets that could make an employee happy.

Providing Azure Subscriptions or AWS Accounts within your ITSM Tool

As cloud has become a new and common IT resource, it may be an obvious solution to use an existing ITSM tool to order specific cloud resources or entire cloud tenants.

A central IT service portal has the benefit that it consolidates all offered services that are used across the organization in a single place. Every employee knows that it exists and will probably use it as a first access point when it comes to IT requirements.

However, this general applicability is also its weakness, looking at highly specific services like cloud tenants. The cloud has much more complexity than a phone or a monitor. Here are just a couple of examples why:

  • Access and Permission Management: The user circle of a cloud project will change and evolve over time (new team members, team members leaving the company).
  • Cloud providers have heterogeneous organizational models. For example you have Management Groups in Azure and Service Control Policies in AWS. Both of these concepts can be used to group accounts within the organization and apply certain security guardrails to them.
  • Cloud projects have a dynamic lifecycle. Not only users and resources change over time, governance guardrails may have to be updated eventually, which can require reconfiguration of accounts for example.

So while a workflow automation as provided by ITSM tools may help when it comes to the initial cloud tenant provisioning, it will hardly be able to cope with the complexity and required cloud governance that a large scale use of cloud by DevOps teams requires.

Building a Cloud Management Platform for Cloud Resources

Due to this complexity of cloud infrastructure, a continuously evolving cloud service offer and organizational implications resulting from the use of cloud (DevOps teams), the product category of cloud management platforms has evolved.

And it certainly makes sense to address cloud complexity with a tool that has been built for this specific purpose, which is what we at meshcloud do with our platform. Our tool enables organizations to be cloud-native. While we provide a framework for cloud governance, DevOps teams are able to use the native cloud tooling they are used to – no barriers, no abstractions. It’s the organizational structure that we take care of: IAM integrations, cloud access management, tenant creation, policies and billing, not the workload.

But there is another aspect that should be considered:

This may sound a bit dramatic, but a lot of central IT departments have lost trust by their (internal) customers (DevOps teams) due to a lack of process adoption. They are associated with slow enterprise processes, legacy tooling and security restrictions that don’t allow for any fun tech experiments or technological freedom.

This image problem brings IT departments into a difficult position to launch a new and isolated tool for cloud management. In order to gain back trust by the DevOps teams, they would have to market it internally to raise awareness ensure its adoption.

Therefore, it often makes sense to use an existing IT service portal as a central entry point to the (mesh)cloud world to increase the discoverability and avoid parallel activities in this field. Furthermore, there may be adjacent service offers, that better fit into such a service portal.

So, how to combine your IT Service Portal with a new Cloud Management Platform?

The central IT service portal stays the central access point for all IT services. However, you will not directly order cloud services like AWS accounts, Azure subscriptions or GCP projects within this portal. Instead, you will use it to get access to a cloud-native cloud management.

In the case of meshcloud as a cloud-native multi-cloud management tool, this process looks as follows:

Let’s say you are DevOps team lead Theresa and you need to get cloud access for your DevOps team to develop this cool new application that runs in the cloud.

1) The central service portal is the initial entry point. The DevOps team lead Theresa can access it to request cloud access. Instead of providing her with individual cloud services, she will get access to meshcloud, her entry ticket to the cloud.

2 + 3) In some cases organizations want to include some approval workflows, which is something that workflow tools do pretty well. For example, Theresa may need to get a budget approved before actually getting access to the cloud. Another use case we often face is that cloud access requires some consultancy services, security trainings or a “cloud license” when used for the first time. These aspects can be covered in these two steps.

4) Once Theresas access has been approved, the central IT service portal will trigger the creation of a meshcloud account with the provided metadata. This process can easily be automated via our meshcloud API.

5) Now, our DevOps lead Theresa can access meshcloud to manage the cloud environments for her application. This includes permissions for other team members as well as the creation of cloud tenants in the available cloud platforms. In order to be able to map her activities in the cloud to the resulting application, she can provide some metadata, like an application ID, a cost center, a responsible product owner or a data security classification for the application.

6) The tenant creation and configuration is an automated process.

7) As this is a cloud-native portal, the DevOps team will have direct access to the cloud native consoles to set up and automate their deployments.

8) Cost management and chargeback can be a pain when managing a large number of projects in the cloud. Costs have to be mapped to their causing applications. meshcloud takes care of this cost allocation even across multiple clouds and provides cost data to be processed in further controlling and chargeback systems.

What’s the Role of Central IT in this?

Right, we don’t see central IT in this picture, but this doesn’t mean they disappeared. So I want to spend the last words on common organizational structures we face in large enterprises. Within the central IT department, we often find a group of cloud experts (Enterprise Architects, Security and Governance, Platform Operators) – often called a cloud foundation. Their aim is to deliver secure cloud tenants to their internal customers (DevOps teams), to provide them with managed services like ELK stacks or databases and to assist them when it comes to security and compliance questions. meshcloud provides them with a tool, to do this in a consistent and scalable fashion.

To learn more about meshStack, please get in touch with our sales team or book a demo with one of our product experts. We’re looking forward to get in touch with you.