A couple blogs ago, I asked whether there was anything to this cloud-native craze and concluded: We needed cloud-native to get the most from the cloud. Since then, I’ve been talking and working with enterprises trying to confront cloud adoption and expansion, and it turns out their problems are more basic than I’d envisioned. Yes, they want to be a part of the cloud’s glorious future, but right now they just want to get more stuff running there.
Enterprises say they originally thought the cloud was just a form of cheap hosting for current applications. You bought IaaS, and you tossed out a dedicated server that cost more to acquire and operate. That worked for a while, but now enterprises are seeing that some application redesign is needed to advance the cloud from that simple IaaS model. It’s raised a lot of questions.
How do you do “cloud-native?” What are the principles we should apply when designing a cloud application? We hear about “microservices, functions, and serverless.” Then there’s “orchestration, Kubernetes and service mesh.” Even if we have solid definitions of all these terms (many say they don’t), do you need all this stuff? If so, how does it go together? Asking enterprises to construct, deploy, and run applications is something like asking a shipping company to build trucks from parts just to make customer deliveries. More than anything else, lack of understanding of what cloud infrastructure and applications look like is holding back cloud adoption.
A Simple Solution: Cloud in a Box
The solution is cloud-in-a-box, not necessarily under that term of course, but some form of a packaged combination of tools includes everything an enterprise would need to develop and deploy applications built for the cloud. The tools we have for the cloud today are almost always little pieces of the big puzzle, and enterprises don’t like IT strategies that require them to assemble stuff from little pieces. How about a product?
Vendors, of course, have seen this problem. This year, while we’ve had a dazzling sequence of new features and new tools, we’ve also seen some vendors focus on assembling a toolbox from all those tools. That gives buyers a vision of everything they need in one place, at one time, and with one vendor providing support. Perhaps most important, it gives technology planners a path to explaining a cloud strategy to senior management.
It starts with nomenclature. Don’t make salespeople tell prospects they need a dozen different packages just for cloud table-stakes, and for sure don’t take that story to the CEO. Give a name to what they need, and don’t play up the complicated details too much. Red Hat calls their cloud-in-a-box “OpenShift.” IBM calls it Kabanero, and VMware is now calling theirs Tanzu. What any of these names mean doesn’t matter because the name is just a brown paper bag to hold the stuff that everyone needs, and nobody understands it…except for the vendor.
The technical goal of all these cloud-in-a-box approaches is the harmonization of public cloud services with data center applications, without forcing the cloud to adopt the old data-center-hosting model of monolithic applications and servers. That, of course, means providing the data center with a path to the cloud model.
Container technology (remember Docker?) is used in all these vendor cloud packages as the “harmonizer.” Containers are augmented with Kubernetes, the deployment/redeployment orchestrator developed originally by Google, and Kubernetes is enhanced to support multiple public clouds and data center containers in combination. That gives enterprises a solid target for deployment and operations.
On the development side, all of the new cloud packages expect to see applications built by assembling small components—microservices. In the past, microservice deployments were complicated because preserving the resilience and elastic work-handling benefits of microservices meant all kinds of tools to help find where you put a microservice, load-balance among microservice instances that were scaled under load, and monitoring this whole elastic bundle to ensure it was actually working. These are now combined in the cloud-in-a-box offerings.
Impact on Public Cloud, Future of Cloud Migration
While the cloud-in-a-box vendors see their new packages as a way of delivering a simple cloud solution to a confused market, they also have a nice competitive side-effect. If these packages are designed to unify all possible hosting options under one roof, they also tend to weaken the control of public cloud providers. You can get managed containers and Kubernetes services from cloud providers, but they must fit under the cloud-in-the-box umbrella or enterprises don’t have a universal model for cloud development and deployment any longer. The cloud packages could dumb down, and even unify, the features of the public cloud, and put the data center in control.
That’s not so bad, of course. The truth is that very few enterprises will “move to the cloud,” replacing their data centers. The cloud today accounts for less than 15% of IT spending by even the most optimistic measures, according to my research. Balancing this dominance truth is the truth that the data center tends to evolve only under threat. Cloud technology could have been driven by data center players just as easily as by cloud providers, but the data center vendors didn’t want to rock the sales boat. We need a little cloud in the picture to keep from taking root in the past and becoming trees.
We also need some planning guidance. Enterprises might have, in cloud-in-the-box, the perfect framework for built-for-the-cloud applications, but they say they don’t understand what makes a given application a target for cloud-native technology. Will our cloud-in-the-box vendors provide that or will we still need the cloud providers to drive planning insights home in CIO organizations? If they can do that, what’s to stop them from coming up with their own cloud-in-the-box stories? It could be an interesting year ahead.
