Multicloud trends
This article discusses different patterns and options when deciding multicloud infrastructure setups
The days of having all workload in one data centre are gone. No news up to here. Up to 76% of companies have already adopted multicloud in one way or another, the 2021 HashiCorp State of Cloud Strategy Survey highlights [5]. By 2023, it will be 86%.
You can read many cases of companies moving workload to the cloud, others having 2 cloud providers supported by different architectures, even cases of software companies repatriating workload to private clouds such as Dropbox or hybrid approaches like CrowdStrike and Zscaler.
Having multiple cloud providers and/or private data centre, co-locations or combinations of all the above are the new norm. So, let’s review what is multicloud and hybrid, why are companies doing these, different patterns and technologies to achieve it.
What is multicloud? And what is hybrid?
The term multi-cloud describes setups that combine at least two public cloud providers. However, it can also include private cloud/co-location, in which case it is usually called hybrid cloud. From a terminology perspective, hybrid is a specific case of multicloud.
The following diagram describes the different types of multicloud setups:
Different multicloud patterns and trends
Within the different multicloud setups, you can find different patterns:
- Extending on-premise private computing with a public cloud provider
Usual case: companies having mainframe workloads on-premise that are expensive to migrate to the cloud, or substantial capital invested in hardware in an owned or co-location. And trying to modernise their IT capabilities to achieve more frequent releases, reduce IT capital expenditure, gain capabilities in certain areas such as analytics leveraging cloud platforms.
- Running segmented solutions in different clouds
Case A: CRM (e.g. Salesforce) on one cloud, Emails/documents in a second one (e.g. O365, Gmail), HR/finance (e.g. SAP) systems in another. Different products/services provided by different suppliers, leveraging the best in each class.
Case B: running the development pipeline in azure, production in AWS, data analytics in GCP. Picking the best option for each stage of the pipeline/journey.
- Load balancing between different clouds with an active/active solution achieving high availability
Case: Need to achieve high availability, so an active/active solution may be the solution. The complexity of having this setup may offset the benefits. So having different regions/AZ within a provider should be better in the majority of the cases.
- Running entire solutions in different clouds, and being able to shift easily between clouds. Portability being paramount.
Case: Need to have the option to switch between providers when required for different reasons. I see this case less common and not worthwhile in my opinion.
- Repatriation of workloads to a self-run infrastructure
Case: One of the most well-known proponents here is Dropbox, which in 2016 scaled back on a long-term relationship with AWS and built its own data centres. For big software companies, where the total cost of revenue (COR) or cost of goods sold (COGS) is eating a significant portion of the revenue, then it starts being important to control this cost [4]. I see this as a trend but not the major trend, other cases adopting a hybrid approach are CrowdStrike and Zscaler.
I believe the repatriation topic deserves a whole article in itself, so I leave it here for now. Reference [4] dives into this topic.
Business drivers and constraints: why are we doing it?
Common drivers and constraints to select different setups/patterns take into consideration the following [2]:
- Reducing capital expenditure or general IT costs
- Increasing flexibility and agility to respond better to changing market demands
- Building out capabilities, such as advanced analytics services, that might be difficult to implement in existing environments
- Improving quality and availability of service
- Improving transparency regarding costs and resource consumption.
- Data sovereignty laws and regulations
- Avoiding or reducing vendor lock-in / migration costs
How to assess workload migration?
In order to assess these decisions consistently and objectively, consider categorising and scoring workloads by opportunity, risk, and technical difficulty [2].
Best workloads to capture business opportunities:
- apps that need to change frequently due to competitive market conditions
- differentiation and innovation are important
- TCO is relevant for the business
- availability, resiliency, security, and/or performance gains
There are also migration risks:
- legal and regulatory requirements
- migration outages
And technical difficulties:
- size, complexity, and age of the application
- app dependencies
- licensing issues
- specific versions, OS, HW dependencies
Building your own abstraction layer on top of cloud
An approach that has been tried by big companies is building a layer of abstraction on top of the cloud platform. Seems reasonable when you hear the idea first time, having the ability to add extra special sauce on top of the cloud provider may seem like a differentiator. However, most likely it will undo the inherent benefits cloud is bringing.
Picking the higher level of abstractions usually brings most of the benefits. For instance, thinking about EC2 or Lambda functions. Going ahead with EC2 means extra effort to patch your instances, upgrade servers, etc. Meanwhile, lambda comes with a ready to consume and scale solution. All we need is the source code.
References
- [1] Multi Cloud Architecture: Decisions and Options by Gregor Hohpe
- [2] Hybrid and multi-cloud patterns and practices by Google Cloud Architecture Centre
- [3] Infrastructure & Ops Hour: Multicloud with Gregor Hohpe and Sam Newman
- [4] The Cost of Cloud, a Trillion Dollar Paradox by Sarah Wang and Martin Casado
- [5] HashiCorp State of Cloud Strategy Survey
Disclaimer
This is a personal article. The opinions expressed here represent my own and not those of my present or past employer/s.
