Sysadmin blog The private clouds are coming. A few of them are already in place, lurking in the shadows, but in 2017 the Infrastructure Endgame Machines (IEMs) land and everyone starts being able to buy cloud-in-a-can. With private clouds moving along the hype cycle towards Commercial Off The Shelf (COTS) solutions, the race to rebrand the concept for marketing purposes begins. Behold: the enterprise cloud!
So what, exactly, is the enterprise cloud? How does it differ from the private clouds of yore and most importantly – at least to your not-remotely-humble scribe – have they built an Infrastructure Endgame Machine yet? The answers, of course, depend entirely on who you ask.
Today's enterprise clouds are going to be almost exclusively based on Hyperconverged Infrastructure (HCI). The reasons for this are simple: HCI is mature, offers performance adequate for almost any workload and is so cheap compared to the traditional three-tier architecture that HCI vendors can still get away with fantastic margins for the software that makes it all go.
But HCI isn't a private cloud any more than a cluster of virtualization hosts lashed together with some management software is a cloud. Or, as I've been saying for some time now: hyperconvergence is a feature, not a product. It's a tool. A means to an end. The end is to make infrastructure invisible so you don't have to think about it again.
Enterprise scale is hard
One thing that's hard to appreciate until you've had to play the game in person is just exactly how hard IT is at scale. Compared to keeping 50,000 nodes happy, standing up a rack or 10's worth of IT is child's play. No matter what's running inside your 10 racks of terror.
With virtualization, 50,000 nodes can translate into millions of workloads. With containerization you can cheerfully be getting into tens or even hundreds of millions of workloads. The mind boggles, but imposing sanity on all of this is what clouds are all about.
You can't keep millions of workloads going by treating every one of them as pets.
Squaring the circle requires automation. Over time, we've developed several generations of desired state solutions, configuration versioning, patch management, vulnerability scanning, monitoring, templating, data protection etc. Layer after layer we've added solutions to the mix to solve the problems of dealing with workloads at scale.
In many organizations – yes, even the much cherished enterprises – these solutions have been built up as though adding band-aid atop band-aid to avoid having to deal with the festering wound of technical debt underneath. None of it quite works properly. The layers conflict. One solution tries to solve problems in a way that isn't optimal for the next solution in the chain, or the features of various solutions overlap, often to the detriment of the organization applying them.
Every now and again a big enough company would get fed up, tear it all up, and start from scratch. This usually involved a lot of custom middleware tying solutions together. Eventually, these custom solutions to the problem of workloads at scale started to look eerily like the solutions used by the early hosting providers to stand up websites for the milled masses. Back then, the buzzword was orchestration.
Someone decided to take their custom middleware for lashing various layers of IT management together, slap a self-service front end on it and the public cloud was born.
Private clouds are harder
Not too long after the public cloud started gaining mindshare companies large and small started popping up promising to build private clouds. All your woes would be put to rest, here were companies that would arrive and simplify your IT! Of course, it didn't quite work that way.
The first generation private clouds were really nothing more than outsourcing the stacking of band-aids to someone else. The companies that installed the public clouds were lashing together disparate solutions from various vendors that may or may not loathe one another, or trying to marry open source projects governed by warring vendors with drastically different priorities.
The end result was private clouds that nobody internal to the purchasing organization knew enough about to fix. Startups were bought up and subsequently silently defunded. Other vendors right-sized their human capital until everyone who knew how the bits worked was gone.
Subsequent generations of private clouds appeared. These were either miserable to use, priced too high to make it worth burning down the farm and rebuilding, or both. None of them really caught on.
2017's attempts are different. A whole lot of someones have decided that it is time to stop building multi-vendor band-aid sculptures and time to start delivering integrated single-sourced solutions. You buy a cluster, you turn it on and – in theory – everything you need to manage workloads is there. In theory, theory and practice in are the same. In practice, they're different.
HCI makes the turnkey part of the equation easier. Evolved virtualization management stacks make handling the part under the operating system easier. In truth, the "enterprise cloud" solutions of 2017 are substantially closer to a true IEM than anything that has gone before. Many of the multi-vendor finger pointing exercises go away. Many of the layers of IT management really do come integrated into a single solution.
The missing bits are mostly around desired state configuration. Nobody has bought up Puppet, Chef, Saltstack or any of the others yet, so today's enterprise clouds are still largely reliant on templates and images rather than creating wicked front-ends that integrate a recipe-based approach into the cloud UI. The closest we get are solutions that try to integrate with the popular desired state solutions.
So close. We're so close.
For most organizations, however, that's close enough for jazz. How long did we manage Windows environments using nothing more than System Center? And how long did we hand craft our Linux management solutions before even something as primitive as Satellite came long? If IT infrastructure can be boiled down to an enterprise cloud, a desired state tool and git to version the configs, we've reached the point where burning it all down and restarting makes sense.
At the core, all of it is just orchestration and automation. Cloud – be it public or private – layered on the expectation of a self service portal for end users and/or developers to provision workloads and a separate administrative interface for sysadmins to set limits, profiles and access controls, define templates and get alerts when some bit or other falls off.
"Enterprise cloud", then, is the above, but with the added expectation that you don't need a room full of PhDs to make it go, and – for the most part – everything under the workloads themselves is integrated and provided by a single vendor who doesn't have to fight with other vendors to make it all go. I'll take it. ®