As enterprises plot out their cloud strategies, it’s perhaps less about the final architecture and more about the migration strategy. Companies that started their cloud journey years ago might have private cloud initiatives. Those that are less certain about either their ability to build their own or dump their legacy stuff talk more about hybrid.
But the future for most large companies is probably best described as multi-cloud.
A Quick Note on Why Cloud
It surprises me that there is still a dominant theme out there that cloud is primarily about cost savings. While it is true, for sufficiently small scale, there is likely cost savings to be had, it is unlikely that effectively renting infrastructure is long-term less expensive than owning it at anything beyond even moderate scale.
If your primary reason for moving to the cloud is to save some money and cut your IT expenses even further, good luck with that. I would encourage you to make sure you have instrumented your cost environment very well so you can at least track.
But just because cloud is probably not a cost saver doesn’t mean it isn’t worth doing. Indeed, the agility aspects of cloud make it well worth exploring. The real innovation that most of the cloud properties have pioneered is in their operations, and that means that companies can reap very real benefits in just moving faster. These can sometimes mean faster path to revenue as time-to-deploy is cut, but the benefit can also extend to having personnel focused on value-creating activities rather than keep-the-lights-on tasks.
My only point here is that you should be clear about what you hope to achieve from cloud, and you should definitely make sure you have good benchmark metrics for what you are hoping to change.
Legacy Masquerading as Cloud
The term hybrid cloud is used too much in my opinion. While it can sometimes mean what it implies, too often it is a euphemism for legacy infrastructure riding alongside a public cloud deployment.
It’s not that this is necessarily a bad outcome for enterprises. There is absolutely going to be a transition for those that want to move from non-cloud to some form of cloud. But when evaluating go-forward networking solutions, the notion of hybrid cloud ought to mean that you are somehow more capable of operating workloads across two different clouds: your own private cloud and some public cloud.
The original intent was to have an overarching orchestration solutions to manage workloads that could, in theory, be moved across cloud boundaries. For that to work, it means that there has to be a private cloud that has many of the same properties of third-party clouds. That is to say that it has to be elastic and workloads need to be portable, and it needs to operate without line-by-line configuration management.
But somewhere along the way, people started using hybrid to mask over a modern-but-not-cloud datacenter. This is a mistake, and really it’s unnecessary naming. Having two different infrastructures that act as ships in the night just means you have two different infrastructures. And if that’s what the environment requires, then there ought not be any shame in that. IT is measured first and foremost on making things work. So do what you have to.
Third-Party Cloud, Not Public Cloud
My view on cloud is that we ought to drop the moniker public entirely. There is nothing public about the public cloud. It’s well-architected and supremely well-managed infrastructure, but it’s basically just third-party cloud. Yes, the cloud providers are vendors just like any other vendors are.
There are no benevolent dictators in IT. None of us can be fully trusted with the ring from the Tolkien classic. The temptation to lock in customers and extract higher margins is simply too great. Tactics like data storage and even workload advances like TPUs all serve to capture and hold customers.
Of course, I also don’t think lock-in is as binary as it gets treated in the Twitterverse. If there is enough value to be had, then you pay for it by being a captive customer. That’s a perfectly fine outcome, though both sides should enter into the agreement with eyes wide open, of course.
Treat Vendors Like Vendors
Because third-party cloud suppliers are simply vendors, it means that over time they will be subject to the same vendor controls that all vendors experience. For enterprises to maintain any negotiating leverage, they will ultimately have to move from single-supplier to dual- or multi-supplier. This will stimulate competition, which will keep the balance of power in the enterprise’s favor.
The logical outcome here is that we won’t settle out with every enterprise having selected a single cloud provider. Rather, the larger enterprises that use supply chain leverage strategies will embark on a multi-cloud journey.
Multi-cloud will be first talked about in the same way that people talked about overlays. There will be this view that workloads will move between clouds based on conditions and needs.
While this might be true over some sufficiently long time horizon, it probably isn’t the way things will actually play out in the meaningful future. Our industry keeps making the same mistakes. We offer up a new technology, and then before that technology is even in wide adoption, we quadruple the degree of difficulty. It’s pretty silly, really.
Consider SDN. Before SDN was even broadly adopted, we were already talking about controllers of controllers and multi-domain management. While there are some companies with the skills, resources, and will to make that work, it just isn’t the majority of people. We need to make something work well, and then we can go ahead and make it harder.
So before we start talking about workload portability across clouds, we need to just get people safely into one cloud. In fact, anyone building a business exclusively aimed here better have the funding to stay solvent. The need will absolutely materialize, but it’s going to take a little while.
If the future is going to be multi-cloud and you are not yet through your transition to cloud, it is definitely worth examining how you plan to get to cloud. In the end, how you get to cloud will determine when you get to multi-cloud. And that could be a huge difference maker in the go-forward trajectory for the entire enterprise.
In a multi-cloud world, things like ubiquity matter. You need to be able to do the most important tasks no matter where the workload resides. And ideally, the workflows will be similar or identical. Having hyper-contextual ways of interacting with a set of resources makes changing contexts extremely hard. And if it’s too hard to change anything, then inertia ultimately carries the day, which is counter to the whole intent around multi-cloud.
This statement is true in terms of underlying infrastructure, but also in terms of tools. Visibility and analytics, templates and scripts—they all need to work across different environments. So if you are embracing something like CloudFormations, you ought to look at TerraForms as well. If you are looking at network packet brokers, you should find out who operates in which clouds. The answers are illuminating.
The Bottom Line
As an industry, we need to get from where we are to cloud before we unnecessarily complicate things. It seems unlikely to me that we will get to a point where workloads are freely moving between clouds. I would guess that multi-cloud will mean some workloads are in cloud A and some in cloud B, and the threat of moving more from A to B is enough to keep the suppliers in check.
That said, even if the workloads themselves are not portable, it will be cost prohibitive to build dueling infrastructures. So considering how key tools and underlying devices will support multi-cloud will be important. I would advise everyone to at least ask the questions. If nothing else, it will tell you whether the next change is more evolution or rip-and-replace.