Busting The Multi-Cloud Drumbeat
There is a constant drumbeat about multi-cloud among the pundits, especially the ones who are fans of AWS. Most of them are dismissive of multi-cloud and talk about using one cloud provider (and it is mostly AWS for them). While it might serve as good chatter on social media, it is not going to help the end-users who care about solving problems that matter to their organizations. In this post, we plan to highlight why an argument against multi-cloud is too simplistic and how it is based on FUD.
FUD Against Multi-Cloud
Let us first highlight some arguments made against multi-cloud and explain why it is either FUD or doesn’t make any sense from the enterprise customers' point of view.
Multi-cloud is not cheaper than single cloud: There was never a cost argument for multi-cloud except under certain scenarios. If you are approaching multi-cloud with just cost savings in mind, you may be in for a surprise. While the constant price competition between cloud providers may present you an opportunity to move workloads from one cloud provider to another, it can end up being more expensive. Similarly, using a multi-cloud strategy for use cases like HA will be very expensive. Everyone knows that running different components of an application on different clouds makes no financial or user experience sense. However, if you have the right automation in place or use a platform like the one offered by SpotInst that takes advantage of spot instances, you could definitely save money with the multi-cloud strategy. By default, multi-cloud is not just about cost savings.
Multi-cloud is not more agile: This is another misconception or FUD. The use of multi-cloud comes from the need for flexibility (more about this later) than about agility. Multi-cloud is as agile as using a single cloud provider. With the right DevOps pipeline in place, it doesn’t matter whether you are using one cloud provider or more. The bottleneck could be in having the right talent or training for all the cloud providers but it is no different from training the employees on a single cloud. With the right automation in place and by avoiding the use cases that are not suitable for multi-cloud (eg: HA across different cloud providers), organizations can have the same agility they get with a single cloud provider.
Multi-Cloud is not about depth: One of the arguments made against multi-cloud is that while using multiple cloud providers, developers are forced into using a common set of features. Partly, this is due to the past approach towards multi-cloud where a common library was used which took into account the least common set of features and gave an easy interface for developers to use. That approach failed because these libraries offered breadth but not depth. Today’s multi-cloud approach is different and, it is about taking advantage of unique services offered by different cloud providers than HA/Portability in mind. Developers are encouraged to use the right set of services needed for their applications and, in many organizations, this automatically leads to multi-cloud usage.
So, what is multi-cloud then?
Multi-cloud is about giving developers the flexibility to use any cloud service from any cloud provider for their applications. If my app demands Google’s AutoML, I should be able to use Google Cloud Platform provided I can take the data to the platform. If I have a new app with limited traffic, I may not want to run a database instance continuously either on a container or from a database service. A better way is to take advantage of a Serverless database. I may want to run that app on AWS even if my organization has other apps running on Azure. The key is to give the developers flexibility to use the right service than force them to make compromises on their apps to use the service offered by a specific cloud provider. Multi-cloud provides organizations a lever to empower their developers than constrain them with services from a single cloud provider. Multi-cloud is about flexibility without compromising on agility. Under certain circumstances and with the right tools, it can also save costs.
Ha, the multi-cloud is the magic pill?
At the same time, people should be aware of the real challenges (as opposed to the FUD in the media) with using multi-cloud. I am listing the critical ones but there are other challenges too.
Multi-cloud can create the same problem with shadow IT if the service provisioning is not managed through a central authority but without compromising on user experience. This implies allowing developers to provision directly from the cloud provider on-demand or by providing an API that offers the same cloud provider like user experience
Each cloud provider has different IAM options and, without managing them properly, organizations will end up with a huge governance problem
If security in the public cloud is a problem for any organization, managing security across multiple cloud providers is a bigger problem. Without the right guardrails in place, this will become unmanageable fast
So, what do I do?
At Rishidot Research, we always tell CIOs that it is about giving flexibility to the developers without having to manage complexities. Whether you are a startup or a large organization making a foray into the cloud, start with a single cloud provider giving them the flexibility to use any service they want. If your developers feel that the services are too constraining for their application needs or you acquire a company that is using another cloud provider, allow them to use multiple cloud providers but have the right set of tools to manage the challenges that come with multi-cloud.
Busting The Multi-Cloud Drumbeat was originally published in StackSense on Medium, where people are continuing the conversation by highlighting and responding to this story.