Why Multi-Cloud Is Here To Stay
Industry analyst Gartner recently published its latest ‘Magic Quadrant’ analysis of the top Cloud Infrastructure and Platform Services. The survey outlined who’s ‘up’ and who’s ‘down’, and provided the key take-away that the cloud sector is still evolving, and is highly competitive.
In other words, it’s not sufficient to just pick one of the Big Three (AWS, GCP and Azure), and off you go. Instead, it reminds us that as IT customers, the landscape could be very different in a few years’ time—if only because Gartner identifies new players emerging, even in that critical ‘visionary’ corner of the Quadrant.
For anyone serious about using cloud as a true enterprise platform, what should really stand out is that no cloud is perfect for everything. The era of acceptance that you need a multi-cloud strategy is now here.
Don’t put all your cloud eggs in a single cloud basket
In other words, no matter how great or functional IBM Cloud is versus GCP, or AWS is versus Huawei Cloud, for handling certain problems, you should always keep your options open. It’s far better to tactically use certain clouds for certain apps, in a specific region of the world, as required.
Why? Well, Gartner’s report says that not all your needs will always be met by even the strongest supplier. So it would be wise to not put all your eggs into one big CSP (Cloud Service Provider)’s basket.
The clue is in the phrase, ‘All your eggs in one basket’. Enterprise CIOs do not want to repeat the same mistakes or expose themselves to the same risks they had with on-prem in their new, clean cloud paradigms. Among these risks are data sovereignty, but probably more importantly, the danger of concentration risk (and all it entails operationally) and vendor lock-in, which combines operational danger and financial risk.
Let’s break this down further.
Why is data sovereignty an important driver to being open to a multi-cloud strategy? Simple: if you, as an international business, need to satisfy the requirements for data sovereignty in different territories, you need to use different providers in different territories to be compliant with local or regional privacy regulations. Best practice is to have at least three failure zones to guarantee availability. So, for multi-geography data sovereignty, you may need different levels of support from different providers in different sovereignty regions.
Don’t get caught out by the IaaS-PaaS distinction
Next up is concentration risk, a term you’ll be familiar with if you are in banking, but also relevant to other industries. In April, as part of new draft supervisory statements, the Bank of England flagged tough new rules to promote IT resilience.
You can’t just put all your main systems onto one platform and expect it to never fail, because life just isn’t like that. Just three cloud providers hold over 70% of the market. So, financial services are being advised to share their cloud service requirements across multiple providers to reduce the risk of failure.
This warning should represent good sense to any CIO, let alone ones in a tightly regulated industry like financial services. But, system crashes aren’t the only risk here; lock-in is perhaps an even bigger problem.
What might puzzle you is that moving to the cloud should surely end over-reliance on one vendor. “I don’t buy all my servers or software from the same source anymore, and I have all that positive open source choice going for me, right?” The reality is that the Big Guys saw this one coming. They are very happy to provide you with the basic ‘infrastructure’ as a service, IaaS, but they figured out that they could package additional functionality nicely with ‘platform’ as a service, PaaS.
The pitch is that PaaS is going to make your life easier and simplify your app decision choices. By putting it all behind the famous ‘single pane of glass’ control, you’re more inclined to stick with them—and pay their fees and sign their long-term contracts.
There is a real danger that you end up trapped by uncompetitive, expensive, or proprietary services that in practice aren’t that different from The Bad Old (pre-cloud) Days. If you decide to go from AWS to Azure, or vice versa, it will not be just a case of lift and shift; there will be complexity and cost involved in moving.
Avoiding moving in the first place by judicious initial placement of your business app ‘eggs’ gives you the data sovereignty, avoidance of concentration risk, and flexibility that the cloud is, and always should be, about. But, there is a final restriction here that may hinder your ability to be a truly agile multi-cloud player; your database.
What I mean here is that, today, nearly all cloud services are horizontal. Take Kubernetes for example. This is a fantastic open source containerisation solution that many developers see as their go-to system, no matter what cloud they’re working in. It makes it simple to develop, test, deploy, extend, and scale your app.
How to get the true cloud independence that multi-cloud requires
The database is the cloud’s hidden problem. You can’t just pick up your database from one cloud and run it on another. Well, if it is the engine for a simple process, you probably could, and could hack it with NoSQL—but very soon, you’d have issues around transactional consistency and challenges with scaling.
The only databases that are open to multi-cloud and can help with cloud migration easily have many limitations. This means you default to Cloud Service Provider X’s solution, locking you in and throwing away any benefits.
The problem the market faces is that cloud-native transactional databases just haven’t developed at the same pace as other technology. There hasn’t been a Kubernetes equivalent for data. Neither NoSQL databases or monolithic SQL databases will deliver the true cloud independence that multi-cloud requires for your operational use cases.
Even in 2022 there are still issues with many databases, especially when you need transactional consistency. While there are various things that you can try and fudge around, the only real way to make multi-cloud multi-databases work is by using something like open source distributed SQL. A prime example of this database is my company’s approach to tackling this problem, YugabyteDB.
To sum up, Gartner recognises that the dynamism of the cloud market should be welcomed, but it should also act as a reminder that multi-cloud can’t fully succeed until that last frontier of the cloud—database—is properly catered for.
