The Patchwork Cloud - To rent or buy your cloud?

cloud-background.jpgI read a lot. That should not surprise you.  Today I got an interesting poke on Twitter that the folks over at PistonCloud have written up an interesting blog post in response to last night's mysterious Amazon outage ... and it caught my attention.  To be fair, many folks I know have commented on the post, and on Amazon's issues - but as always you can expect a slightly different viewpoint from me ...so here goes.

 

At the heart of the PistonCloud message is the phrase "it's better to own than rent" ... in the cloud context.  Is it though?

 

As with most topics that are controversial, you'll hear the typical "well, it depends" answer from me ...but I'm interested in PistonCloud's justifications on why they believe this.  In the interest of full disclosure, HP does deliver cloud in both buy and rent variety - public, private, and converged (hybrid) cloud consumption models.  Let's dive into an analysis of the rationale...

 

  1. "It's cheaper to own than rent" - I don't think so.  Are they considering the other factors besides server cost?  What about data center real estate, cooling, human resources, software costs, cooling and power?  Wait, there's more - don't forget the operations costs that are management of the servers hardware & software...  I'm curious where the 3x multiplier for cost of ownership over renting comes from ... I would surmise, although I personally haven't done the research to prove it, that this is the exact opposite.  For those of us that are sick of server glut, boxes being bought and running a single service then decommissioned and taking up power and generating heat ... this just doesn't make sense.  Consuming the compute service as-you-need-it is a great idea, and in the end even thought it may not be dramatic, it should be a cost savings.  Having your own private cloud is suitable for many applications, compliance and security being a major opportunity, but I'm just not sure the 'cheaper' argument is viable.
  2. "Your landlord doesn't give a {bleep}" - Really?  Change providers.  When you're hunting for a cloud provider, do your due diligence and make sure that your interests are reflected in your provider's operating model.  Give the Service Level Agreement (SLA) a check, and make sure that it meets your requirements and that you're not just getting more free poor service after your compute service fails you!  Heck, if your current provider really doesn't give a {bleep} as the PistonCloud blog post suggests, come over to HP Cloud Services (hpcloud.com) - we care about our customers, and we'll show you with choice, consistency and confidence in your provider.  This argument is just silly.
  3. "There goes the neighborhood" - I will admit that at first blush this argument is compelling.  After I thought about it a bit, I realized that this isn't really that different that than your average internal private cloud ... follow me on this one.  If you're a large enterprise odds are you'll be potentially sharing a private cloud service across your organization, not just your specific BU (cost savings, remember?) and that means you'll have to be comfortable with the risk appetite and security profile of all of your private cloud neighbors ... so while this is a bit of a stretch it's just as real.  Looking upstream we can see that at the edge of your network you share the Internet with other organizations at the handoff to your private cloud, it's further upstream and isn't on a flat network like a private cloud - but it's not a far stretch.  Bottom line is that you have to understand the risk profile of your application(s) and decide your private (or public) cloud profile accordingly - so this could be true for high-risk, high-profile applications ... is it true always?  I seriously doubt it, and it's a cheap way out.
  4. "Build home equity" - Are they serious?  I think anyone, myself included, that owns a home right now may not agree so much with this statement.  Also, when is the last time that your server hardware appreciated in value?  I get the argument that you build equity in the form of processes and improvements because you may feel locked in with your rented cloud - but consider that if you're an HP Cloud Services customer you're not locked in given our commitment to OpenStack and consistency across public, private and converged clouds (owned or rented)... Vendor lock in is a very serious concern and even our CEO agreed when she gave her keynote at HP Discover in Las Vegas.  One more analogy ... do you generate your own power at your home?  The answer is unlikely to be yes - but in some homes, in some geographies, in some climates it makes sense to put in solar panels or other means and even feed electricity back to the grid.  It doesn't make sense everywhere, but some places the ROI on solar panels is undeniable!  I truly believe it's the responsibility of the consumer to look at what they're buying, and make sure you're not buying into proprietary technology which won't provide you the choice, consistency and confidence in your cloud strategy.  Again, this notion of building equity is borderline silly.

 

As you can tell, I'm not really on board with PistonCloud's "buy your cloud" attitude.  Like my friend @christianve says, one cloud does not fit all. Your cloud should be customized to fit your business.  I believe that if you're going to have a cloud strategy you need to have a pragmatic approach which has you doing your due diligence, proper risk analysis, and understanding your cloud vendor.  If your provider fails ...do you have a strategy?  If you've transformed all those applications of yore to cloud applications then the answer should be yes, and your applications should be resilient across multiple clouds, vendors and environments ... this is the magic of cloud.

 

To suggest anything else is ... well ... silly.

Comments
George Reese(anon) | ‎06-16-2012 01:46 PM

Articles like the Piston Cloud one should be entered into a Twitter-based game called "Are they lying or are they stupid?" In short, you are right on the mark regarding all of the so-called points Gretchen attempts to slide past us in the Piston Cloud blog. As a matter of fact, your response is so sound it begs the question of whether the Piston Cloud team is this stupid or whether they are being disingenuous and trying to scare people away from public clouds.

 

The bottom line is that nothing Piston Cloud offers will protect you from what happened with AWS this week. What will help is a redundant architecture that ideally spans multiple clouds. A private cloud may be PART of that approach, but it isn't the answer to the outage this week.

 

Unless you think you never will experience an outage in your own data center. In which case, you probably are the ideal Piston Cloud customer--a dupe.

adrianco(anon) | ‎06-16-2012 02:16 PM

There's a guy parked by the side of the road with the hood up on his car. Another guy stops and asks "What's wrong?".

 

"Piston broke"...

 

"So am I, but what's wrong?"

 

secolive(anon) | ‎06-18-2012 05:21 AM

I recommend reading the AWS RCA (http://status.aws.amazon.com/rss/ec2-us-east-1.rss) - there are a few interesting points:
1. At 8:53PM, generator powers off. At 10:19PM, generator is fixed and powered on again. Time to diagnose issue and have it fixed=less than 1 and half hour - outside business hours. In my own experience, this is impressive. Do you think you can beat this? If so I hope you are a competitor :)
2. Overall outage for 99% customers is approximately 4 hours; longer, but still very difficult to have a significantly better result by yourself
3. AWS are "incorporating these configuration checks into our regular testing and audit processes" - they have learned something and can now improve; this is a very good example of how you need to fail sometimes to actually improve your resilience. You see, power problems are quite typical, because it seems surprisingly difficult to design and implement a backup circuitry that works as expected in many scenarios - especially because it is difficult (or too risky?) to conduct meaningful tests. Unless you actually experienced, say, a dozen power outages, there are probably still a few surprises for you in the pipe.
4. Only one availability zone was impacted, so this incident really is within specs. Nobody can run a single data center with 100% availability, so if you need high availability (say 99.99%) then plan for redundancy across data centers - and why not across service providers?

 

One of the difficulties running your own infrastructure is that you will always have to rely on providers - unless you're not connected to the Internet and have armies of monkeys peddling to generate your electricity. Oh, and you need providers to service your equipments in case of failure too (unless you hire dozens of engineers in various fields and keep them on-call) - because however you design your infrastructure, there will always be edge cases where you rely on something being repaired to resume normal service. That's actually quite a lot of providers you need. Do you really think you can find only providers that care as much about Nobody Inc than about a huge customer like, say, amazon? If you _rely_ on service excellence, then good luck.


Moreover, can anybody actually demonstrate that there were issues caused by Amazon not caring enough about a customer? Maybe. Sorry, but a far better resiliency strategy is exactly not to depend on the cloud provider having to care about you. Plan for outages, and expect the outages to be probably as long as if it were your own infrastructure (e.g.. 4 hours for a yearly incident). If you're concerned about such service levels AND you prove it's a problem for your business, then I suggest planning for additional redundancy, because you will always need it at the end, cloud or not.

 

@secolive

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation