Cloud Strategy: Key Considerations for Multi-Cloud
This blog is part of my cloud strategy series and talks about different patterns that could be used to decide which multi-cloud path your organisation could take.
Various researches show that organisations are thinking beyond a single cloud and multi-cloud adoption is on an uprising trajectory. Let’s discuss these options and their pros-cons:
Ad-Hoc: Everybody is free to take which cloud they want for their next workload. This show lack of strategy, governance, decision making process and enterprise architecture control. This could be due to excessive vendor influence. Although this is not a go-to-strategy in the longer term but could be accepted for quick cloud adoption if the cloud strategy is taking too long to shape up. This should be taken as an opportunity to shape up your strategy and decide how you should utilise cloud platform but not for too long else a cloud-lock-in would set in place which would be very difficult to move away from.
Best-Fit: This pattern is useful when you decide on a particular cloud platform on the basis of particular strength of a cloud vendor for the required capability eg, GCP for analytics, Azure for data architectures or any other combination you see fit. Other factors could be cost, regulatory concerns, latency, ESG concerns, maturity of a service or the vendor relationship.
There are a few pitfalls to avoid too: whatever decision you take, it should be evidence based and long lasting else you would end up in Ad-Hoc category. Another big factor would be to not just look at individual service but look at the cloud as a whole as cloud generally works as an ecosystem and global optimisation is an important factor. You should also ensure that there should not be too much cloud fragmentation in the same business area, and also that one cloud should not become too heavy (95% AWS but Azure is only 5%). Such situations would impose undue skill requirements.
Preference-Based: Central IT in large organisations usually prefer to have relationships with all cloud vendors and may decide to use a particular cloud vendor a specific business unit or team. This also helps in negotiations and avoid lock-in with a particular vendor. This options differ from Best-Fit in the way that the fragmentation would be low in this case and IT would ensure that there is significant and even presence across vendors.
This is a good choice in the starting phases of cloud adoption as teams can experiment and have the option to switch.
Portable/Interoperable: Cloud platforms, although highly resilient and available, can have expected downtimes, and these cloud incidents are on rise. To protect your workloads, usually you would have a DR site running in a different region on the same cloud platform but sometimes one region has cascading effects on other regions too, eg AWS us-east-1 region has many global services which are required by other regions. Another factors is that once a region is down, all tenants rush to another region, thus putting it under stress and subsequently bringing it down.
- Data Portability
- Platform Interoperability
- Application Portability/Interoperability
- Management Interoperability
Another advantages of taking this approach is reduced lock-in, ability to move to a different region because that region is running on greener electricity, or because you want to shift the spike traffic to another region.
In this mode, you are able to port your workloads and data to another region using automation and abstraction. This scheme works when your workloads are running on open source technologies like Kubernetes, MySql/Oracle type DBs and using as few native services as possible. If you are using cloud specific services or database, then you would need to write the abstractions which would make the architecture even more complicated.
You should ensure that there are valid reasons to take this approach like availability requirements. Sometimes sticking to open source technologies stops you from taking advantage to the cloud native services and puts you at a disadvantage. You should also see which parts of your architecture need this pattern and whether it would be cheaper to have the cloud specific architecture on each cloud instead of writing wrappers to make it compatible. These last options force you to look at another option which should be consiedered over the Portable one.
Parallel-Run: This is when you run different parts of your workload on different cloud platforms. This differ from Portable in a way that Portable runs the whole workload on a single cloud and makes it portable to be run on other cloud as a whole. This may be needed in case of Data Lakes when you need seamless movement between clouds in case of an incident while not compromising on availability. This one also needs lesser coupling with the underlying cloud platform which could be achieved in teh follwing ways:
- Use cloud specific common services like IAM, CI/CD, or common products for monitoring, security etc. But the idea is to decouple these non-core services from your code business logic
- Use open source components like Kubernetes which are also portable across platforms. Choose the vanilla kubernetes over cloud specific versions like EKS, AKS, GKS etc
- Use cloud abstraction framework as was proposed in the previous option. This would make the overall architecture complicated and lock-in with this framwork. You should also remember that cloud servives keep getting updates which will never allow your abstraction framework to get stabilised.
- Have a different architecture for each cloud that is optimised for that particular cloud instead of having same portable architecture
This is the best option if your architecture needs minimal RPO and RTO, , needs high availability with minimal downtime and protection against region failures. But you should evaluate all options mentioned above before embarking on this path.
