Last week, Flexiant posted a whitepaper I had written, proclaiming that private cloud was ultimately dead. Jeremiah Dooley (who works in the office of the CTO at VCE) posted a thoughtful riposte yesterday. Firstly, I’d like to thank Jeremiah for taking the time to read the paper before commenting (not everyone did that), and most of all for taking the time to reply. I said on Twitter I would answer, so here it is.
Apologies for the length, but some of the criticisms raised are down to the fact the original paper was condensed to make it readable by those with short attention spans, and that necessarily means some points got lost.
Purpose of Paper
Let’s put this one to rest first. Whilst (hard as it might be to believe given the consequent twitter storm) this wasn’t originally written by me as marketing piece but as a ranty blog post, I should be clear that it was subsequently adapted by our marketing department to form one. Adapting in this case means making it less long winded (see the length of this blog post for why this is necessary) and easier to digest (which means taking some material out), and making it look pretty. It is marketing collateral. Its audience is service providers, and specifically people in service providers who are selling to their potential customers. That’s not the same thing as an academic paper or a paper written for a cloud conference.
So, is this just a sales pitch for Flexiant? Well, no – not least as it doesn’t once suggest anyone buys anything. We’ve found whilst all service providers have got the message ‘cloud is hot’, many are ill equipped to sell it, as they often don’t understand the issues and the objections that their customers raise. Their customers’ objections to cloud technology are similar in many cases to objections we saw to virtualisation and objections to outsourcing; whilst some are valid, more often than not at least some are based more on fear, self-protection and specious argument than solid facts. We’re a European company and our customers are predominantly European, so perhaps that applies more here in than in the US (though I’ve had plenty of US people agree with me on this point). So what the white paper is designed to do is to provide ammunition to service providers who need to make their case for service provider run clouds, rather than solutions that keep IT in the enterprise. I’d say that’s because we believe the long-term future of IT is in the Service Provider, not the organisation’s own data center; I explain why in the article, and not one of the reasons I give is that ‘Flexiant’s software is great’. I can understand why, given Flexiant sells Service Provider focused software, that might come over as self-serving, but when I load up VCE’s home page, the ‘title’ element says ‘Private Cloud Computing’, so perhaps we all have our biases.
Am I doing anything radically new here? Are my terms particularly controversial? I don’t think so. Here’s an article by Simon Wardley using yet another definition of private and public cloud. And here’s one saying private clouds are a transitional phase whereas public clouds are the long term economic model. Perhaps ‘private clouds are ultimately dead’ is just a bit of plain speaking too far, but it means the same thing. I could look for other sources, but having sat through Simon’s (by his own admission often rather similar) presentations sufficient times without a single person arguing, I’m guessing his views are hardly heretical.
Jeremiah doesn’t like having to register to read papers on the web. You know what? Neither do I. In fact I’ll go further: I hate it. I hate it enough that 99% of the time it will stop me reading them. I also hate emails not written in plain text and wrapped at 76 characters, top posted replies, and my iPhone for making it hard for me to avoid either. But I’m not the audience, and this is marketing collateral. Our marketing guys like measuring the effectiveness and distribution of these materials, and asking for registration is hardly unknown – for instance one of VCE’s shareholder’s here. Given the number of cartoon characters we now appear to know have both memorable phone numbers and a surprising interest in cloud, and given we emailed it to anyone who wanted it, there would appear not to be that high a bar to work around for those who don’t want to give personal details.
And as far as opening PDFs opening full screen, I’m almost sure that’s a product of the web browser. On Safari and Chrome the default (for all PDFs) is to load them in browser. This infuriates me, so I turned it off. All PDF downloads (including Flexiant’s) now appear as downloads.
Anyway, this reply is in badly formatted HTML on my personal website, unadulterated by marketing, and with no registration required, so I am thus hoping it is peeve free.
Jeremiah notes that I didn’t use the NIST definitions. I have a few nits to pick with the NIST definitions (in particular the use of the phrase ‘general public’ as opposed to ‘customers in general’), but none that are particularly serious. So let’s have a look at the differences between NIST and what I used, so we can ascertain whether this makes any practical difference:
Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.
Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.
Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).
Public cloud – a bank of cloud resources managed by a service provider, located in its datacenter and shared between customers.
Private cloud – a bank of cloud resources managed by an organisation, and used only by that organisation. It is irrelevant whether it is ‘on premises’ or not. This isn’t a distinction of who owns what building, but of who manages what. Just as the organisation might not own its head office building, the physical datacenter might belong to someone else, but the management and operation is done by the organisation concerned.
Hybrid cloud – a particularly ill-defined term that has many definitions. In general it means something on the spectrum between public and private clouds.
So, there are three main differences:
- I don’t mention community clouds. I think they are special cases of public clouds, just with a limited ‘public’. Given how little attention these get these days, I think this is a forgivable omission, and Jeremiah doesn’t pick me up on this one.
- Our definitions of private cloud are different. I say a private cloud is managed by the organisation to whom the resources are dedicated. NIST say it can be managed by anyone. More on this one immediately below.
- I say ‘hybrid cloud’ is an ill-defined term. I stand by that, and more on this under ‘Hybrid Clouds’ below.
Does who manages a private cloud matter?
So let’s look at point 2. My core argument re private clouds is that save in the case of the largest of clouds, the economics of public clouds are likely to be better. Those economics are likely in most cases to outweigh other factors, particularly as many of those other factors are less relevant than they might first appear, or are spurious. The reason why I believe the economics of public clouds are superior to private clouds are derived from scale, and scale comes in the main from multi-tenancy. I could perhaps have said ‘big clouds are better than small clouds’.
So, if by ‘manage’, we are looking solely at the economics of the hardware, I agree it doesn’t much matter who manages it. I agree that a private cloud doesn’t gain some sort of magic technical efficiency because the people with console access are employed by someone other than the organisation using it. However, management also includes the organisational resources to set the cloud up and to provide ongoing support. Those aren’t skills every organisation has, and there are economies of scale to be found here too. But I’d argue in the absence of any form of multi-tenancy, those economies are in general small.
The distinction I was making in my definitions was that it doesn’t matter whether the private cloud is on-premise or not. Put simply, putting your stuff in someone else’s datacenter does not make it either a cloud, or necessarily more efficient. Or (with the intended audience in mind) ‘don’t go selling datacenter space to people and pretend that you’re selling them cloud’. Something more than the location of the equipment needs to change whether it is scale (through multi-tenancy) or something else (perhaps management).
I agree that my definition has a ‘blackspot’ between my definitions of public and private cloud, which that a cloud dedicated to one organisation and where no resources are shared (i.e. is entirely single tenant) but which is managed by another organisation doesn’t fit into any category; such a cloud falls between two stools. NIST would call this a private cloud. Jeremiah says my definition is ‘self-serving’. I agree that there are some limited economies to be gleaned from having a single tenant cloud managed by a third party, and I agree that I ignored this case, but I don’t see how this makes the argument self-serving. As Jeremiah says, ‘How an enterprise pays for or maintains ownership of those solutions doesn’t fundamentally change what is going on’. To the extent that’s correct, then a private cloud managed in-house and a private cloud managed by a service provider should be similar, so not a lot would appear to turn upon the fact I didn’t deal with the latter case.
That said, given not a lot turns on it, and given as an industry we spend too much time talking about definitions, it would have been preferable to use the NIST definition of private cloud and avoid the debate. If I revise the paper I shall use that instead.
The dismissal of the Hybrid classification is expected, but disappointing. Being able to manage resources that have been purchased from public clouds alongside infrastructure that is dedicated is important. Most of the hypervisor providers have been, or are moving towards tooling that can handle this kind of use case. If you are a round peg, it’s easy to see the Hybrid use case as a square hole and move on, but customers and service providers are increasingly seeing a need for this.
So here we disagree. Yes, I do slate the classification of private cloud, in the sense that I point out it is an ill-defined term. I don’t, however, slate hybrid clouds in general. In fact I say there are three models, two of which have their uses.
Re the definition, NIST says (ignoring community clouds) that hybrid cloud is a composition of private and public cloud infrastructures that remain unique entities but are bound together. I say the term is used to mean something on the spectrum between public and private cloud, and then later (starting on page 7) decompose this into three modes, the first two of which fit directly into the NIST definition (a composition of public and private clouds, with the composition being done in different ways), and the third of which describes a single cloud where some resources are dedicated and some are shared. Whatever the NIST definition says, this usage (meaning a hybrid between a public and private cloud) is used. I agree it’s confusing, and I make that point myself.
So, why do I draw a distinction between the first two hybrid cloud models? Simply because one makes sense, and the other is (in my opinion) likely to be a nonsense.
I have a suspicion that Jeremiah might actually agree with me here, as his statement ‘In the next paragraph the phrase “cloud-bursting” was used, and so I skipped the entire rest of the Hybrid Cloud section in protest’ rather suggests he thinks as little of it as I do. However, like it or not, we still hear people talking about it, and it thus needs to be addressed. I suspect skipping the rest of the section where I talk about the more useful types of hybrid cloud might explain why Jeremiah thinks I’m slating the whole thing.
So, what are these two models. In the first model, a given service component uses both private and public cloud simultaneously (at least under some circumstances) – for instance the service might ‘burst’ to use the cloud when running over a baseload capacity. In the second model, some services or service components are on a private cloud, some on a public cloud.
Let’s look at that diagrammatically, considering two services A and B, and colour representing whether the workload is performed on a public or a private cloud.
The first model’s problems are in essence that the very things that (by assumption) prevent a service going entirely on public cloud make it unsuitable to go on both public and private cloud. You also have data synchronisation issues if (like most compute tasks) each compute node cannot carry out its tasks completely independently. Or, to put it another way, introducing tens or hundreds of milliseconds of latency between some parts of an infrastructure and others may cause it to perform badly. As far as I’m concerned, apart from a few limited applications, this model – and cloud bursting in particular – is smoke and mirrors. Perhaps someone will pop up and prove me wrong on this, with an example of a significant enterprise application where cloud bursting using a hybrid cloud works better than putting the lot on public cloud. For now, I think it’s all hand-waving.
The second model doesn’t suffer from these problems. Some services or service components go on public cloud, some on private cloud. There’s no dynamic placement lunacy. I agree here common management is useful. But the model itself isn’t generating an additional returns beyond the returns you’re getting from putting one set of services on public cloud, and putting another on private cloud. And you’ve got a few extra challenges. For instance, you may have increased latency between the public and private elements. Assuming the two halves are closely connected, you’ve imported the security concerns of public cloud and consequent need to take additional precautions into the private cloud bit too. So whilst to an extent you have the best of both worlds, also you can have the worst. It’s not a panacea. What I don’t see it does is produce substantial advantages beyond those of its constituent components. I do however, in the concluding paragraph to this section (the title to which has sadly gone awry) suggest this is a useful approach for enterprises to take, along with the third model (virtual private clouds).
On Commodity Clouds
On the public cloud side, I would wager that the majority of the customers referenced in the GiagOM research regarding pricing being a driver were talking about AWS, not cloud services hosted by traditional service providers. Using them as the bar, especially on cost, isn’t very useful.
I agree with this. However, that was by way of interesting introductory statistic rather than a basis for my entire argument. I am (and Flexiant is) a strong believer in the ability of service providers to differentiate on things other than price. Service and Service Level is one such area ripe for differentiation as I mention on page 10 – have you ever tried speaking to AWS on the phone? If I thought price was the only important factor, I’d conclude that only service providers approximating the size of AWS would have any significant market share (i.e. that there would be a very high concentration ratio, and Flexiant would have very few customers). However that is not what has happened in any many other service provider market, and not what I believe will happen.
Currently, as an industry we suffer from a problem where cloud products are poorly defined, not portable, and not fungible. Put simply, comparing them is an apples-and-oranges exercise. Lack of substitutability means we have poor price competition, which means excess profit for certain suppliers. We have one licensee with a cloud much smaller than AWS that prices their product significantly cheaper, sells a commodity product, and still makes money, and I know of at least one other provided (not using our software) who does similarly. Thus I’m pretty sure AWS operates at a very healthy margin.
So, given that I think price isn’t everything, why am I banging on about economic drivers? Two reasons: firstly, the law of diminishing returns, and secondly because I am talking about the long term, not the market situation now. On the first point, most enterprises are sub-scale. They will get very significant economic advantages by deploying their technology on a larger platform than the platform they themselves need. There are exceptions – for instance enterprises with IT requirements the size of a medium size service provider are likely to be able to attain a similar cost profile to that sort of service provider. But the larger the service provider gets, the lower the marginal economies of scale. I am betting a service provider half the size of AWS, going to the same hardware vendor, can purchase hardware within a fraction of the percentage point of cost difference. And re the second point, the current lack of comparability between cloud products will disappear as the market and the products within it are commoditised. That doesn’t mean every product will become the same, rather that it will become well defined and the buyer will be better able to select products that are similar or substitute effectively. And what that means is that where two products have similar characteristics, price will become an increasingly important factor.
Let’s pick a real world example from another industry segment: internet access pricing. When I started in that business in the early nineties, prices and products varied hugely. You could buy purportedly the same service for one price, or elsewhere for one tenth of that price. Knowing which to buy was difficult. Pricing was incomprehensible and illogical. Margins varied hugely (though I seem to remember most of them were negative). Now, there are still different types of internet access product, and those have different prices. But the price of a particular type is reasonable consistent across all suppliers.
We’re still in that first stage for cloud. I’ve heard several organisations say that right now they are building private clouds because ‘they can do it cheaper than Amazon’ even for comparatively small clouds. What they mean by this is ‘they can build it more cheaply than Amazon’s current output pricing’. I expect that for commodity cloud (i.e. the market AWS is aimed at) in time margin compression from competition will end that for clouds of such small scale. It’s at this stage that economic drivers will kick in. But the point about price comparability is equally applicable to the choice between similar products or solution provided on public or private cloud infrastructures.
Let’s consider for a moment the alternative hypothesis: cloud will grow hugely, but despite this there will never be effective competition. This sounds desperately unlikely.
Public Cloud Drivers
As an aside, I don’t agree with including “multi-tenancy” and “commodity” in a list of reasons why customers should choose a public cloud. Both are things that customers will have to swallow hard and deal with in order to take advantage of the larger value, but I don’t think either is a selling point to the customer.
I agree. That’s why I didn’t list them as demand side drivers. They are supply side drivers (see top of page 5), in that the supplier wants them, because it reduces the cost of providing the services and thereby gives statistical gain. The customer may (or may not) benefit from consequent cheaper pricing.
Private Cloud Drivers
I’m less clear on the basis of Jeremiah’s objections here. Let’s take two things in particular.
There are TONS of valid reasons why the vast majority of enterprises of all sizes continue to maintain their own infrastructure, or pay a provider to maintain it on their behalf, and almost none of them include elasticity or utility billing. I’d argue that very, very, few organizations, no matter what the size, do actual utility billing internally.
I’m not sure I understand the point here. I would have thought the point that the enterprise for many applications wants both elasticity (ability to flex resources) and utility billing (i.e. billing on a usage related OpEx basis rather than a CapEx basis) is relatively uncontroversial. Yes, I agree that they do not in general get this if they maintain their own infrastructure or pay someone to manage it on their behalf; that’s rather my point. The economic drivers that push people toward public cloud do not apply to the same extent to private cloud (whoever maintains it). Frankly I would have thought that was pretty uncontroversial. This does not mean there are not other factors that might militate in favour of private cloud solutions. But what it does mean is that the magic ‘cloud’ word does not deliver the same benefits regardless of deployment model.
And he continues:
Here’s a hint: it’s a completely different product, so there is different value realized and different costs involved. Comparing a company that wants a dedicated infrastructure managed by CSC to a customer who wants to pull VMs from a public cloud provider and migrate their enterprise apps to that model is silly. They don’t have the same drivers, they don’t have the same expectation of cost, they don’t want the same value.
I’m beginning to think part of the problem here is definitional. My comparison is not between AWS and CSC. It’s between the customer that wants a dedicated infrastructure (whether managed by CSC or the customer, that’s a private cloud) and the customer that wants a managed infrastructure provided by CSC which is not dedicated to one customer but rather to all of CSC’s customers, i.e. is multi-tenant. In my book the latter is public cloud. Under NIST’s terminology I think it is too, as it certainly doesn’t fit within the NIST private, hybrid or community cloud definitions.
Addressing Buyer Objections
Again, I think most of these are misunderstandings of what I wrote (or perhaps my failure to express them adequately).
Objection 1 – Public cloud has inadequate SLAs – (paraphrased) “Sure they do, and even if they don’t you don’t really need an SLA anyway, but you need a terms of services contract.” … VCE customers have, on average, 0.5 infrastructure incidents a year, leading to 83X better availability according to IDC, reducing productivity losses by more than $9,000/yr per 100 users. There’s an implicit level of accountability with the internal IT teams responsible for those metrics (um, continued employment), but if I want that same level of accountability from AWS (2.0 incidents/year, 72X better availability) I’m asking the wrong questions? Red herring at best.
Well, I’m not in a position to argue with IDC’s figures, so let’s take them at face value. If so, using VCE gives 83 times better availability than AWS (which is built on commodity hardware). No doubt it costs rather a lot more too. What we learn is that expensive hardware with built in redundancy has higher availability than cheap hardware that doesn’t. No surprises there.
But that’s a difference in technology, not a difference in deployment model. If VCE’s hardware were deployed in a public cloud, would its availability suddenly drop to the same as AWS? I’m guessing not.
What I argue is not that public clouds all have fantastic SLAs. Rather that you get what you pay for. If you want an enterprise-grade SLA (for some value of ‘enterprise-grade’), you aren’t going to get it from AWS. Perhaps you need to go to a cloud built using VCE’s hardware, or one with a different configuration. Undoubtedly, it will have a different price point. However, just because commodity public clouds often do not have such SLAs, that does not mean that the fact that a cloud is public prevents it from having a meaningful SLA. And an internally managed private cloud often has no SLA at all.
Objection 2 – Public cloud has inadequate security – (paraphrased) “Most problems here are actually your fault, and anything that IS an issue with public clouds is also an issue with private clouds, except public cloud providers are smarter than you.”, Well. OK then. Once again, the shitty definition of “private cloud” used plays into the failure of this statement to reflect reality, but this isn’t an actual rebuttal of the objection, it’s just pointing the finger somewhere else.:
Let’s quote in full what I actually said, as it’s shorter that Jeremiah’s comment.
Most security problems are not down to technical failings, but are instead due to poor organisational practice. For example, compare the number of security breaches originating in software bugs to those originating from configuration errors. Whilst cloud does present security challenges, many of these are common to private clouds. Service providers have in-house cloud-focused security expertise, whereas enterprises in general do not.
I’ll leave it to the reader to determine whether Jeremiah’s paraphrasing is a fair summary. As I say, cloud does present security challenge, and some (but not all) are common to all deployment models. Approaching private cloud as if it contains no security challenges would be foolhardy.
Objection 3 – For regulatory reasons we cannot use public cloud – (paraphrased) “You don’t really know what those regulations mean. Hybrid cloud may help here, just ignore that we ragged on it in the previous objection. You should go get a deeper understanding of the fundamental regulatory oversight your company is in.”
Again, I don’t say what Jeremiah seems to think I said. Firstly, it was only one model of hybrid cloud I slated (though as Jeremiah skipped the section, he missed that). Secondly, I do not say the company doesn’t know what the regulations mean, I say “it is necessary for service providers to get a deep understanding of what the regulatory restrictions actually are, rather than accept the statement that regulation bans them at face value”. Knowing your customer’s industry is vital and the parameters in which they operate is surely important.
I pretty much stand by what I said in the original white paper. In retrospect it would have better to use the NIST definitions straight, perhaps at the expense of some more words, but I don’t think it changes the thrust of the argument. Given this reply is already longer than the original whitepaper, and given its intended audience, there’s a limit to the amount of information I could reasonably put therein. However, thanks to Jeremiah for helping draw out these points.