Private Cloud Choices

Posted on by su


Last Thursday, I had the pleasure of joining Dustin Fennell, CIO of Scottsdale (Ariz.) Community College, and Paul Roberts, Cloud Architect at Carpathia, on a panel coordinated and emceed by Morgan Gerhart at Citrix Synergy.

The topic was  ”Is There Such a Thing as a Private Cloud?” Thankfully, we got past the surface question quickly enough and were all in agreement that there is such a thing. We then moved on to what types and flavours of private clouds can be found in the world and how to think in a more nuanced way about them.

The key message I focused on in the session was the following: In order to think more effectively about clouds, it is helpful to think about them as one of four types: inside/outside and legacy/webscale.

Legacy clouds are ideal for highly regulated, complex client/server environments, with extremely complicated layer 2 networking requirements. Webscale clouds are ideal for less regulated, web/mobile applications, greenfield apps and simpler stacks that need to scale (as well as a growing list of enterprise apps). Public is outside the firewall, while private is inside.

Each choice carries its own pros and cons and a different cost structure.* It is IT’s job to understand the different models and decide where to move workloads to in order to achieve the lowest cost, highest flexibility, and best return on capital and assets for their business.The diagram below hopefully helps provide a simple view:

So for those organizations building private clouds, it’s key to realize that there are choices. If you do not require a legacy architecture for your private cloud, you’d gain substantial CAPEX, OPEX and flexibility advantages by choosing the webscale architecture.

The other thing to realize is that webscale clouds are moving quickly up the feature ramp as they disrupt the legacy clouds. We’ve seen this recently as AWS has embraced Oracle and SAP.

My slides from the presentation are at the end of this post. I go into a lot more detail on the distinctions between the different cloud types in the deck. Please ping me with questions or comments. My email is troy at cloudscaling dot com. Or just leave comments here on the blog. I’d love to know if these distinctions are helpful to people.

Thanks again to Citrix for inviting us to be part of Synergy.

[*The numbers here are rough estimates and are being used simply as a guide to show how each choice has a different cost structure for the IT buyer. These numbers come from a range of internal research done by the Cloudscaling team on public and private clouds across many different geographies.]

This entry was posted in Cloud Computing, Company, Events and tagged , . Bookmark the permalink.

Previous post:
Next post:

  • http://samj.net/ samj

    Troy,

    While I think it’s useful to distinguish between “legacy” private cloud (in which reliable hardware hosts unreliable software) and “commodity” private cloud (in which unreliable hardware hosts reliable software), I think the “webscale” term you guys have been using more and more these days misses the point.

    That is to say, there’s nothing stopping you from creating a “webscale” private cloud using legacy hardware, nor anything stopping you from creating a small scale private cloud using commodity hardware.

    Fair comment?

    Sam

  • Troy Angrignon

    I think it’s a fair comment from a purely academic standpoint but a bit out of sync from what I’ve seen in my many conversations in real operators. Your experiences and conversations may have provided you with different data points of course.

    To your point, you could try to build a VCE or Websphere or HP style private cloud on more commodity style hardware (assuming you could find stuff that would pass their respective  hardware compatibility lists) and that would help reduce the total cost per VM (while decreasing the commission of the sales team). Or as you suggest, you could build a webscale cloud out of highly available, expensive hardware, thereby driving up the cost per VM (but why would you?)

    But when we have looked at deployments that people have built or are exploring in the many telcos and service providers we’ve spoken with, we find very strong clustering (in a statistical sense of the word.) In other words, most often the enterprise legacy IT cloud type systems we’ve seen are comprised not of commodity hardware but of the typical highly available, very expensive, high-margin components. I would suggest that of the folks I’ve spoken to who have built those legacy clouds, that the vast majority of them are running expensive and proprietary hardware alongside their expensive and proprietary software and those two factors combined are driving up their per VM cost, forcing them to come to market with very expensive VMs.

    Again, nearly universally, those clouds that we have found to have the lowest cost per VM have cost-optimized every single aspect of the operation – software, hardware, operations, data center, network, etc. So those types of operators wouldn’t think to suddenly try to drive up their hardware costs by adding in HA enterprise gear. It wouldn’t make any sense.

    So while you’re accurate that this is really a continuum of possibilities more than discrete categories, I haven’t seen many of those in-between cases in the real world. I remember one exception in a financial services firm where they had built a private cloud that was entirely commodity hardware – but they were the exception, not the rule.

    The enterprise vendors still enjoy 40-60% gross margin on that gear and so those teams are highly incented to build and spec solutions that allow them to put as much of that equipment out as possible. And in many cases, enterprises and operators are simply buying what the vendors spec, following the “recommended path” and their hardware costs end up being 2x-4x higher than they would be in a purely commodity style approach.

    None of this is to say that I agree that this is how it SHOULD be done. If I were advising somebody on how to build a private cloud for their entire app portfolio, I’d certainly recommend that if they could get away with it, they build a webscale cloud to start and use that for as much of the portfolio as possible (knowing too that it should be improving in features and functionality over time if it’s on the right platform). KT did this and are in the midst of moving 70% of their internal IT applications over. This has given them significant capex reductions (79%) and provisioning time improvement (50x) over their old model.

    But for those remaining apps, *assuming that there is business value in moving them at all*, that absolutely couldn’t run on a webscale type architecture for some reason because of their networking complexity or stack support issues, then sure, the next best bet would be to build a private legacy-style cloud on commodity hardware. It will be more economical than using the HA equipment. The question is can you get the vendor to approve it with their HCLs? And can you actually get their sales teams to sell you what you need? They have zero incentive to do so.

    Thoughts?

    • http://samj.net/ samj

      My point was that while you could deploy legacy (unreliable) software on commodity (unreliable) hardware or “webscale” (reliable) software on “legacy” or “enterprise” (reliable) hardware there’s not much point in doing either — in the former case you’ll end up with an unreliable system and in the latter a reliable but expensive one.

      • http://samj.net/ samj

        Conversely, both unreliable software on reliable hardware and reliable software on unreliable hardware make sense.

  • Troy Angrignon

    Sam, I also forgot to address your point about the terminology – webscale vs. commodity.

    We have discussed and debated this a lot in the team and we realized several things. We definitely wanted to decouple the word “enterprise” from the types of clouds (as in “enterprise cloud vs. commodity cloud” because it leads to the myth that enterprises use only the former and not the latter (definitely not true.)

    We also wanted to avoid the use of the word commodity because we found that unlike its real definition, it seemed to have a negative connotation with people where they took it to mean “cheap and of poor quality”. Clearly AWS, KT, and RAX are relatively inexpensive but we wouldn’t go around accusing them or any other commodity-hardware based cloud to be “of poor quality.”

    So we were looking for two terms that described more the types of workloads without using either the term enterprise or commodity. I’m not sure to be honest that legacy cloud and webscale cloud are significantly better but they help us make a clear point. SMBs, enterprises, and governments can use both types of cloud, and generally use them for different things (enterprise-scale / complex / regulated / client-server vs. web-scale / simpler / less-regulated / web & mobile).

    We think this is a really important distinction that is being lost in the noise created by enterprise vendors marketing their legacy IT stacks as “cloud systems” when really they are “legacy cloud systems.”

    Hopefully we have not solved one problem and created another. Given the points above, I’m keen to hear your thoughts on our terminology conundrum.

    • http://samj.net/ samj

      I too don’t like the term “enterprise” cloud as it’s disparaging of cheaper, commodity alternatives in the same way that “private” cloud implies the alternatives are somehow not private.

      By definition a commodity is something that is differentiated only by price — it says nothing of quality. Here’s some common commodities for example: http://money.cnn.com/data/commodities/ Would you consider gold or silver to be ”cheap and of poor quality”?

      I think “commodity” is a more useful term which reflects that the computing fabric is homogenous rather than heterogeneous, without saying anything as to the scale (ala “webscale”). Hardware isn’t really a differentiator any more and “commodity” makes this clear.

      That said, it can also be useful to refer to small vs large or “web” scale because it’s only at scale (~10-100k+ servers) that TCO really tapers off — mixing the concepts is unhelpful.

      • Troy Angrignon

        Yes, I agree that we’ve traded one problem (the possible negative connotations of the word commodity)
        for another (the overloading of webscale when scale is just one
        dimension or trait by which the clouds are judged. We may end up falling
        back to Legacy Cloud vs. Commodity Cloud at some point. Where it gets
        annoying is that edge case that you pointed out where somebody builds a
        VMWare / Websphere / HP stack on commodity gear and says “ta-da! –
        Commodity cloud!” Ummm…no.

        Admittedly, we as an industry have a ways to go to create language that
        is more useful. I really appreciate hearing your thoughts on this Sam.
        We’ll keep working on it.