HTBase Blog Multi-cloud Part Deux

Welcome back! So you’ll remember in our last blog we delved into the concept of the multi-cloud; and why organizations might be incentivized to adopt a multi-cloud strategy as a means to avoid vendor lock-in and take advantage resource commoditization. In this blog, we’ll talk about multi-cloud as a marketing term and the nuanced differences between disaster recovery, resource consumption, and application availability.   Head in the (multi) clouds Multi-cloud today has a very nebulous definition. As employees at HTBASE, we have a very clear vision of what multi-cloud means. And as I explain this vision to customers and prospects, I urge them to zoom out, away from the actual knobs and gears of the individual technology components, and to focus on the end-user impact of a given solution or architecture. While in this 20,000-foot view, I believe most technologies fit into 3 buckets with regard to their “multi-cloudiness” (trademarked…). Multi-cloud disaster recovery: This is a pretty big bucket of technologies and one with which I have the biggest bone to pick. Most of these technologies are what I like to call “legacy tech with multi-cloud lipstick”. I’ll explain. The biggest noise I hear in this space has been in traditional data center storage appliances. You take your fancy (old) block or file storage array, take a bunch of snapshots of the volumes and LUNS, and you replicate them to a cloud storage service of your choice; and you manage all of this using a Management-as-a Service portal provided by said storage array vendor. Boom. Multi-cloud. Right? Hold your horses buddy. Multi-cloud is supposed to give me agility, flexibility, and a path to lower costs. You just took my data and put it on the proverbial top shelf of the book case. Yes…it’s safe, but it’s also hard to reach and once I reach it, I can’t use it until I restore it and (re) build my application to connect to it. Oh, and once I recover my primary site…I have to reverse the whole process. Thanks. *eyeroll* In reality, there’s nothing wrong with these technologies. They are valuable as a piece of any overarching multi-cloud strategy. But for these vendors to claim that by simply adding “multi-cloud” to their product literature, your organization becomes multi-cloud, is insulting and disingenuous. Multi-cloud resource consumption: These are a class of technologies that facilitate the provisioning of various cloud resources at the point of consumption. An example: A developer logs into a self-service interface to spin up a new application. The developer is given a choice of “clouds” on which this new application can live. The orchestration platform deploys the application on the cloud platform of choice.   These technologies are indeed multi-cloud enablers. They’ve redefined what is generally acceptable threshold for agility and flexibility. Though they do very little to ensure that deployed applications are highly-available should a cloud service provider suffer an interruption.     The path to a true multi-cloud for the enterprise lies in solving this availability conundrum. Multi-cloud availability: The technologies that fall into this category are very few and far between. Multi-cloud strategies demand agile infrastructure that can be provisioned quickly and over and over again. They should be flexible, so that services and applications can be deployed where they’re needed, when they’re needed. But not a lot of thought has been put into ensuring these applications stay available to their end-users in the event of a cloud service provider outage.   A true multi-cloud strategy that is focused on availability, would allow an organization to deploy micro-services for a given application across public cloud boundaries. An advanced network control plane would allow micro-services running in one public cloud to easily communicate with micro-services running on another cloud. There might even be logic that dictates latency requirements between micro-services that are deployed for the same application to ensure performance requirements are met. Technologies that emphasize application availability while still maintaining the agility and flexibility associated with the cloud represent the next step in the evolution of application infrastructure. This is true multi-cloud. *waves hands like a magician* The post Multi-cloud Part Deux appeared first on HTBASE - Multi-Cloud Control and Data Fabric.