In recent years, especially during the COVID-19 pandemic, there has been a huge shift in cloud and cloud-native ways of working, as organisations realise their need for more flexibility and stability.
Global end-user spending on public cloud services is forecast to grow to 332 billion in 2021 at a yearly growth of 23%.
Whether your organisation has already made a move towards cloud or is just considering it, one of the biggest determinations is how you’ll go about it. What cloud providers will you use? And will you choose to utilise a single, multi or hybrid cloud model?
This blog defines a multi-cloud approach and its potential advantages as well as disadvantages. And, for those who are required to take a multi-cloud approach or otherwise determined that multi-cloud is right for them, how to realise success with your multi-cloud approach.
A multi-cloud architecture utilises more than one public cloud, each of which are operated in an integrated way. To understand multi-cloud, here is how hybrid and single cloud architectures are defined, in comparison:
It might be tempting to use multi-cloud to balance applications, and therefore risks, between multiple cloud providers. If something happens within one cloud, you have the option to move everything to the second one, right? It’s a natural assumption, but it doesn’t quite work like that.
Each cloud provider operates in a completely different way, even at a basic infrastructure level. For a start, the APIs are fundamentally different even further down from that, image formats aren’t the same.
Because each cloud provider operates in a different way, managing services across multiple cloud providers isn’t simple.
Without the specialist teams (and time) required to manage services across your cloud providers, you run the risk of racking up a whole host of additional costs.
There’s a certain level of flexibility that’s afforded in selecting the right set of services that fit your application, across multiple clouds.
Depending on your industry and the regulations that apply, you might have a compliance obligation that mandates a multi-vendor strategy. If that’s the case, the vendor choice that a multi-cloud implementation provides is a valid reason to pursue it.
According to IDC’s 2021 research:
“While many financial services organisations in Europe still tilt toward an all-in-one cloud approach — citing management simplicity, benefits of deeper integration, and attractive cost structure — this view is increasingly challenged by regulators looking for solutions to avoid cloud concentration risk.”
If you’re in a global business that needs access to several specific markets, a single cloud provider might not be able to give you access to all of the localities that you need.
Because of the low barrier to entry for different regions within cloud providers, it allows you to be more experiential in the way that you pursue geographically distinct businesses. If your experiments fail, you can back out with very little time and energy spent.
So, again, this is a valid reason to pursue multi-cloud.
But it doesn’t just have to do with testing new markets. Some countries have very strict data sovereignty laws, meaning that you must locate your workloads close to the customers whose data you’re going to be processing.
If you're doing business in those geographies, you might need regions that are within the geopolitical borders of that country. And if your primary cloud provider doesn't provide that, it would make sense to branch outside of that with a secondary cloud.
If you've examined your business use cases and determined that multi-cloud is the right direction for you, the next question is: What steps do you need to take to take advantage of multi-cloud capabilities?
Firstly, you need to embrace cloud native technologies and ways of working. ‘Cloud native’ as a term has been used and abused in the industry and suffers from lack of one, streamlined definition. For the sake of this document, and from Appvia’s perspective, our understanding of cloud native aligns with how the Cloud Native Computing Foundation (CNCF) defines it: The CNCF defines cloud native as technologies that empower organisations to build and run scalable applications in modern dynamic environments such as public, private and hybrid clouds.
It’s important to note that the use of multi-cloud is implied here. The definition continues to explain, “containers, service meshes, microservices, immutable infrastructure and declarative APIs exemplify this approach. These technologies enable loosely coupled systems that are resilient, manageable and observable.
Combined with robust automation, they allow engineers and operators to make high-impact changes frequently and predictably, with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open-source vendor-neutral projects.
We democratise state-of-the-art patterns to make these innovations accessible for everyone.”
To take this one step further, the CNCF breaks down cloud native into five technology categories. Each of these categories represents an aspect of your application that must be addressed in order for your business-critical functions to operate in a cloud native way and to be able to seamlessly take advantage of multi-cloud capabilities. Those five categories are:
As you approach your multi-cloud journey, you will need to learn from all five of these categories.
There’s a huge amount of variety within each category, and many projects that seek to solve each aspect of the ‘cloud native puzzle’. It’s up to each organisation to select which technology best aligns to your business use cases. The industry has adopted Kubernetes and containerisation as the primary method or vehicle to make multi-cloud accessible within the enterprise. This is seen not only in the velocity and size of the Kubernetes project, but also in its widespread adoption across all industry verticals.
The CNCF’s 2020 survey found that 78% of respondents were using Kubernetes in production.
Earlier, we mention that one reason to stay away from multi-cloud is to de-risk it because clouds fundamentally don’t work in the same way. Kubernetes and containers address this concern by providing a common set of APIs and abstractions that can run in any of the cloud providers, allowing you to seamlessly port your application from one cloud to the next.
In this sense, Kubernetes is a way to provide those abstractions and make multi-cloud work for you, but it’s something that you need to bring along yourself; it’s something that you need to enable, the cloud providers aren’t going to do natively out of the box. That’s the reason Kubernetes and containers are so important if you’re pursuing multi-cloud.
Looking at Kubernetes and its many moving parts, in addition to the other aspects of the cloud native landscape, the options can seem overwhelming. But there are opinionated platforms that 1) address the technologies that you're going to need and 2) provide a structure where interdisciplinary teams can work together in a defined streamline process to unlock the true value of multi-cloud.
One way to look at it is this: The landscape with all of its projects, combined with the services provided by public cloud providers are like hardware stores. They have all the raw materials and building blocks that you need in order to build the applications and services that drive your business forward. But, much like a hardware store, these are simply raw materials that often don't come accompanied with blueprints of how to assemble them into the form or structure that you need.
Opinionated platforms address this problem by providing a structure and a blueprint for how to put them together. That really is the value of multi-cloud Kubernetes platforms. They make functionality accessible immediately, without your teams having to learn how to handle all the raw materials in the first place. They make adoption simple.
One example of these multi-cloud Kubernetes platforms is Wayfinder. Its core design addresses the four key areas of multi-cloud adoption that we find to be critical: speed, security, scalability, and sustainability.
Speed provided through self-service mechanisms and frictionless deployment of applications and services, including Kubernetes clusters.
Security provided through enforcement of least-privilege operations and mechanisms to ensure that your security posture in each cloud environment does not drift over time.
Scalability by providing automated workflows, and the ability to reduce bottlenecks between teams. This is achieved through the definition of plans and policies that define what developers can request and when.
Sustainability by making day-2 operations as simple as requesting the resource in the first place by providing automated cluster maintenance and cost reporting/attribution back to the individuals or teams who requested the capability in the first place.
Once your organisation has cloud-native technologies, patterns and ways of working in place, you can then begin to use multi-cloud as a way to solve your business problems. Increasingly, organisations are capitalising on multi-cloud as a way to address complex regulatory concerns.
Such concerns might consist of multi-vendor mandates through legislation that are intended to mitigate vendor risk and provide continuity of service in the event of vendor acquisition failure or change in service level. This is often within the government space, but also occurs within healthcare. A side effect of this multi-vendor mandate, which is integral to multi-cloud adoption, is that it also provides you access to a wider variety of services, enabling you to address a larger feature set which, if applied correctly, can simplify your application design and implementation.
Another compliance issue that multi-cloud can address is regionalisation. For multinational organisations doing business in multiple geographies, it is not uncommon to encounter different data sovereignty and data protection laws in each geography. Most large countries have enacted their own data privacy and data sovereignty laws, and they can vary widely. Some take a geographic approach and define their authority by the geographic borders of the country, and mandate how data must be processed within the geographic borders of that governing entity. Others define how data from citizens of that country must be processed, regardless of whether or not the data is actually conducted within the geographic borders of that country.
GDPR, one of the most notable examples of this privacy legislation, dictates that regardless of the point of processing that the users data must be handled in a consistent manner consistent with the GDPR regulations as well as the home country of origin.
In the United States, regulations often apply to specific industries, such as SEC, Sarbanes-Oxley or HIPAA. Organisations seeking to do business in China, often find a new set of regulations that are even more restrictive.
46% of U.S. organisations named “compliance (beyond the GDPR)” as their highest priority.
When you consider this landscape for growing, diverse multinational corporations, having the ability to select vendors who are capable of complying with local compliance obligations and meeting regulatory concerns as the organisation or company expands is critical. Multi-cloud empowers this capability.
Implementations using multi-cloud are extremely powerful in addressing complex issues of growing multinational organisations. But multi-cloud adoption doesn’t come easily and shouldn’t happen without strategic consideration.
Multi-cloud requires deliberate implementation of cloud native technologies, ways of working and platforms that simplify their operations. Without this, organisations pursuing multi-cloud capabilities to satisfy their business or regulatory concerns could easily find their investment squandered by failure to launch or limited return because of complexities and transitions in skill set.
