Multi-cloud strategy — Motivations, Challenges and Solutions Landscape
Multi-cloud has recently become an integral part of a sound business strategy. More and more companies are either considering multi-cloud, have already implemented a multi-cloud architecture or are currently in the process.
With 2020 driving digital transformation forward like never before and cloud being on the forefront of this, a multi-cloud strategy for most enterprises is either inevitable or at-least deserves an in-depth look. The reasons for this are varied:
- Avoiding vendor locks — It goes without saying that unless it’s a part of a strategic alliance, enterprises don’t like to be locked to one vendor for a host of services.
- Compliance and Regulations — Some workloads are only allowed to be run on a particular cloud because of a multitude of compliance and regulatory reasons.
- Licensing lock — Certain workloads are locked up due to licensing reasons in a way that they can only be run on a particular cloud.
- Workload / Product certification — Many products or workloads are certified to work on specific clouds only.
- Lack of required services and integrations — One cloud services provider may not be enough for the breadth of services and integrations into current infrastructure needed for future-proofing and day-to-day services.
- Cost reduction — A multi-cloud approach can help achieve an even better cost reduction than what’s possible on one cloud.
- Flexibility — Not being locked in to one cloud allows you to explore more and provides you with the flexibility to make better and more informed architectural decisions.
- Developer ecosystem — This is less a top-down strategic decision, more bottom-up. Sometimes developers prefer a particular ecosystem for their domain — for e.g. your data engineers / data scientists might prefer Google Cloud for their products whereas .Net developers would rather stay on Microsoft ecosystem, i.e. Azure. Making a strategic decision that the developers aren’t content with, might adversely affect developer productivity and consequently your overall agility and time-to-market.
While this is not an exhaustive list of reasons to adopt a multi-cloud strategy, it does encapsulate around 95th percentile of the primary drivers.
Now that you are probably interested in multi-cloud, let’s look at what possible challenges you might face in this journey and their possible solutions.
Challenge 1 — Application Portability
Now that you have workloads on different clouds, you would want to be able to move them around — be it for cost or other reasons. Portability in terms of application means not having to rewrite your application when you move from one cloud vendor to another. You would obviously want to avoid doing any extra work related to a specific cloud vendor.
Every cloud vendor has its own agenda and thus wanting to be interoperable with other cloud vendors is not really high on their priority list. Another reason for this lack of interoperability is that it would require considerable amount of effort and collaboration to be able to standardize, let’s say APIs for FaaS and PaaS services.
- Ignore Application Portability for some workloads — Sometimes a product on a particular cloud fits so well to your requirements and has some proprietary features that are nowhere else in the market that it makes business sense to put portability on back burner. However that won’t work for all your workloads.
2. Use Kubernetes as an abstraction layer — Containers have become the most prevalent way of application modernization. This has led to an explosion of adoption of Kubernetes as the preferred container orchestration platform. Since all major cloud providers support their own CNCF certified Kubernetes distributions (EKS on AWS, GKE on Google Cloud, AKS on Azure etc.), most enterprises choose respective Kubernetes products as their first choice to migrate to the cloud.
While the omnipresence of Kubernetes on all major clouds helps heave a sigh of relief, it still doesn’t mean you won’t have to do some extra work. For e.g. all these Kubernetes distributions tick differently— in terms of authentication, authorization, networking, maximum number of nodes/pods allowed etc.
Furthermore, most applications aren’t standalone — they need databases, middleware etc. That means moving applications across clouds would also require you to have a strategy to move accompanying infrastructure.
3. Use multi-cloud solutions provided by the cloud — Some cloud providers like Google Cloud have set higher priority on multi-cloud / hybrid cloud solutions, for e.g. Anthos on Google Cloud allows you to manage your clusters on Google Cloud and AWS using a single pane of glass (Azure integration is planned for Q2 2021). You can thus use the same tools to manage the infrastructure, containers, configuration and multi-cluster management etc. on both clouds. This also allows the applications to be easily moved from one cloud to another.
With all the solutions mentioned above, it’s always important to have an exit strategy. For e.g. for all workloads running on Cloud A, it’s important to jot down all the steps required to run the same workload in Cloud B, including the stakeholders and relevant partners in this process. It’s also important to categorize the workloads according to their business criticality.
Challenge 2 — Governance vs. Agility
Balancing governance against agility is a tough enough task on a single cloud, let alone on multiple clouds. You don’t want to stifle the speed at which your developers can progress, but at the same time you also need to make sure you don’t end up with a hefty bill to pay at the end of the month. If you are too heavy-handed with your governance policies — with multiple approvals required before an action can take place, especially in an unautomated way — you can be sure that this will restrict cloud adoption. You can’t end up having more restrictions than were there in your on-prem environment. It’s all about the balance.
- Consistency across clouds — You need to make sure that there is consistency in terms of resource naming convention, tagging strategy etc. If that is not possible for some reason, it’s imperative to have a clear mapping between them. This will help you form consistent governance policies across multiple clouds.
- Automation and self-service — You can package all the governance related components through infrastructure and project related automation in an artifact which is deployable through simple self-service. This helps to make sure that governance and compliance rules are being abided by in every single deployment that takes place. This helps you build a catalog of services / deployable artifacts that are pre-approved. You can further allow such deployments to take place through automated workflows in your favorite ITSM tool. For example, AWS Service Catalog allows such automation and self-service.
- Adopt consistent policies that limit the blast radius — The right balance between governance and agility is found by allowing people to make their own decisions in sandboxed environments where you can limit the damage that can be caused. The policies need to make sure that people have freedom to try out different products in the cloud whilst ensuring that they don’t cause detrimental harm in any way, for e.g. no confidential data gets exposed etc. Budget alarms are also a great tool to increase responsibility among cloud users.
Challenge 3 — Data Governance
Data is ubiquitous — in a multi-cloud setup, this fact can cause a lot of headache. The fluidity of data can be punitive since movement across different cloud environments is accompanied by costs, i.e. cloud providers charge against outbound data transfer (egress). Many times data has to be replicated from Cloud A to Cloud B to run data processing pipeline / analytics with result going back to Cloud A for further processing and the result being archived in Cloud C— in some cases there are much more complex workflows. All this criss-crossing of data raises enormous challenges around data provenance, security, visibility, lifecycle complexity and governance.
If your data movement is due to analytics, there are multiple products that help you with data governance and analytics across multiple clouds. For example:
- BigQuery Omni —BigQuery Omni uses Anthos clusters that are fully managed by Google Cloud to securely execute queries on other public clouds. Thus you can use the same BigQuery interface on Google Cloud to query the data that you have stored in Google Cloud, AWS and Azure (support planned for Q2 2021)without any data movement. BigQuery as a platform has separate compute and storage layers, which makes it relatively easier to deploy the compute layer in other clouds and run queries there.
- Snowflake Data Platform — Snowflake delivers a single data experience by abstracting the complexity of underlying cloud infrastructures, allowing you to run your data solution seamlessly across multiple clouds and regions. It also has separate compute and storage layers, with a control plane on top of them. You can enable virtually all your users and data workloads to access a single copy of your data without impacting performance. Snowflake currently supports AWS, Azure and Google Cloud.
Challenge 4 — Multi-cloud management
Managing and maintaining multiple clouds separately can get very complex and time-consuming. Since each cloud ticks differently and has its own intricacies, there is a need for a single pane of glass that provides an abstraction layer to be able to govern, monitor and orchestrate multiple clouds.
Cloud management platforms (CMPs) enable organizations to manage multicloud (private and public cloud) services and resources. This includes providing governance, life cycle management, brokering and automation for managed cloud infrastructure resources across following functional areas:
- Provisioning and orchestration
- Service request
- Inventory and classification
- Monitoring and analytics
- Security, compliance and identity management
- Cost management and workload optimization
- Cloud migration, backup and disaster recovery
- Packaging and delivery
The Gartner Magic Quadrant shown above depicts the current playing field in the CMP space. Although Morpheus Data and Flexera are currently shown to be doing better than the others, this is a very fluid space and each enterprise should evaluate these products according to their specific needs.
Challenge 5 — Security
Having your enterprise security policies streamlined onto a multi-cloud setup can be a daunting task. Each cloud provides different types of security controls, automation, different abstractions and features, which further require different mappings of your security model for each cloud. When you couple that with differences in regulatory compliance across different geographies, things can get really complex.
Unfortunately this is not a problem that you can solve with tools and frameworks — rather by involving your security team in your multi-cloud strategy from the get-go. All the governance around security (network security, data security, application security etc.) must be approved by appropriate stakeholders. It is also recommended to only use cloud services which have been green lit by security and compliance teams.