A lot of what we talk about in technology seems more conceptual than real. One area where the distinction is really important and really vague is the cloud. It’s like “the Internet” in a sense; it’s a vague overarching something that we can get on, but how do you build it or build stuff for it? Mystery. Hybrid cloud is even worse because just talking about it means we must accept that there’s not just a cloud, but a cloud that is mated with something else.
The truth is that hybrid cloud is likely the only cloud that really matters. What the “concept” means is that you build applications designed to run partially in one or more public clouds (Amazon, Google, IBM, Microsoft…you get it) and partially in the data center. That’s exactly what nearly all enterprises want, not cloud by itself. The problem is that a real hybrid cloud would have to be somehow written to run like that because software runs on something specific. In programming terms, we know servers and clouds, but do we know hybrids?
There’s a lot of vendors out there, suddenly, who want to show us hybrids. IBM, who bought Red Hat in large part to get a position in modern open-source cloud software, has made it clear that they consider hybrid cloud to be an architecture, something you can build to and that products (IBM/Red Hat products, of course) can then implement. They say that they were leaders in hardware, software, and middleware. The fourth area of architecture leadership is hybrid cloud.
Cisco, Amazon, Dell/VMware, Google, HPE, Juniper, Microsoft, and just about every other significant IT or enterprise network vendor has also discovered hybrid cloud. You could hope that all the attention the idea is getting will result in a nice, clear explanation of just what that hybrid cloud architecture is. Doubtful, so let’s try it on our own. To do that, we must investigate the future of hybrid cloud architecture, then explain why we’re not there yet.
A program is written to a platform, which is a set of foundation hardware, database, network, and other primary tools, presented through a series of APIs. Linux has APIs, and so does Microsoft’s .NET architecture or IBM’s database technology. Programs don’t really know hardware or software tools; they know APIs. If data center systems and cloud provider hosting use different APIs (which they do), then your applications can’t move easily between the two.
The solution to this is a hybrid cloud architecture (HCA for short), which is a kind of virtual hosting environment. Applications use the HCA APIs, and the HCA implementation then maps those APIs to the hosting-specific APIs of the data center or the public cloud. Now applications and their components don’t care where they’re running. The HCA implementation can then take care of making the network connections, passing work along, scaling under load, replacing stuff — it can make a hybrid cloud of infinite complexity into something that looks like a single computer.
We don’t have an HCA implementation like this, for one reason because nothing would be written to run on it. We have data center systems and decades of development specific to them. We have new public cloud development that’s specific to the cloud provider we’re using. This natural division of application software encouraged the market to build our HCA implementation from the bottom up, and we’ve not reached the top yet. We still tend to create applications that divide explicitly between the cloud and the data center, and our “hybrid cloud” architecture really only describes how we deploy and connect the pieces.
IBM’s solution to the HCA implementation is to offer all the tools needed to build data center and cloud application components, then connect them, and run them.
Cisco recently announced a partnership with Google Cloud that creates an “SD-WAN Hub” for connecting all those various application pieces onto a common network. Everyone on our list as a prospective provider of that top-floor HCA implementation seems to be stalled on their version of the mezzanine level.
The big question for hybrid cloud, and for vendors who want to capitalize on the concept, is whether the business value of hybrid cloud is so eroded by the lack of that top-floor HCA implementation that the concept never pays off fully. Whether that’s a big risk is hard to judge at this point because enterprises just caught on to the reality of hybrid cloud last year. Without well-educated buyers, there’s not much motivation for sellers to do more than sing and dance.
I think it is a big risk, particularly to vendors who expect to promote hybrid cloud as a means of rebuilding revenues after the pandemic and lockdowns end. What I described as the endgame is what we really need to have in place. Without the ability to write for the hybrid cloud as though it were a virtual computer, we force developers to deal with all the special environments and special situations that arise now, or will arise, in hybrid cloud applications. That demands more skill, more time, more costs.
Vendors who want hybrid cloud revenue should step up now, while prospective adopters are still learning the ropes, and offer the best solution for the early development experiences. That will build confidence among enterprises, and revenue for the vendors. And it will finally give us what we wanted from the cloud all along.
