Some considerations for Multi cloud strategy

Though there has been wide ranging discussion on multi-cloud strategy, and I have also written about it. This is a refresher note based on recent conversation, in which the team was contemplating "portability" capabilities to be thrive in the multicloud landscape. My view was portability is not required, but approach technology debt management effectively.

• Multicloud is a reality for most enterprise clients as part of their cloud computing continuum.? The workload placement in multicloud would be decided based on workload requirements.
• Enterprises need to have “orchestration” and “interoperability” capabilities to manage the multicloud landscape.

1. Cloud portability is extremely difficult to achieve, may not be required, and it would not be a right enterprise architecture decision.
2. Each cloud provider has intrinsic capabilities, and they would differentiate their services at design and implementation levels though at capability level it would comparable [like in-memory cache service, it is not viable to create an abstraction layer above cloud service and use it.]
3. Even with SQL92 standards, which was supposedly profound and everyone rallying behind it, we never got to write an application which can work across Oracle, SQL Server, DB2 and Sybase unless it came down to minimum common denominator. [essentially leaving out most of database engine features]
4. Today, with time to market pressure, it is appropriate for enterprises to make good decision in the current context and choose one cloud provider for a workload.

• Technology will evolve, and decision made earlier with workload placement on a particular cloud would change, [may be regulation change, necessitates an application to brought back to private cloud or there is a superior technology from a provider, which can make application richer] all of these should be treated as technology debt and included in the continuous improvement budget to manage the changes as needed.
• Portability is incredibly tough and expensive to build.

1. Layers – Infrastructure, Platform, Application, Management tools, Developer tools and Security tools. [Portability needs to be engineered for all these layers. K8s deployment solves only a small portion of portability requirements]
2. Toolset – there are not enough mature tools in the market which can work across all clouds (public, private and SaaS) for management, development, and security which is cost effective and does not increase operational complexity
3. Skillset – Building a multicloud management practice with required toolset, requires engineering talent on par with digital native companies. Typical enterprise customer may not be able to attract and retain these talents.

• Situation that forces exit from a cloud provider,

1. Few regulators ask for flexible hosting apart from chosen cloud service provider - This does not require instantaneous portability, but more an exit plan in about 12 months.
2. Change in partnership model or dramatic change to commercial models – Need to have a plan at strategy level, but budget allocation for implementation would be invoked should an event like that happen. [It is not worthwhile in engineering to build capabilities for instantaneous portability, when the need is for eventual portability.]
3. Mergers and acquisitions – Merged entity might like to consolidate on a set of cloud provider(s).? Budget for implementation would be part of the merger cost, so there is no need to plan a prior, and may not be possible either. Having portability in the IT landscape does not have any positive impact on the M&A discussion either.

So, the right way forward is,

• Define the Cloud computing continuum.
• Arrive the most suitable workload placement across the continuum, with considerations on compatibility, capability, compliance and cost.
• Engineer the multicloud management capabilities with focus on orchestration and interoperability.
• Actively manage the workload placement as technology debt