Last year, at Re:invent, Amazon AWS launched Outpost and finally validated the concept of hybrid-cloud. Not that it was really necessary, but still…
At the same time, what was once defined as cloud-first strategy (with the idea of starting every new initiative on the cloud often with a single service provider), today is evolving into a multi-cloud strategy. This new strategy is based on a broad spectrum of possibilities that range from deployments on public clouds to on-premises infrastructures.
Purchasing everything from a single service provider is very easy and solves numerous issues but, in the end, this means accepting a lock-in that doesn’t pay off in the long run. Last month I was speaking with the IT director of a large manufacturing company in Italy who described how over the last few years his company had enthusiastically embraced one of the major cloud providers for almost every critical company project. He reported that the strategy had resulted in an IT budget out of control, even when taking into account new initiatives like IoT projects. The company’s main goal for 2019 is to find a way to regain control by repatriating some applications, building a multi-cloud strategy, and avoiding past mistakes like going “all in” on a single provider.
There Is Multi-Cloud and Multi-Cloud
My recommendation to them was not to merely select a different provider for every project but to work on a solution that would abstract applications and services from the infrastructure. Meaning that you can buy a service from a provider, but you can also decide to go for raw compute power and storage and build your own service instead. This service will be optimized for your needs and will be easy to replicate and migrate on different clouds.
Let’s make an example here. You can have access to a NoSQL database from your provider of choice, or you can decide to build your NoSQL DB service starting from products which are available in the market. The first is easier to manage, whereas the latter is more flexible and less expensive. Containers and Kubernetes can make it easier to deploy, manage and migrate from cloud to cloud.
Kubernetes is now available from all major providers in various forms. The core is the same, and it is pretty easy to migrate from one platform to the other. And once into containers, you’ll find loads of prepared images and others that can be prepared for every need.
Multi-Cloud Storage
Storage, as always, is a little bit more complicated than compute. Data has gravity and, as such, is difficult to move; but there are a few tools that come in handy when you plan for multi-cloud.
Block storage is the easiest to move. It is usually smaller in size, and now there are several tools that can help protect, manage and migrate it — both at the application and infrastructure levels. There are plenty of solutions. In fact, almost every vendor now offers a virtual version of its storage appliances that run on the cloud, as well as other tools to facilitate the migration between clouds and on-premises infrastructures. Think about Pure Storage or NetApp, just to name a couple. It’s even easier at the application level. Going back to the NoSQL mentioned earlier, solutions like Rubrik DatosIO or Imanis Data can help with migrations and data management.
Files and objects stores are significantly bigger and, if you do not plan in advance, it could get a bit complicated (but is still feasible). Start by working with standard protocols and APIs. Those who choose S3 API for object storage needs will find it very easy to select a compatible storage system both on the cloud and for on-premises infrastructures. At the same time, many interesting products now allow you to access and move data transparently across several repositories (the list is getting longer by the day but, just to give you an idea, take a look at HammerSpace, Scality Zenko, RedHat Noobaa, and SwiftStack 1Space). I recently wrote a report for GigaOm about this topic and you can find more here.
The same goes for other solutions. Why would you stay with a single cloud storage backend when you can have multiple ones, get the best out of them, maintain control over data and manage it on a single overlaying platform that hides complexity and optimizes data placement through policies? Take a look at what Cohesity is doing to get an idea of what I’m saying here.
The Human Factor of Multi-Cloud
Regaining control of your infrastructure is good from the budget perspective and for the freedom of choice it provides in the long term. On the other hand, working more on the infrastructure side of things requires an investment in people and their skills. I’d put this as an advantage, but not everybody thinks this way.
In my personal opinion it is highly likely that a more skilled team will be able to make better choices, react quicker, and build optimized infrastructures which can give a positive impact to the competitiveness of the entire business but, on the other hand, if the organization is too small it is hard to find the right balance.
Closing the Circle
Amazon AWS, Microsoft Azure and Google Cloud are building formidable ecosystems and you can decide that it is ok for you to stick with only one of them. Perhaps your cloud bill is not that high and you can afford it anyway.
You can also decide that multi-cloud means multiple cloud silos, but that is a very bad strategy.
Alternatively, there are several options out there to build your Cloud 2.0 infrastructure and maintain control over the entire stack and data. True, it’s not the easiest path and neither the least expensive at the beginning, but it is the one that will probably pay off the most in the long term and will increase the agility and level of competitiveness of your infrastructure. This March, on the 26th, I will be co-hosting a GigaOm’s webinar sponsored by Wasabi on this topic, and there is an interview I recorded not too long ago with Zachary Smith (CEO of Packet) about new ways to think about cloud infrastructures. it is worth a listen if you are interested in knowing more about a different approach to cloud and multi-cloud.
Originally posted on Juku.it