WE ENABLE CLOUD-NATIVE ORGANIZATIONS

tl;dr:

Don't build your own (multi-)cloud management platform. We all face limits in time and resources. Don't invest this time and resources into a solution that each of your competitors will have to build, too. Focus on your core competencies to build products your customers love and make a difference in today's competitive market environment.

The start of a cloud journey

cloud journey
Most organizations start off using a single cloud provider. They go for cloud to leverage the benefits in speed and scale those technologies provide: On-demand access to a large pool of resources, a large offer of stable services, waiting to be used in new innovative applications and finally a cost model that reflects the actual resource usage, rather than a big block of inflexible fixed costs.

You have to balance agility and control to use cloud in the enterprise


Unfortunately, in an enterprise world cloud cannot be integrated by pulling out the company credit card and registering for an AWS account (replace AWS by any other cloud provider of your choice). Instead, the new provider will be integrated into an existing process flow, regulations have to be respected, security guidelines followed, considerations on alternative providers will be carried out and possible exit strategies evaluated. And all this is right: The gain in agility and speed has to be balanced with more control or (for those who don't like this word) transparency on responsibilities.

Silos, fragments and growing pains

Cloud Silos
A lot of companies initially choose to build this integration of new technologies into the existing organization themselves. This may work well in the beginning, while the number of users and projects is small, only one platform has to be integrated and the cloud is mainly used by experienced cloud-native developers and before the first compliance audits are done. At scale, such efforts can easily result in chaos and intransparancy (Have a look at our cloud maturity model to learn more on the different stages of multi-cloud management).

One of the reasons this happens is that there is neither a comprehensive strategy behind the activities nor a central team accountable for the result. The solution mainly emerges from bits and pieces needed on the way that result in heterogeneous cloud silos (Isn’t this how we started?).

  • Each cloud platform will follow its own process. Teams implementing the integration will do duplicate work. And teams that are new to cloud may have a hard time to get started as they won't know how and where.

  • Only parts of cloud management will be covered, wherever the pain is most pressing: e.g. IAM integration, provisioning of cloud tenants, configuration of cloud tenants, billing. Mostly the former ones, as this is where the journey starts.

  • In the end the use of cloud is part of a comprehensive IT strategy. However, its effectiveness can only be evaluated, if I actually get an overview on the acceptance of the new technologies, the resources running in different clouds, the type of services required by my teams, etc.

  • There are some processes there, that will help me at first but

    • are they documented and resilient to withstand audits or regulative requirements?
    • are they really cloud-native, e.g. resulting in a time-to-cloud of seconds or minutes?

Why it doesn't make sense to build your own cloud management tool

Apart from the result being different than what you expected and a high probability that you'll find yourself starting all over again, trying to integrate the partial and provisional solutions to a comprehensive view of your (multi-)cloud environment, there are a couple of reasons, why it doesn't make sense to build your own multi-cloud management tool in the first place.
Cloud Management Make or Buy

1) Time is against you

Building your own tool for multi-cloud management will take too much time. Planning the project, finding the required resources or building up specific cloud know-how and implementing it, will take some time, even if you are fast and have unlimited monetary resources. You don't have this time and most probably you also don't have unlimited resources.

No matter what industry you are in, you are probably facing a strong competition. Traditional industries like banks or automotive companies in particular have to fight for their markets, have to reinvent themselves and use their competitive advantage (extensive know-how, a large customer base, a known brand and a large amount of data to work with) to stay in the game.

The competition is strong and won't wait for you. And in regard to IT, you start in unfair conditions. While new players in the market can start building their business from scratch and in a cloud-native manner, you are carrying a heavy backpack of legacy infrastructure and processes.

To keep up, it's not enough to make your existing processes a bit better, you'll have to build new cloud-native processes.

2) Developers are hard to find

Finding qualified IT specialists is tough and probably one of the biggest challenges every kind of organization small or large faces nowadays. To build a multi-cloud management platform you'll need platform experts for the cloud platforms that you aim to use. As this hasn't been your focus so far, you'll be looking to hire those and they are even harder to find than regular software engineers.

Of course you could access external resources that have the skills and know-how to help you out faster. However, they are expensive and more importantly they are not sustainable. Building a cloud management tool is not a one-off project. Working with cloud resources is more complex than ordering physical servers, a phone or a monitor. Everything you deal with in the cloud has a lifecycle: users, cloud projects, permissions, certifications and so on and your tool will have to take care of it. This requires continuous governance and transparency on the state of your multi-cloud environment.

Furthermore, the cloud-native ecosystem is incredibly dynamic. Requirements for cloud management and governance evolve over time, new platforms pop-up on the market, new regulations will be defined and you'll have to comply.

These circumstances scream for a software service that comes with updates and adapts to a fastly changing environment as we face it here.

3) You have a business to run

We've figured out that time and resources are limited for all of us. But there is another point that shouldn't be neglected in a make-or-buy assessment. And that is something you definitely learn as an entrepreneur, but which is true for organizations of any size: With limited time and resources, you have to focus on your core competencies.

And these are most probably not multi-cloud integration and governance best-practices (for us they are), but rather products and services in your industry. Invest your resources in activities that create value for your customers. Work on innovation and new business models that will help you to make a difference on the market.

If your customers are IT teams, take them on the cloud journey and provide them with the tools they need to deliver software faster. It is your job to make it fun to use the cloud, to attract new talent because of the freedom and possibilities IT teams experience in your company.

Having a tool in place that takes care of the basics, will relieve you from being a bottleneck and allow you to focus on the specifics of your organization: Which services you want to offer, how to get cloud-newbies on board, architectures for newly build applications, security and network configurations for your specific setup, providing insights for better stability or investment decisions.

About meshcloud

meshcloud helps organizations leverage cloud technology in a cloud-native way. Our platform provides consistent governance with cross-platform Identity and Access Management, Tenant Management, Compliance & Security and Cost Governance. Large enterprises use meshcloud to deliver cloud environments to thousands of teams while staying in control and reducing complexity.

Please reach out to us for further information. Our team is more than happy to give you a free introduction to our platform.

Cloud means Multi-Cloud

The cloud is the foundation of an efficient IT operation in the digital age. More often than not, one cloud platform is not sufficient for at least two reasons: 1) Different cloud platforms service different purposes and each has specific strengths and weaknesses hence embracing the plurality of platforms in a best-of-bread manner is more productive than trying to fight it. And 2) To avoid a technology lock-in on one vendor or platform, creating a diverse skill set preserves technical sovereignty.
Therefore, building a proper multi-cloud management capability is key to a successful and efficient cloud strategy. To give some guidance about the technical approaches to build such a capability, we introduce the meshcloud multi-cloud management maturity model.

Multi-Cloud Maturity

The meshcloud multi-cloud managemenet maturity model

Stage 0: No Multi-Cloud Management ?

The first stage is easy to reach – it is the natural stage when you do not take any actions, maybe because you do not realize you have a multi-cloud challenge to solve. However, the effects rise nevertheless.
Due to disorientation of users individual platform or ad-hoc processes will be established and you end up with a silo-structured organization loaded with unnecessary complexity due to different access routines for different platforms.
But that is not necessarily the greatest worry: people tend to shortcut complexity and lengthy processes and public cloud vendors make it way to easy to access cloud resources within minutes with the simple (yet virtual) swipe of a company credit card. The nightmare has a name: Shadow IT! You end up with individual, unconnected, unregistered public cloud accounts the company pays for but has no efficient way to manage. All comes down to individual initiative and discipline which might go well, but it’s an anarchy and there is no way to ensure rules and regulations are followed and compliance is uphold. This has severe implications for security or regulatory duties, e.g. you cannot give full report about data processing activities as required by the GDPR. Accounts might be shared among colleagues. When people leave the company, no one guarantuees credentials are rotated. And so on.
Therefore, this stage is like purgatory – you suffer from sins of the past and want to get out as soon as possible. To receive remission, action is necessary.

Stage 1: Manual / Semi-automated Multi-Cloud Management ?

So we realize: let’s bring order to the chaos. We try to standardize, define common processes, keep track of tenants and workloads out there in the clouds or running within our own private cloud.
In Stage 1, we define a process to provision and configure tenants on the clouds we use. Someone is defined responsible for a certain platform, to keep security and governance up and to provide users with what they need to get their cloud projects up and running.
Regarding implementation, we move quick and take the tools we have and are familiar with: a ticketing system to order cloud tenants from the IT department which someone creates manually or provides manually or with some scripting on her or his own. What about controlling? Let’s keep track of cloud tenants in an Excel sheet or export a list of projects on a platform to see who’s doing what and how much of it.
It’s tedious and everyone hates it – those who want to use the cloud because there still different contacts for different clouds and because they have to wait so long to receive their credentials. And operators hate it because they are doing dull work and lots of it instead of improving processes and evaluating further advanced technologies.
The cloud is all about automation and the multi-cloud is, too! So this stage does not fulfill the promise of self-serving, on-demand, scaling capacities with a few key strokes, but falls behind the spirit that comes with cloud technologies: automate ALL THINGS.

Stage 2: Imperative / Workflow-based Multi-Cloud Management ?

With further investment, we reach stage 2 where we have reached the stage of integrated, automated processes to provision tenants and user accounts in all relevant cloud platforms. We might even have established a self-service where users are able to set up cloud projects 24/7 at their own pace and needs. There is a portal where they can order cloud projects or ressources and after a while they are ready to run.
So all good now? At first, it might be. But over time, workflows and tenant configurations evolve and after some months or years it becomes hard to tell which tenants were created and configured by which version of the process. Also, do people reliably remove resources when they are not needed anymore? And how are resources in different clouds connected and how do they depend on each other? Hopefully, the documentation is available and up to date – otherwise, we still lose orientation between platforms and projects consuming and possibly spanning them.
But what now?

Stage 3: Declarative Multi-Cloud Management ?

Meet declarative multi-cloud management! You already know the concept from the deployments of your workloads where it labels as infrastructure as code. You describe the desired target state and the system works it out for you. Declarative multi-cloud management means the same, but on an organizational, cross-platform level – Organization as Code as we framed it.
So you define which projects should exist on which platform and which users should have what kind of access. You save the new configuration in a versioned repository and after a short while the whole multi-cloud federation converges to the new state you described. The version control enables you to frantically audit every single change that happened to your multi-cloud landscape. This has several advantages:/li

  • Robustness: Distributed systems might suffer from weak network links which might cause process flows to stall and fail. However, with the target state clearly defined, the system can try again and again to finally reach the desired state.
  • Prevention of local changes: You know the “colleague is on vacation, but I need urgent access” situation which might lead to a quick and dirty permission to cloud projects by an administrator. More often than not, those changes stick longer than intended – the human lazyness is my witness. However, a declarative multi-cloud management system would roll back those changes at the next sync.
  • Decoupling of semantics and implementation logic: With a descriptive configuration you describe what you want, not how to do it. Therefore, flexibility remains with the system on how to implement reaching the desired state which means more freedom to improve the multi-cloud system over time.
  • Documentation and Auditing: If every configuration change is tracked in the manifest and version controlled, it is always easy to report, audit and track who had access to which system or data and how long, why and by whom.

You see that declarative multi-cloud management has many advantages – it’s for some reason the paradigm turned so successful with configuration management. Therefore, meshcloud put the declarative paradigm at the heart of its vision of an agile, but full-control multi-cloud management. If you want to learn more, we are happy to start the conversation with you.
Reach out to us via mail, social webs, phone or any events we attend. We are looking forward to hear your thoughts!