Cloud Management Platform: 10 Things to Consider When Choosing One
A Cloud Management Platform helps Cloud Centers of Excellence master the complexity of their multi-cloud environments by implementing governance and control mechanisms.
In this post we provide guidance and orientation for the evaluation of Cloud Management Platforms to help you make the right choice for your organization.
What is a Cloud Management Platform?
Coined as its own product category by Gartner, Cloud Management Platforms provided by vendors like meshcloud, CloudCheckR or Morpheus, have been the tool of choice for lots of organizations. A Cloud Management Platform helps control their cloud infrastructure landscape when cloud adoption increases.
Here are 10 criteria to consider when choosing a Cloud Management Platform:
(✅ 1) What is your intention of moving to the cloud?
There are different strategies that let organization leaders decide to move to the cloud. I’ll shortly describe the 2 extremes and how they can impact your choice of Cloud Management Platform.
- Empty Datacenter with Lift&Shift: High hardware and operations costs that aren’t flexible drive organizations to shut down their data centers and move workload to the cloud (no matter how). This is not much about innovation or speed, it’s a shift from CapEx to OpEx for more flexibility. What you will need from a Cloud Management Platform to achieve your goals is easy provisioning of commodity services: VMs, Networks and so on. Teams do not have (and need) in-depth cloud know-how. They just move from the actual datacenter to a virtual one.
- Accelerating with cloud-native development: For other organizations the main driver of cloud is speed. Accelerating development, collecting customer feedback and shortening release cycles for fast iterations are crucial. Teams have to adopt new ways of working (DevOps), leverage cloud-native practices like CI/CD or Infrastructure as Code and get familiar with the cloud providers’ services. A Cloud Management Platform should be almost invisible to developers that are working in this mode. It should help them get access to the cloud faster and support with standard setups for developers: Git repositories, CI/CD tooling etc. (Developer Toolchain). But once the initial setup is done, they should be free to access native cloud environments: AWS accounts, Azure subscriptions, GCP projects and choose the services they like.
Of course there are variations of these 2 strategies. And in some cases you might have to enable both as they are executed in parallel. So if your Cloud Management Platform supports both: Self-service provisioning of simple cloud services through a marketplace-like interface as well as native cloud environments and the access to them, you are on the safe side.
The alternative is to look for Cloud Management Platforms that provide DevOps teams with entire cloud environments like AWS accounts, Azure Subscriptions or GCP projects and leaving the choice of specific services within these platforms to the teams.
Download your Cloud Foundation Maturity Poster with over 50 capabilities covering everything you need from Security to a Service Ecosystem. Asses where you're at and plan your road map to cloud-success.
(✅ 2) What is the right level of abstraction for you?
This question is not new to cloud. Enterprise architects have been dealing with abstraction levels for decades, and it’s a key decision to take when looking at Cloud Management Platforms. So let’s have a look at the options.
There are 2 main approaches we see on the market:
- Abstraction on the resource level: When abstracting on the resource level, teams that have access to the Cloud Management Platform get offered different resource types, e.g. VMs, databases and so on. They choose what resource they need and can usually provision it in self-service via a self-service portal. Depending on the “depth” of the abstraction they will or will not be aware in which cloud the resource will be provisioned. This approach implies that every cloud service a developer wants to use has to be integrated into the Cloud Management Platform, either by the CMP vendor or your team. Especially, when expecting a scaling demand for cloud, this can make it hard to accommodate all the different use cases.
- Abstraction on the tenant level: In contrast to workload abstraction, abstracting on the tenant level means that the Cloud Management Platform provides the capability to provision native cloud tenants, e.g. AWS accounts, Azure subscriptions, GCP projects and so on, in self-service. The developers get the freedom to access these native cloud environments and choose their preferred cloud resources directly in the cloud. However, thanks to the tenant-level abstraction, they will not have to deal with different tenant provisioning processes for each cloud platform, figure out how they’ll get access to the environments, or how to extract costs. That will be handled homogeneously by the Cloud Management Platform to reduce complexity and lower organizational overhead.
(✅ 3) How important is vendor lock-in to you and your organization?
Vendor lock-in is one of the drivers of multi-cloud strategies. By having multiple providers in place you reduce the dependency you have on each individual provider and can easily define an exit strategy.
In reality this is a bit more complex:
If you abstract on the resource level, you can make sure that you only provide services that are available across multiple clouds, rather than proprietary and highly specialized services. This facilitates moving from one cloud to the other. However, in this case vendor lock-in to the Cloud Management Platform itself becomes a critical risk. Removing the CMP from your setup, would leave you without any organizational structure or processes as well as badly isolated cloud resources.
If you abstract on the tenant level, you will have your organizational structure represented within each cloud platform. Most importantly, you will have isolated tenants for your workloads that people can continue to access when removing the CMP from your setup. The downside: Depending on the used resources within each cloud, migrating workload from one cloud to the other may be a bit more complex.
(✅ 4) What do you want the onboarding process for new cloud tenants to look like?
Cloud Onboarding is where everything starts. The process you set up here defines how different teams and stakeholders within your organization will get in touch with the “new” cloud offering you are building. It has a great impact on how fast and intensively cloud will be adopted and finally on the speed of digitization for your whole company. The smoother the onboarding, the lower the hurdle to access cloud resources. If you want to call yourself cloud-native, self-service is a must here.
One way to measure how mature your cloud onboarding process is, is to define your time-to-cloud: How long does it take a product owner or developer from requesting a cloud environment to him/her actually having access to that environment. A good answer is 5 minutes. This should include all the various aspects of cloud onboarding like assigning a budget, defining access rights, documenting it in a central tenant database and actually creating the environment. inThis should at least be the case for low-risk sandbox environments.
(✅ 5) What kinds of resources do you want your application teams to use?
IaaS is a classic, but most organizations are looking to leverage the cloud for higher-level services: K8s, serverless functions and more importantly managed PaaS services like PostgreSQL databases, BigQuery or Kafka just to name a few. They free you from heavy operating efforts and allow you to move faster and focus on what matters: custom functionality that stands out in the market.
A lot of Cloud Management Platforms (CMPs) originate from an IaaS time and focus on provisioning infrastructure like VMs, Networks and nowadays K8s rather than making the entire cloud portfolio accessible to teams. These commodity services are integrated into the platform and can be easily provisioned by DevOps teams. For Lift&Shift workloads this can work out nicely, because the teams do not need to deal with the specifics of each cloud platform. If they have more sophisticated requirements though, it will be hard for a CCoE to accommodate them. New services will have to be integrated individually which will slow down software delivery.
(✅ 6) Are you aiming to change the way you work?
You might recall the old times when requesting a server required filling out lengthy forms and maintaining a good relationship with the server team to accelerate the process from months to weeks.
In cloud-native development code is king. You describe everything you can as code to make it fast, consistent and easily repeatable. Leveraging cloud-native paradigms like CI/CD and Infrastructure as Code will help you shorten your release cycles and delivering new features faster. To support these this shift, your Cloud Management Platform has to provide you access to the native cloud APIs and allow you to use cloud-native tools like terraform or GitLab.
(✅ 7) What is your approach to achieve compliance?
Staying compliant is one of the core goals of cloud management. Simplified a lot, there are 2 basic approaches to achieve compliance when moving to the cloud: Preventive or reactive. You usually recognize a reactive approach by a list of policy violations you need to fix, often times displayed with the classical “traffic lights”. However, it may require a lot of resources to remediate the errors reactively once something has been detected.
In contrast, cloud environments can be secured preventively in a fully automated fashion. Landing Zones are the “tool” of your choice to accomplish that. They define the guardrails for cloud usage within your organization and prevent DevOps teams from doing things they shouldn’t: E.g. deploying outside of Europe (GDPR) or leaving S3 buckets public.
Your Cloud Management Platform should support an automated rollout of Landing Zones. It means that developers won’t be able to do basic mistakes and that security configurations are implemented consistently across different use cases. This makes it much easier for security to assess application’s security as they start from a solid baseline.
(✅ 8) Are you ready to trust your developers?
The cloud only unfolds its full potential when you use it to enable a wide range of use cases within your organization. What does that imply? A lot of engineering moves from IT into functional departments, like production or sales. These teams know best what they want to build and even how they want to build it.
Giving them their freedom requires a new mindset and even more important: A new shared responsibility model. I don’t mean the one between your company and the cloud provider, but your internal one: between your CCoE and developers.
When choosing your Cloud Management Platform you’ll have to make sure your developers get the technological freedom they need to be successful. Specifically check, whether they can create cloud environments in self-service, use the cloud-native APIs for automation and access the large variety of services the cloud providers offer without anyone’s assistance.
(✅ 9) No native Policy Orchestration
One reason to opt for a Cloud Management Platform is to avoid lock-in to the specifics of each individual cloud platform. And yet there are some aspects you can hardly abstract away. One of them is policy orchestration. All three hyperscalers provide native policy orchestration tools. You most probably have come across at least one of them: Cloud Formation (AWS), Azure Blueprints or Google Deployment Manager.
As the cloud itself is the place where policies are enforced (the so-called policy enforcement point), it’s helpful if your Cloud Management Platform leverages this native policy orchestration. You want to have full flexibility when it comes to security and compliance, even if this may cause more effort in setting up an appropriate policy framework as part of your Landing Zone.
(✅ 10) The beauty of Desired State
As humans, we tend to think in workflows that execute one step after the other. Automation enables us to improve workflows by making them faster and more reliable (You are sure it’s exactly the same, every time you run it). Looking at the tooling landscape, ITSM tools are a common way to model workflows digitally. They give you the power to easily automate your workflows and save you time while increasing consistency. They also facilitate collaboration when they automatically trigger a next step, once the first one has been completed to reduce the need for coordination.
Here is a workflow example in the context of cloud account creation:
- Product owner requests an AWS account by providing her name and use case
- Admin receives service request and triggers automation to create the account with the provided parameters
- An account automation script creates the account and tags it
- Once the account is created, the IAM team receives a notification to provide access to the account
- Once access is provided, the Product owner receives a notification and can access the account
While this is already much better than handing over tasks manually, a workflow approach for Cloud Management comes with weaknesses, especially when you have a large-scale cloud migration project ahead of yourself. Often times workflows still include manual steps. In the long-term they suffer from inconsistencies. How do you integrate future changes? You’ll have to implement a new workflow which will further increase complexity. Or what if there was an error that led the workflow to end early? How do I know after months and tens or hundreds of cloud environments what the actual state of a specific cloud environment is?
That is where declarative definitions or Desired State Models come in to play. Instead of defining each step individually, you define the desired outcome. E.g. an Azure Subscription with access for “Tom Teamlead” and a security configuration that allows productive workload. That’s the desired state that will be “replicated” to the cloud (creation of cloud environment, tagging for production, rolling out of a Landing Zone, providing permissions and so on). While in the beginning the results of workflows and the desired state model may seem similar, the approach to get there is fundamentally different. And the value of that materializes in the long term. Declarative automation in the context of Cloud Management focuses on achieving continuous compliance. What does that mean? A desired state that is defined upon the creation of a cloud environment can be compared against the actual state (actual existance of a cloud environment, actual permission set, actual security configuration etc.) in the cloud. In case of divergence the actual state can automatically be set back to the desired one. Infrastructure-as-Code is a commonly known example for a desired state approach.
meshStack as a Cloud Management Platform follows a desired state approach that is mostly focused on organizational aspects of Cloud Management like Tenant Management, IAM, Security & Compliance or Cost Management.
Cloud Management Platforms are a great way to improve the structure of your cloud landscape and ensure transparency across multiple cloud platforms. However, the choice of platform is a strategic decision that will affect the way you work and the speed in which you’ll be able to adopt cloud in the future. Taking these 10 aspects into consideration will help you take the right choice and better understand its implications.
World Office at meshcloud - How we Tackle the Challenge of Remote Onboarding
In the past two years working from home (sometimes with screaming kids in the background) has become the new normal. With decreasing numbers of corona related cases and less risk of getting seriously ill, our office gets busier every now and then again - which is great. We love our live meshBeers on Fridays to start the weekend together 🍻
However, as a company we can understand and we actually even value that everyone has different preferences. That’s why for our meshis it’s up to them whether they want to come to the office, work remotely or work somewhere else, maybe somewhere close to the ocean with some more sun rays during the day ☀️
Being a remote and even World Office friendly company of course also comes with challenges. In today’s blog post I want to disclose how we handle onboarding remotely, in case we have to.
Equipment of choice to get you all set-up
For Starters, our Onboarding doesn’t begin with your First Day of Work, it actually starts once the contract is signed. There are of course a couple of administrative things that need to be done like the enrollment to the payroll for example.
You also need to select your equipment. At meshcloud we offer a list of items that you can choose from (e.g. Laptops from different brands with various configurations) but are always open in case you need anything that you can’t find on the list, like maybe a special mechanical keyboard, monitors or anything else.
Hassle-free Pre-Onboarding for you
You are able to do every administrative task online completely and mostly automated with our HR-Software. So that it is not only really easy but also super quick for you 🏎️
Do you want to empower humans to build a better future? Then we'd love to meet you!
Our HR-Team will keep you up-to-date about your onboarding status and will also give you detailed information on your first day at meshcloud and the upcoming weeks beforehand. Psst! 🤫 A couple of days before your start you will get a suprise meshi-package that’ll help to really get you started for your journey at meshcloud 🎉
Start your meshJourney with an Onboarding-Buddy
On your first day at meshcloud tons of new information is waiting for you. But don’t worry we will try to pack it in small events. There will be various onboarding workshops to our most common used tools lead by different meshis, so that you already have the chance to get to know some people. Also an Onboarding-Buddy will be by your side and will guide you throughout the next weeks 🗨️
Our Game-Changer: The virtual office
To get together in a fun way we recreated our office virtually. With an avatar designed by your choice you can walk around the virtual office, meet colleagues and attend the different Onboarding Workshops. The picture above shows a sneak peek of our Virtual Office - we also have a garden area, if you just need some time to chill 😎
Reaching your next career level is our common goal
Together with your Manager you’ll have regular 1on1 sessions to talk about your onboarding progress, general things that are on your mind and also your personal development. It is our goal to help you reach the next level of your career within 1-1.5 years of being with meshcloud. Therefore the two of you will sit down in the first few weeks and work on a detailed development plan.
For people who do start remotely, they are always invited to come to the office. We are also having regular live team-events and weekly virtual coffee dates, so you’ll be able to meet your new colleagues quickly.
One thing we can promise you - we will give our best to make the Onboarding as smooth as possible. If you want to experience our Onboarding first-hand - apply here.
Cloud Foundation: 3 valuable Players on the Field
Building Cloud Foundations can be cumbersome and tedious. In this post we’ll introduce 3 of our offerings in that field that will make your life easier.
If you are an Enterprise Architect and/or responsible for your organization’s Cloud Center of Excellence or Cloud Foundation Team this post is for you.
It will show you ways to accelerate your Cloud Journey, provide insights on Cloud Foundation best-practices and finally demonstrate how our offerings play together to help you build the best Cloud Foundation.
The Cloud Foundation Maturity Model – Getting Clarity
As a member of your Cloud Foundation Team, you may have come across the Cloud Foundation Maturity Model (CFMM). It’s a strategic model that helps you understand the capabilities you’ll need to build up during your Cloud Journey, regardless of which clouds you use, where you’re currently at or what approach to implementation you have taken.
You can consider it the coach on the playing field. It gives you guidance, shows where you’ll want to go and provides insights into different implementation options that will get you there.
We have used this model successfully with leading cloud-native organizations from various industries.
Building Cloud Foundations is an Iterative Process
Lots of organizations we work with run thousands of applications in the cloud, managed by a central Cloud Foundation Team. However, they didn’t get there within a day. Implementing a Cloud Foundation is best approached with an iterative approach. You start with the basics and implement more and more sophisticated capabilities over time as you get to know more about your users and their requirements.
The Cloud Foundation Maturity Model helps you to break the journey down into small steps that systematically build upon each other.
It’s not only about how far along the Cloud Journey you are, but also what type of vehicle you’re using
When Cloud Foundation Teams are faced with large-scale cloud migration projects, they know that whatever Cloud Foundation capabilities they build they’ll have to be highly automated in order to keep up with the upcoming scale of cloud demand.
That’s why we cover two dimensions when it comes to maturity within our Cloud Foundation Maturity Model:
- Journey Stage: Varying from Essential building blocks (1) to Industry Leading capabilities (5)
- Implementation Maturity: Varying from manual to fully automated
Assessing both brings you valuable insights when evaluating the current state of your Cloud Foundation and that’s exactly what the Cloud Foundation Maturity Model can be used for.
As a result, you’ll have a structured analysis of your Cloud Foundation, demonstrating your achievements as well as areas you’ll need to improve on a single page, which makes it a great tool for internal communication.
Collie – A Trustworthy Helper On Your Way To Cloud Foundation Maturity
Most organizations start their cloud journeys in high spirits on a green field. By the time you realize that you need proper cloud governance and decide to establish a Cloud Foundation, the once green grass has turned into a brownfield landscape. Collie is an open-source multi-cloud CLI that helps exploring and sorting, preparing for systetmatic management. It’s built for power-users, single player.
Collie CLI easily provides multi-cloud transparency on cloud tenants, corresponding access rights, tags and cost information. In regard to the Cloud Foundation Maturity Model it will help you to implement the following building blocks:
- Cloud Tenant Database
- Multi-Cloud Tenant Database
- Cloud Tenant Tagging
- Multi-Cloud Tagging Policy
- Monthly Cloud Tenant Billing Report
To fully automate your cloud foundation capabilities and establish collaboration between the Cloud Foundation and your DevOps teams, you’ll need to go one step further and use a platform like meshStack that reflects this organizational model.
meshStack – Your Cloud Foundation Platform
At meshcloud, we focus on enabling DevOps teams to use cloud and speeding up their applications’ time-to-market. Providing self-service access to native cloud tenants like AWS accounts, GCP projects or Azure subscriptions is critical to achieve this.
We know that every organization is unique and comes with specific requirements, especially in regard to the integration of existing IT Landscapes. Our aim with meshStack is to help you get the basics right and enable you to build upon them.
That’s why a lot of Cloud Foundation capabilities come out-of-the-box, while others can flexibly be adapted to your organizations’ needs.
In general there are 3 ways meshStack can help you to implement Cloud Foundation Building Blocks.
-
meshStack provides this Cloud Foundation Building Block out-of-the-box
Example: When using meshStack in a multi-cloud setup, you’ll have a Self-Service Multi-Cloud Tenant Database, out-of-the-box.
-
meshStack enables strong facilities for an easy implementation of that building block
Example: With Landing Zones and Services you’ll have everything you need to implement Modular Landing Zones.
-
There are established solution patterns that facilitate the implementation of this building block, when using meshStack
Example: There is an established solution pattern that will help you provide managed Service Accounts with meshStack.
In The End It’s About the People
Our offerings aim to help organizations throughout their entire Cloud Foundation journey:
- From understanding and defining the Cloud Foundation for your organization based on our Cloud Foundation Maturity Model
- to analyzing and understanding existing cloud landscapes with Collie CLI
- all the way to implementing large-scale Cloud Foundation Platforms to manage thousands of teams and applications based on meshStack.
However, establishing a Cloud Foundation within an organization is not only about building up the relevant capabilities and deciding on implementation options. It also is a huge organizational shift that requires involvement of all stakeholders and great communication across teams and up to the C-Level.
By allowing organizations to easily experience the power of self-service and providing means for internal communications, we want to enable Cloud Foundation Stakeholders to drive acceptance for change throughout the entire organization in order to pave the way for a new way to organize IT.
Life as a meshi: Working in Customer Result Teams
In the previous post we introduced what a customer result is. In this post we want to show you how The meshcloud way of work forms cross-functional teams that own the customer results they work on.
Most customer results are scoped to a timeframe between 4 and 12 weeks worth of team work. This means that during this time the customer result team forms, establishes a firm grip on the problem space, delivers a result and validates the desired outcome was achieved.
Forming Customer Result Teams
Our Customer Results board is the central operational planning mechanism for the company. We believe that teams work best when everyone is committed to the same goal. We therefore empower meshis to choose customer results they work on on their own.
How does that work in practice? As a meshi specializing in a specific function (e.g. you're a Marketing Manager or Software Engineer) you look through the next highest prioritized customer results. Do you see yourself in the dream team and think you can make an outstanding contribution to this result? Great, you assign yourself to the team.
Kicking it off
As soon as the team is fully assembled, you meet with the team to kick off your mission. In this first meeting you disseminate the customer result together and explore the problem space. Together with your team you form an understanding of the challenge ahead and start making a plan on how you will tackle it. This may involve building a backlog of user stories, arranging customer interviews or any other activity and method that you find suitable to achieve the goal. While there's an established set of best practices and tooling available, we trust teams to know best what works form them.
Every customer result has an assigned supporter who's role is to support and mentor the team in these activities. Supporters are experienced senior meshis whose job is to make sure the team stays on the path to success. The first thing the supporter will guide the team towards is how to make a solid plan and condense it to a form where you can present it at our weekly company all-hands.
Flock and Customer Result Work
As a meshi working in a customer result team, you work on the mission and act like a "liaison officer" to your flock (what this is will be covered in the next blog post). Let's illustrate this with an example. Suppose you're a software engineer working in a customer result and your team has determined that the best way to achieve the desired outcome is to add a new product feature. The product implementation and its development process are owned by your flock, you follow them when working on the feature implementation. Acting as the team's liaison officer to the product, you coordinate any necessary product architecture and implementation decisions with your flock and help the customer result team understand how the feature can be rolled out to production.
Syncing with your Customer Result Team
We believe that meshis are best positioned to manage the operational work they are doing. That's why meshis are responsible for managing their own time to work on customer results and working on flock duties. Customer result teams therefore arrange their own work schedule when they will be working together on the project and how they will meet and coordinate the ongoing work. In practice, most teams use a weekly sync meeting and have virtual collaboration spaces (e.g. in our gather.town office, ClickUp lists, channel on slack etc.)
Wrapping it Up
As your customer result nears completion, the team and its supporter focus on evaluating the outcome by collecting customer feedback and metrics. It's important to plan this phase well ahead of time, as collecting feedback from the real world takes time and patience. Nonetheless, it's really important to conduct this rigorously to put the customer result to a definitive end. Definitive end means that you share at an all-hands which outcomes we can celebrate, and from which we can learn and improve.
During the evaluation phase of a customer result, your team may have already identified other valuable customer results to explore. You feed those back in the process and already look for the next customer results to join. Do You Want to Empower Humans to Build a Better Future? Then we'd love to meet you! Do You Want to Empower Humans to Build a Better Future? Do it! Find our jobs here.
Launching Collie – Your Open-Source CLI for Cloud Governance
If you've been in touch with meshcloud, you'll know that we love sheep. And that's because clouds and sheep have a lot in common:
- They love to be free, rather than locked in a barn
- They love to be together, rather than wandering alone
- And they need a shepherd, to protect them from lurking dangers
With Collie, we're launching an open-source CLI tool that helps you as an enterprise architect or platform engineer to assume your shepherd responsibilities, giving you the control to steer your flock towards the next pasture.
More specifically, Collie enables you to:
- View all cloud tenants in one single overview - View your AWS Accounts, Azure Subscriptions, and Google Cloud Projects with their metadata with only one command.
- View billing information across all clouds - See what you spend per day, month, or week in all cloud platforms, including the right metadata. Includes support for CSV, YML and JSON.
- Analyze tag inconsistencies - See at a glance what tags are used, by which tenants (and which not), and what potential inconsistencies are in place to fix any governance issues.
- Track your cloud history - Collie CLI is built on the principles of GitOps and its data can easily be written to git repositories for tracking changes in your cloud environments.
The development is based on our in-depth experience with meshStack: Our multi-cloud governance platform for the enterprise. It provides you with an easy and lightweight entry to cloud governance.
Let's have a look into Collie and how it empowers you to manage your multi-cloud landscape!
Is your Cloud Landscape a Mess?
Did you ever get the feeling that you are losing track of what is happening in your cloud landscape? You have multiple environments (AWS accounts, Azure Subscriptions, or GCP projects) running across different clouds. They started as playgrounds and now more and more serious stuff is running in there, making it harder to keep track every day.
Your sheep are basically wandering off from the flock.
No matter which cloud you use: AWS, Azure, or GCP, they all provide capabilities on the org-level to see what cloud environments are running in there, and what costs they cause.
What is missing though is a comprehensive overview. It's all hidden behind different screens and settings, across multiple cloud consoles or CLIs, not allowing you to get that single picture you're looking for.
Cloud Transparency is Key!
For a proper overview, you would need to have different types of information, consolidated in a single view. It could be fairly easy, all you need are answers to these questions:
- Which cloud environments do exist in my multi-cloud landscape?
- Who do these cloud environments belong to?
- What costs do these cloud environments cause?
- Are they consistently tagged and documented?
Having this information at hand, enables you to bring things into order (= Cloud Governance) and herd your sheep.
Collie – Open-Source Multi-Cloud CLI Tool
This has never been as easy. All you need, is to have the native cloud CLI tools installed on your machine. From there it's just a couple of commands to shed light into the dark.
See for yourself:
If you are wondering how to use that information, here are some common use cases that people implement with Collie.
1) You want to delete cloud environments that aren't used anymore to reduce complexity.
2) You want to implement a consistent tagging strategy and need to know which cloud environments are still missing
3) You want to make sure that there are no idle environments (Sandboxes, etc.) raising your cloud bills every month
4) You want to implement a consistent tagging strategy and need to know which tags are currently used within your cloud environments
5) You want to map cloud environments to IT products, applications or cost centers within your organization
6) You want to analyze cloud costs based on their tags to build multi-cloud cost reports with nice dashboarding tools like PowerBI or Google Data Studio
How to get started with Collie
If you're looking for full transparency on your growing cloud landscape, Collie is just right for you.
Collie is open-source and available on GitHub. You only need to have the native cloud CLIs installed on your machine and are ready to go.
We hope you find it useful. Please reach out with any contributions, feedback, ideas or requests for help.
We're looking forward to herding our clouds together.
meshcloud receives funding for the cloud security approach "MultiSecure" by the German Federal Ministry of Education and Research (BMBF)
It’s been a while since we announced that we’ve been funded for our MultiSecure project. We are still very excited about the great news and have already been working hard on putting our vision into practice: We want to enable organizations to code their cloud security regulations along with their applications and infrastructure.
Additional Information:
Starting in April 2020 meshcloud receives funding by the German Federal Ministry of Education and Research (BMBF). The funded project with the title “MultiSecure” aims to create a declarative technology to describe secure multi-cloud infrastructures and organizations. It addresses the need of organizations to establish an effective way to handle security requirements as well as control on the infrastructure in their cloud transformation.
Implementing secure cloud configurations is a major challenge for large organizations
By now most large organizations already use cloud computing infrastructure for application development. Flexible on-demand access to different types of cloud resources as well as a shift towards agile methodologies enable them to accelerate their software delivery capabilities and drive innovation. Cloud service providers like Amazon AWS, Google Cloud Platform or Microsoft Azure provide a vast and continuously growing portfolio of cloud services to address these needs. As the adoption of cloud computing increases, cloud environments become more complex and are harder to control. Looking at the market, we observe that in many cases the “experimental” use of the technology has been overcome, requiring consistent, automated processes to allow for a further scalable adoption.
Security Responsibilities have shifted and decentralized across the organization
We are facing increasingly complex cloud environments. In addition to that a shift in responsibilities has occurred: While central IT departments used to be responsible for the majority of security aspects on the infrastructure layer, this responsibility has shifted and decentralized. Many services are directly provided by the cloud providers rather than the central IT departments, relieving central IT from part of the responsibility. To learn more about Shared Responsibility, check out our (Guide on Cloud Security and Compliance). On the other hand DevOps teams that use the cloud have to take care of the security on the infrastructure and application layer. Mistakes in the configuration of infrastructure are security-critical. Incidents as happened at Capital One demonstrate the risk.
This shift in responsibility raises 3 questions:
- How can central IT departments achieve control on the organization’s cloud infrastructure ?
- How can organizations handle policies across clouds and across teams ?
- How can organizations enable DevOps teams to focus on functional requirements of their application ?
Without consideration of these questions, an organization is likely to lose itself in shadow IT, immense complexity and an enormous non-functional overhead in application development.
Cloud Environments are complex, dynamic and durable
Let’s look a bit deeper into the organizational context of a cloud project. Here is an exemplary process of providing a cloud environment to a DevOps team:
- A team member, most often a team lead, requests a cloud environment for a specific cloud platform for his team.
- The environment, also known as a cloud tenant, has to be created.
- Permissions on different levels (e.g. admin/developer) have to be provided to the team members.With these permissions in place the team will have access to their cloud environment and the corresponding services.
- DevOps teams have to demonstrate compliance with the organization’s security frameworks to get an approval to bring their application to production. Therefore, before deploying an application to the cloud environment, cloud environments are usually configured to follow corresponding security controls.
Mostly, these configurations are not workload-specific, they cover organizational aspects of different areas like identity and access management, server geography, service configurations or cloud budgets. These are some examples:
Defining, implementing and maintaining them over time is a major challenge (Read more on this in our post on the Cloud Landing Zone Lifecycle). Especially at a large scale, organizations face the following difficulties:
- In some cases, DevOps teams receive access without prior configuration of the cloud tenant. The compliance then has to be approved retrospectively leading to additional effort and change requirements when the application has already been deployed, rather than preventing them to occur.
- If the cloud tenants are configured manually and by each team individually there is a high risk for inconsistencies, due to mistakes.
- Security controls are mostly defined abstractly and in natural language. Their interpretation is often up to the person that technically implements them which again leads to inconsistent results, even if done correctly.
- Cloud service providers offer different ways to put these configurations into place. For multi-cloud environments this makes it even harder to implement consistent policies across different cloud service providers.
- With large amounts of cloud tenants these inconsistencies multiply and with no system in place that provides cross-cloud transparency, an effective implementation and control of the measures is hard to achieve.
Today’s IT organizations have to find the right balance between, which leads to a demand for new security approaches:
the agility and technological freedom DevOps teams need to leverage the cloud for a better software delivery performance
AND
the control and governance an organization must have to on their infrastructure to act responsibly and mitigate security risks. Finding this balance requires new approaches to IT security.
In a perfect world security rules and requirements are unambiguous and easily interchangeable between Stakeholders
In many cases policies bring together different stakeholders and their implementation requires the cooperation of multiple departments within an organization and beyond it. Let’s consider a compliance department: They define policies in natural language. These policies then have to be implemented by IT teams and will later be audited by an external party. While standards like the ISO/IEC 27000 family have led to alignment and a common vision of best practices in the field of information security, we still face a lot of uncertainty, when it comes to the adoption and implementation of these standards within the organization in connection with new technologies and working methods.
Textual explanations are oftentimes ambiguous and it is hard to judge, whether a control has been appropriately fulfilled or not.
In a perfect world, security organizations would be formalized, e.g. put in “code” to avoid unstructured and intransparent document battles. Rules and requirements would be clear and therefore could be communicated precisely. Suppliers, customers and companies would have a common basis for communication.
MultiSecure unifies and formalizes security and organizational rules to establish a consistent and transparent security framework for organizations
With the MultiSecure project, meshcloud aims to overcome this uncertainty and increase transparency when implementing security policies within the organization. MultiSecure bridges the gap between clearly defined security controls, custom organizational processes and the cloud infrastructure providers.
The idea – A declarative projection of the organization
The idea of MultiSecure is to describe organizational elements and their relationships as code in an open and reusable format - a declarative manifest that represents the desired target state of the organization. The information in that manifest follows a clear structure and can be handled as source code:
- It can be versioned,
- it is at all times clear who made changes to the target state definition and
- it can automatically be compared and synchronized with the actual state of the multi-cloud environment.
MultiSecure allows to centralize this information in an open format, instead of squeezing the organization into the envisaged organizational models of the cloud providers and therefore maintaining multiple proprietary organizational models in parallel and distributed. It builds a projection of the organization that can be consumed by different systems.
This is where meshcloud and our software platform meshStack come into play. meshStack consumes this organizational information either manually via our user interface or via API and automatically replicates it into the different cloud service providers, taking into account their specific native tools, services and best-practices.
The Benefits – A comprehensive IT security framework and avoidance of vendor lock-in
We already mentioned the benefits of having code to avoid ambiguities in terms of interpretation of security controls. Here are the main benefits we see regarding the overall governance of IT infrastructure within the organization.
1. An integrated security concept:
By enabling organizations to define policies centrally and in an open format, that can be applied to various cloud providers, MultiSecure provides an integrated security concept for the use of cloud technologies.
2. Reducing vendor lock-in:
Uncoupling organizational processes and security requirements from a specific cloud provider, empowers organizations to keep sovereignty over their infrastructure and choose their preferred cloud provider(s) self-determently.
3. Reducing IT security risks with preventive measures:
Configuring cloud environments to comply with security requirements, before handing them over to their users (DevOps teams) is one of the core concepts behind MultiSecure. It does not only prevent misconfigurations that could lead to security breaches, but relieves DevOps teams from non-functional requirements.
4. Made for scale and a sustainable IT strategy:
The declarative nature of MultiSecure allows for a sustainable and scalable security strategy. Cloud environments can be created fully automated fulfilling a rising demand for infrastructure of any provider. Furthermore, the approach takes into account the lifecycle of applications and policies, with mechanisms for updates and long-term operations in place.
The scope – Infrastructure as Code vs. Security as Code
The concept of a declarative manifest is not new to the cloud world. Known as “Infrastructure as Code” it has been popular for the deployment of cloud infrastructure. We are not aiming to cross this field. That is why we consider workload out of scope of the project. There are already great solutions around (e.g. terraform, ansible) to define resources within cloud environments. As meshcloud, the MultiSecure project focuses specifically on the organizational aspects of security and governance and can be considered the “terraform” for security and the organization.
Join the MultiSecure Community to shape the Future of Cloud Security
We strongly believe that this project will benefit from the contribution of diverse stakeholders. Even before the official launch of the project, we’ve received excellent and supporting feedback from customers as well as partners. We’d be more than happy to have you on board for our mission, too.
To keep up to date, we kindly invite you to
- Follow us on Twitter @secascode
We are interested in your use cases. If you see any touchpoints to MultiSecure, we’d be more than happy to discuss and get in touch with you. Reach out to us with your questions.
Why your ITSM Tool is the wrong Choice for cloud-native Cloud Management
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.
(Multi-)Cloud Outlook in 2020
As meshcloud, we are proud to look back on a successful year 2019, in which we won multiple new customers. During this time we've had the great chance to accompany different types of companies in their cloud transformation. While our customers belong to many different industries, e.g. Automotive, Financial Services or Utilities, we've been able to observe many similarities in their move to the cloud – showing the relevance of cloud management and cloud governance among large organisations.
At meshcloud, we support large organisations in their cloud transformation. Our platform provides consistent governance with cross-platform Identity and Access Management, Tenant management, Cloud Security & Compliance and Cost Management and is used by large enterprises to deliver secure cloud environments to thousands of teams while staying in control and reducing complexity.
Based on our experiences in this past year, here are some predictions on upcoming cloud challenges in 2020:
Experiments come to an end: Bringing the Cloud Journey to the next level
A lot of companies have surpassed the experimental stage of using cloud. They are moving towards production deployments of cloud applications, have to manage rising costs and face tightening cloud security requirements. While in the beginning of a cloud journey, we often times face scattered cloud initiatives across different parts of the organisation, we now see more and more companies consolidating these initiatives and bringing them to the next level, setting up professional guardrails, preparing for wider user groups. One of the biggest challenges in this move is a reorganisation of responsibilities, especially in terms of cloud security, as the use now will surpass a couple of cloud experts.
In order to fulfill these requirements, there will be a consolidation of deviating cloud governance activities, bringing them together and solving them consistently across different cloud providers, often conducted by a dedicated team of (multi-)cloud experts. These new solutions have to be set up for scale in order to address the rising demand for cloud resources. Self-service and automation help to accelerate the time-to-cloud to a couple of minutes for increased productivity.
Watch out: Organizational lock-in is on the move
Being obsessed with avoiding vendor lock-in on the workload level a lot of companies have managed to transfer workload to infrastructure like Kubernetes and data to open-source databases like MySQL, PostgreSQL or MongoDB. At the same time the maturity of managed Kubernetes offers has greatly improved. However, as the use of cloud grows organisational processes and integrations towards cloud platforms are being established. And they are a new way for cloud providers to keep their customers close. As most organsations use more than one cloud provider to meet all their requirements, they are confronted with multiple organisational models. This is rather challenging, as the integration of new platforms becomes time and resource consuming and slows down the actual adoption of the new technologies.
We are very happy to be working on a declarative definition of organizations ("org-as-code") that enables companies to define their organization once, while meshcloud takes care of translating this into the different cloud platforms. The concept is known from infrastructure as code and based on the idea of defining a desired target state in an abstract way, while the system works out the specific implementations in the background. Having this, it becomes very easy to integrate new cloud platforms and provide technological freedom. (Learn more about org-as-code in our multi-cloud maturity model)
Cloud Security Complexity is bursting
When cloud is widely used across the organisation and the number of cloud projects is continuously growing, it is essential to have clearly defined cloud security concepts as well as proper process documentation to keep transparency on ongoing activities. Especially cloud access management (e.g. provisioning and retrieving access rights to cloud tenants) must be handled consistently, as the amount of managed permissions grows exponentially over time: more users, more projects, more cloud platforms. An easy and highly automated approach will help to keep control and enables to run continuous governance in order to comply with cloud security frameworks and certifications.
At the same time, multi-cloud teams will have to help cloud users and DevOps teams to implement cloud security concepts (e.g. via landing zones in their cloud tenants to achieve consistent security configurations across accounts and help them to deal with the increasing responsibility of DevOps practices.
Therefore, for 2020 we see an increased demand for clear governance of (multi-)cloud environments. Consistent cloud configurations and policy definitions will be key as companies scale up their use of cloud. Not only do they have to be controlled once implemented, their definition and scalable rollout will be in focus in order to provide a basic cloud security level for all cloud activity, which helps to align cloud configurations and accelerate basic cloud security assessments, even in regulated environments.
Are these topics relevant to you in 2020? At meshcloud, we provide best practices for multi-cloud management and multi-cloud governance, integrated into a powerful software platform. Feel free to reach out and get in touch with our multi-cloud experts or book a demo.
Multi-Cloud Management – Make or Buy?
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
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
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.
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.
Multi-Clouds in Banking – 3 Takeaways from the 2nd EBF Cloud Banking Conference
It’s already been a while. On July 9th, I visited the 2nd EBF Cloud Banking Forum in Brussels. The topic of the day: “Shaping a Multi-Cloud Environment”. Representatives of banks, regulators and cloud providers met to discuss how cloud computing can be used in the financial services sector, with one common goal in mind: To provide secure banking services to the people. With all the FinTechs and Neobanks showing up all over the place, it is obvious that traditional banks have to adopt new technologies to stay competitive in the market. The EBF Cloud Banking forum brings this discussion to the European level. With joint forces, we can be an example not only to other countries, but also be a pioneer in regard to other sectors.
The adoption of cloud technologies comes with some hurdles and quickly raises questions for the users: “How do I stay compliant with existing regulations?” as well as the regulators: “How do I make clear and transparent rules?”. “How are we going to treat the overcententration on the market?” There basically are only a handful of cloud providers to choose from and implementing a multi-cloud strategy is one way to act against overconcentration. However, it also raises the administrative complexity of adopting cloud. Therefore, a proper cloud management has to be put in place to help the banks avoid having more complexity than before. From a whole day of intensive discussions, I’ve put together the three main take-aways of the day.
Identity and access management (IAM) is crucial to a bank’s cloud transformation
This topic is not new to external environments like clouds. Defining how to manage identities and access to infrastructure resources is and has been a complex issue for many years. In order to mitigate the risk of abuse or unauthorized access to confidential information and critical systems, access rights have to be reduced to a minimum, following the principle of least privilege. Having a multi-cloud environment may raise the complexity of achieving this.
On the one hand, you want to make it easy for your users to access cloud resources, in order to speed up software development and lower the barrier for cloud adoption. On the other hand, you need to be in control of the access process, make sure it is documented and auditable to avoid the risk of undiscovered information leakage.
With meshcloud, we help large organizations like banks with a governance framework for multi-cloud environments. Our platform plugs into the existing organizational structures and identity providers like Azure AD or LDAP and unifies the way access and permissions are handled across different cloud providers. As a result, we use existing identities and provide secure SSO access to all cloud providers as well as a platform to manage fine-granular permissions centrally before replicating them to the attached platforms.
In addition, cloud providers like AWS and Azure have published services like AWS CloudTrail that monitor access and operations related to your cloud infrastructure.
An exit strategy is necessary to avoid vendor lock-in to a single cloud provider
The EBA guidelines on outsourcing arrangements include a paragraph on exit strategies, which requires banks and other financial institutions to have a well-documented exit strategy in place that ensures business continuity in case of an interruption of outsourced services. This can be the result of a failure, malfunctioning service offers as well as contractual or legal obstacles in regard to the service provider. These scenarios should be well documented and practiced, as it is crucial to be familiar with the workflows and know what to do in such exceptional circumstances.
While multi-cloud is a way to distribute the risk across more than one service provider, there are strategic steps to be considered when deciding on a sustainable cloud strategy. The use of open-source infrastructure components on different layers, such as Kubernetes, PostgreSQL or NGINX for example, can facilitate migrations from one cloud to another drastically. They can even be operated in a private datacenter. However, most companies decide on a multi-cloud strategy as a result of a best-of-breed approach. They want to use each cloud for the specific (and often proprietary) services it offers, for example in the field of machine learning or artificial intelligence. The use of such tools can accelerate development because they bring a lot of functionality out-of-the box and enable teams to focus on truly differentiating functionality. An assessment of the criticality of applications as well as the consequences of the failure of such proprietary services should be considered within an exit strategy.
As meshcloud, we help companies to avoid vendor lock-in by facilitating the use of multiple cloud platforms and the distribution of infrastructure and applications across them. We define organizational structures (teams, projects, users, permissions) in a declarative manner to enable our customers to integrate new service providers very fast and with little administrative overhead. To address the rise of higher-level infrastructure services, such as managed databases, message queues or machine learning and AI services, we offer a service marketplace that enables customers to provide a large variety of services based on an open standard (OSB API). This unifies the process of provisioning services and decouples it from the underlying infrastructure.
Configuration is key
A recent study of KPMG found that 80% of IT security incidents happen due to manual misconfigurations. By spreading infrastructure across different service providers it gets even harder to keep control on correctness and consistency of cloud configurations and this does not consider any application-specific configurations yet.
To improve security and compliance of cloud environments, our landing zones help to configure cloud accounts upon creation. This enables our customers to roll-out consistent configurations in automatically created cloud accounts, according to their use case (test, development, production). To give an example these configurations can limit the use of cloud infrastructure to specific geographical regions or blacklist certain services that are not compliant. By rolling them out consistently across all cloud accounts, our customers can relieve their development team from defining compliant configurations individually and instead provide them with a framework that has been approved by the security department.
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.