Every day, I see and hear about new data points that suggest we’re getting the whole hybrid- and multi-cloud story all wrong. It’s a given that stories about the cloud are all about hybrid and multi-cloud deployments, but they’re sparse on just what the terms mean, and that means they’re not particularly useful in guiding planning.
One of my pet peeves is the growing number of stories about hybrid cloud or multi-cloud being “adopted”, as though these models were something that users thought about and planned for. What enterprises say about their own cloud usage is entirely different, and has been from the first.
Hybrid cloud, they say, is the only cloud usage model the majority of enterprises will adopt. They say that they’re not moving old applications to the cloud, or rewriting applications to get them from data center to cloud. What they’re doing is changing the front-end piece of the applications, where the users connect, and the changes are being made by adding cloud-hosted components in front of their data centers. Hybrid cloud.
Multi-cloud is also less a goal than a defense. In the early days of the cloud, enterprises saw it as a single source of failure and a new source of lock-in. Keep those greedy cloud providers honest and have a couple of them in the bullpen to draw on. Interestingly, the number of enterprises who see multi-cloud that way are diminishing annually. What’s replacing them are enterprises who pick different cloud providers for different applications, based on things like geographic coverage or special web service features that would facilitate application development.
The net is that one of the big problems with our conception of hybrid- and multi-cloud is that there’s no real technical definition of what the relationships mean, either at the resource level of at the application level. A hybrid cloud is a resource relationship between a public cloud provider and the data center, and a multi-cloud is a relationship with multiple cloud providers. Neither of these generally accepted views deal with the applications involved, which is a problem because that’s what users are trying to run. That leads to a misunderstanding about what resource relationships should exist.
The public cloud has an advantage in terms of scalability and resilience, when compared to a company’s own data center. It has a disadvantage in terms of security and compliance for legacy applications and their databases, and all the enterprises who have shared their numbers with me say that hosting everything in the cloud would increase their costs rather than reduce them. That’s why the prevailing goal is to divide applications so that the variable, elastic, piece goes in the cloud and the rest stays where it is.
For the great majority of enterprise cloud planners, what’s happening is an extension of existing applications via new cloud components, creating a “hybrid application”. The two pieces aren’t intended to cross back and forth between data center and cloud; the cloud feeds the data center. That creates something I’ll call the workflow integration model.
Workflow integration in cloud applications is characterized by a very loose linkage between cloud and data center (or among clouds). A hybrid application has components that run in the cloud(s), and in the data center, and in general those components scale, deploy, and redeploy within their primary hosting environment. There’s a linkage point where work passes from one environment to the other, but it’s the work that moves and not the applications. This is in one sense a hybrid cloud application, even when multiple cloud providers are used, because the clouds were chosen for specific tools to support specific applications, and there’s limited (if any) direct cloud-to-cloud integration.
The other possible cloud model is the hybrid pool model, the one most people seem to think dominates multi-cloud (but doesn’t). With this model, there is a pool of resources that’s made up of contributions from the data center and one or more public cloud providers. This hybrid pool then hosts some or all of the components of an application, and those components could in theory move between hosting contributors as they deploy, redeploy, and scale. Workflows move because what they’re linking between has moved.
Hybrid pools are potentially useful for backup of cloud resources, but they pose significant problems for enterprises. The need to run the same stuff on multiple clouds means accepting a kind of web-service-lowest-common-denominator in terms of custom application-building tools. Changes in workflow created by multi-cloud deployment of components can create a lot of random and uncontrolled “border-crossing” events and require a much more general strategy for interconnecting the clouds for application traffic than a static gateway would. There’s also a potentially enormous financial downside because traffic flows in and out of the cloud are often a cost item, so it’s hard to price out this approach with any conviction. This doesn’t mean that multi-cloud isn’t useful, of course, only that most enterprises will adopt it not as a hybrid pool but as a set of parallel front-ends.
Current coverage of multi-cloud suggests that 1) it’s a hybrid pool, and 2) that it’s different from hybrid cloud. In most cases both those suggestions are wrong. Most multi-cloud will use the parallel workflow-integrated hybrid cloud model, but with more than one provider. Most of what enterprises need to do for multi-cloud will be based on their hybrid-cloud approach.
A final complicating factor is the growing conflation of “containerized” and “cloud-native” in terms of application structure. Containers are a general hosting strategy whose benefit is management of dependencies, thus improving the ability to host something more portably. Cloud-native is a program architecture that maximizes a component’s ability to be scaled or redeployed in case of failure. If we start thinking that containers equal clouds, we could end up backing into the hybrid pool model, and at the same time lose focus on the cloud-native techniques that would really maximize cloud benefit.
The net of this is that we’ve come to think of hybrid- and multi-cloud as complete architectural descriptions, even as goals, when they’re a hosting configuration byproduct of good application design in a cloud-capable world. They aren’t. One is a description of what enterprise cloud adoption has been all along, and the other is a byproduct of the fact that cloud providers have sought differentiation by providing their own set of web-service-based application tools that draw a different mix of applications to each cloud. It’s this underlying trend that should be watched, because the fight for differentiation continues.