The Case for Private Clouds
“Everything is going to AWS and Azure, right?” Not so fast…
In the many countries, we’ve probably hit “peak virtualisation” (80–90%), where most server workloads that are sensible to virtualise, have been.
(As an aside, I’ll note that there other places in the world where this is far from the case, such as China, which is perhaps only 20% virtualised, but hold that thought.)
That makes it (theoretically) easy to move those virtual machines to an IaaS cloud, where everything is a VM. Coupled with the promise of elasticity, “infinite” resources, and only paying for what you use, we should be seeing a mass exodus from the enterprise to the public cloud. Are we?
Evidently public cloud revenues are on the rise, even as prices fall (60% since 2013, apparently). In 2015, the big four cloud providers’ revenues averaged 84% growth, whilst the total forecast for 2016 is somewhere between $38bn and $96bn depending on which analyst you believe.
Meanwhile, though, worldwide IT spending is set to increase by roundabout $300bn from now to the end of 2019 (to between $2.8tn and $3.5tn, again depending on who you believe; this is an interesting example of variation between analysts!). Clearly, therefore, even as companies spend up to $96bn more on public cloud this year, that could all have come out of this new IT spending.
Evidently there is some money shifting, I’m just pointing out that the shift probably isn’t as big as one might first expect.
So what are all of these cloud workloads then?
Firstly, I don’t believe that most of them are traditional enterprise workloads.
In the past, that’s been due to concerns over security and data sovereignty, but those arguments are weakening in the face of the investments that public clouds can make in compliance (see AWS’s impressive list of certifications) and datacentres within each country (by my count, AWS — 16 regions/10 countries, Azure — 30 regions/12 countries, SoftLayer — 20 regions/14 countries, Google Cloud Platform — 8 regions/3 countries).
Instead, it’s more about how “enterprise-like” clouds are, and how “cloud-like” applications are.
IaaS clouds don’t behave the way enterprise IT does
Clouds give you a virtual machine (not a physical server); the customer has relatively little control over networking and storage (more about QoS, less about specific hardware); and the SLA is decent but not on par with expensive server hardware (I assert, given that IaaS clouds will use cheaper server hardware at vast scale). In fact, the SLA for AWS refers to the availability of EC2, but explicitly excludes failures “that result from failures of individual instances or volumes not attributable to Region Unavailability”. In other words, your VM may just go away. Azure’s SLA is expressed in terms of percentage of time that one of a pair of VMs (split across Fault Domains) will always be available (again, one of that pair can disappear at any time). Not really what you’d expect your enterprise IT department to (not) promise you.
But it’s more than that: many virtual machines in the enterprise run on VMware vSphere, but none of the big public clouds are built on it (cost and lack of open source being the two big factors). That makes migrating workloads into the cloud painful because of the conversion step. It’s only very recently that VMware-based workloads have become more readily accessible on AWS (as of last week), and on SoftLayer (earlier in the year). Even then, neither of those are running atop the existing Xen-based clouds (XenServer in the case of SoftLayer), but on bare metal servers, meaning it’s more hosting than IaaS cloud, but it’s a start at least.
Enterprise applications aren’t cloud-native
Because of the (“lower”) SLAs in the cloud, applications need to be architected to assume failures, and deal with them transparently. Clearly some level of high-availability pairing is done already in some applications (e.g. databases), but that’s not brilliant if you want to scale up quickly (or you’re worried about an SLA that allows up to 21 minutes a month of downtime of both VMs, as AWS’s 99.95% implies). And then there are the applications just aren’t built to be resilient at the application layer… Pets don’t belong in the cloud, and few will go to the pain and expense of killing their pets and replacing them with cattle.
Instead, many of the workloads moving to cloud are either ones that don’t particularly matter from an SLA point of view (test and development), or new ones that are architected to be cloud-native. Happily Oracle’s co-CEO seems to be of the same mind, though what struck me about that keynote summary was the comment by AIG’s CEO that they spend “75 percent of [their] IT budget on its ‘very brittle’ legacy applications”. Probably one reason why IT spending is still increasing!
But enterprises can still gain from “cloudy” infrastructures
I’ve long maintained that what many enterprises want is self-service (let Finance create another database server if they need it, not worrying about the underlying infrastructure), and chargeback/showback (send Finance a bill for what they consumed, rather than hiding the true costs).
They don’t (for traditional enterprise applications) need fancy load balancing, or security groups for multi-tenancy, or object stores. They do need some form of “cloud-like” orchestration, to provide the self-service and chargeback.
Enter private cloud
Thus, we know that enterprises want cloudy infrastructures, but can’t move many of their current workloads to the public cloud. At which point the sensible approach is, in my view, to deploy a private cloud. Keep using the expensive (and hence, hopefully, reliable) hardware. Keep using hypervisor-level HA. Lose the long deployment times (“we’ll need to order a dedicated server for that”). Lose the unapportioned central IT cost.
Then the question becomes “why haven’t enterprises done exactly that?”. It comes down to what’s on offer: until recently* it was basically (lots of smaller players aside) OpenStack and CloudStack in the open source camp, and VMware vCloud Director in the proprietary one.
This is where the waters have been muddied: the hype has conditioned people to believe that (a) clouds should be the antidote to vendor lock-in, and (b) that the orchestration software should be free (because many public clouds use open source orchestration frameworks). This is dangerous because it slows private cloud adoption.
As many people have written before, open source does not mean cost free. In fact, in the case of OpenStack and CloudStack, you either need to buy a commercial distribution (and thus it’s not free) or be prepared to have a well-paid team of developers who can stand-up and support what you want (again, not free). Gartner have said as much.
Meanwhile, whilst I’m not a fan of lock-in, it stands to reason that if you already have one vendor’s products, and want to add cloud capabilities, you should at least consider their enterprise orchestration product. But the promise of vendor-agnosticism (however not free it might be) made people cautious (as, I suspect, did the price!).
In my view, what’s stopping enterprise private cloud is that most cloud orchestration platforms are too complicated
Remove all of the features that cloud providers need (see above) and keep the ones which really are useful to the enterprise. Make it simple (to install, run, and maintain), and shrink-wrap it. Then provide people with really clear guidance on how to move their current (legacy) workloads onto it (hint: they shouldn’t need to change anything about them).
Then you’ll see private clouds.
* What’s interesting is Microsoft’s recent foray into hybrid cloud by creating Azure Stack. Not only is this a shrink-wrapped orchestration tool, but it also gives people the option of moving their workloads into the Azure public cloud (or that of other service providers who are running Azure Stack) with minimal fuss. The only downside is that today it requires the purchase of new hardware, i.e. it’s not an add-on to your existing datacentre. I’ll be very interested to see if this requirement gets removed, and the pricing set so that you can use some quantity of Azure Stack for free as part of some kind of Azure cloud pricing…
