The Multi-Cloud Future (4) — Five Patterns To Get You To Start ‘Thinking’ Multi-cloud
To do multi-cloud, you should first ‘think multi-cloud’. Here are five patterns that can get you to start ‘thinking’ multi-cloud.
This is the third part of the “The Multi-Cloud Future” series. You can read the first part — Why Just “Cloud” and Not “Multi-Cloud” Will Impede Your Business Growth. Second part — Why Exactly Should You Adopt Multi-Cloud?. Third part — To Do Multi-cloud, You Should First ‘Think Multi-cloud’. Now read on…
In the previous edition of this series, we discussed why multi-cloud is a new thought process and not just another technology. We also discussed why having multiple clouds is not the same as having or leveraging a multi-cloud strategy.
While we’ll get into more details about the four pillars of multi-cloud strategy in the next post, this edition focuses on giving you a bird’s eye view on how a fully implemented multi-cloud strategy would look through the eyes of application development managers and architects. After all, the successful execution of your enterprise multi-cloud strategy significantly depends on the alignment, adoption and implementation by your application development managers, engineering managers and your architects.
So here are some key patterns. These are some of the common patterns but by no means exhaustive. It is also not uncommon to find multiple of these patterns adopted within the same enterprise.
Patterns of Multi-cloud 1 — Arbitrary Workload Placement
While it may look funny at the outset, there are enterprises where this has worked perfectly. Without naming them — there have been several wildly successful cloud-native enterprises who have taken to multi-cloud like a moth to a flame and have built the foundations of their business with natively multi-cloud-enabled platforms.
Patterns of Multi-cloud 2 — Defined Workload Placement
But what if you were to have more control specifically on your Data Warehouse. You love BigQuery and see that it fits your data warehousing goals better than any other cloud data warehouse platform, and you want to enforce a strategy that any “data warehouse” across your lines of businesses must necessarily leverage BigQuery, while for regular transactional workloads (your website, APIs etc) you leave the choice of cloud to your architects. This is exactly the scenario where this second pattern comes in.
Patterns of Multi-cloud 3 — Choice of Cloud for Specific Workloads
This pattern expands upon the previous one, but takes an outside-in approach. That is, instead of identifying specific workloads and marking them for Cloud 1, you mark them for a choice of Cloud 1 or Cloud 2 but definitely not Cloud 3. And all your other workloads will continue to have an open choice of choosing between all of your cloud providers.
Patterns of Multi-cloud 4 — Replicated Workloads
One of the major benefits of having a well laid out cloud strategy is to address cost effectiveness and risk mitigation by leveraging a different cloud platform for backups and Disaster Recovery. I’m aware of large financial services enterprises who started their cloud journey by replicating on-premise workloads to a cloud to act as their DR site. This reliable DR strategy also helped them warm up to cloud, get their operations ready for a cloud-driven future, and gradually take steps towards migrating several hundreds of petabytes of data to cloud over the following years.
Patterns of Multi-cloud 5 — Portable Workloads
Another key benefit of multi-cloud as a risk mitigation strategy is to be able to make your workloads to be container-ready or containerize by design. Technologies like Google Kubernetes Engine and Anthos give you the ability to take any workload from any cloud (or on premise) and seamlessly port them to another cloud platform.
In this post, we discussed five common (but not exhaustive) patterns enterprises tend to adopt from an application development and architecture perspective. In the next post, we’ll resume diving deeper into the four pillars of multi-cloud thinking.
