If you’ve read my blogs or followed me on social media, you know that I am one of VMware’s most fervent cloud evangelists (see “Springing Forward to Solve Problems Related to Multi-Cloud Adoption,” “Reducing the Complexity of a Multi-Cloud Environment,” “Multi-Cloud: What to Expect in 2022,” “The Cost of Cloud, and the Need for a Multi-Cloud Strategy,” and several other posts I’ve authored on the topic). While I’ve spent a lot of time focusing on why we should embrace multi-cloud, I haven’t written much about the common pitfalls and how to avoid them. While our teams at VMware could probably write an entire book on this subject, I thought I’d share some high-level pointers about what to avoid as you consider the move to multi-cloud.
Mistake #1: Jumping in without a comprehensive plan
Like any major business decision or project, adopting multi-cloud requires a well-thought-out strategy. It’s easy to be dazzled by the promise of lower costs, greater flexibility, and the ability to quickly scale without purchasing or maintaining additional hardware. But before you start comparing providers, remember that nothing is consistent across clouds. So be intentional about driving the types of standards and consistency that are important to your business. You can have consistency at the DevSecOps layer, the infrastructure layer, the management/governance/cost layers, the app layer, and more. The Office of the CTO blog features many great posts on these topics. I encourage you to check them out as a first step in your planning process.
Mistake #2: Not considering the need for workload portability
Flexibility is the single greatest advantage of adopting multi-cloud. This includes the ability to easily move workloads to meet changing legal compliance standards, support company acquisitions, or respond to other variables. Of course, these factors may not apply to your situation. It may make more sense to commit to a cloud provider that offers the best-of-breed capabilities for your specific environment. But if you do want workload portability, advance preparation will help you avoid undue time and expense. I recommend reading Martin Hoskens’ excellent post, “It’s Time to Develop a Cloud Exit Strategy,” for a deep dive into this issue.
Mistake #3: Not thinking through the level of abstraction your developers require
As you construct your plan, it’s important to keep your developer experience (DevX) in mind. How important will cross-cloud standardization be in your environment? How much differentiation do you want to expose? I recommend investing in a modern application platform (such as VMware Tanzu) that gives you the freedom to create the experience that works for your business.
Mistake #4: Living in the present
While many self-help gurus advise “living in the present,” (looking at you here, Deepak Chopra!), this guidance definitely does not apply to multi-cloud adoption. Try to anticipate the level of flexibility you’ll need in the future. Do you think you’ll want to expand to a new cloud provider? Provide compute at the edge? Support a certain type of app? Thinking through these questions today will help you architect your solution to support your current needs and position yourself for tomorrow’s.
Mistake #5: Not assembling a multi-disciplinary team
Adopting multi-cloud will touch many areas of your company — far beyond the IT department. Stakeholders will include your finance and legal departments (since subscription-structured contracts are different than hardware purchases), lines of business who may have to tweak code, application developers who should re-focus on cloud-native development, and so on. Duncan Epping’s recent post, “The Key to Successful Multi-Cloud Adoption: A Center of Excellence,” contains some great nuggets of wisdom on this topic.
The bottom line is that multi-cloud is inevitable, so it’s critical to get it right from the start. If you’ve got a question or a tip to share, I invite you to leave it in the comments.
Best,
Kit
From an ecosystem perspective VMware helped tremendously to increase model resolution of local weather forecasting models.
The future field in intentional climate intervention however is controversial as the methods may have unforeseen consequences.
Stratospheric aerosol injection tactics and simulations, solar radiation management through sun shields, cloud whitening, reflective buildings, etc. are typically topics inside a sovereign cloud.
Living in the present – yes, hyperscaler proliferation and/or datacenter-on-satellite as cloud exit strategy – no, please no yet another “oops”.
VMware could take a major business decision to create an own perspective of the necessity of interconnecting tropospheric research institutes, aviatic authorities for stratospheric controlled perturbation, investors and federal law of sovereign clouds.
Lighthouse projects? Please, publish them.