AWS Outage Proves It’s Better to Own Than Rent

Gretchen Curtis  /  Jun 15, 2012  / 

Forget foreclosures and record-low interest rates, there’s an equally fierce real estate battle being waged in the cloud. The Amazon Web Services outage last night highlights the largest risk to betting on public cloud: you don’t own it. Any of it. Which means you’re at the whim of whatever vendor you have entrusted to protect it. How much do you really know about where your data and applications are being housed?

When selecting between public and private cloud solutions for mission-critical aspects of your business, never forget to weigh the very real risks of outages and security breaches with the conveniences of public cloud. How much will two hours of being offline cost your business? Last night’s outage highlights the importance of high availability, and emphasizes that – unless you own it – you can never be too sure about the reliability of your IT infrastructure.

Why own vs. rent?

It’s cheaper to own than rent.

In the long run, this is true of land and cloud. Just as home ownership can provide a return on investment with savvy planning over time, owning your own infrastructure can return 3x the investment as throwing money away on rent. Owning your own cloud infrastructure is actually much cheaper than renting indefinitely.

Your landlord doesn’t give a *#*&!

A landlord doesn’t care about you, only the four walls you’re in, and making money on them. If a window leaks, they’ll fix it, yes, but you won’t know about the leak until it rains. The public cloud offers a one-size-fits-all model that may fit some, but is based on general usage patterns of the majority of renters. Your requirements for compliance, cost, security and service levels will largely be ignored unless you fit the general profile.

There goes the neighborhood.

In the public cloud, you are sharing infrastructure with an unknown number of other renters that may be a target for cyber attacks. Do you really want your organization’s business critical applications being housed next to strangers? When you own your infrastructure, you have control over servers, compute power, storage, security and service level agreements (SLAs). You know all your neighbors and even chair the neighborhood watch group.

Build home equity.

Like owning a home, with private cloud you get to make the decisions over improvements that grow value over time. Not only do you get to avoid public cloud vendor lock-in, but you can consider your unique enterprise integration and workload requirements. Renters are far less likely to make major and costly improvements if they can avoid it. Homeowners, on the other hand, take pride, and even financial gain, from investing in the future and state of a home – improvements that ultimately save money or put money back in your pocket.

Share this:

Posted in: Blog


  • http://cloudchronicle.com Patrick Pushor

    Can you please substantiate the “cheaper to own than rent” position please? Thanks.

    • gretcurtis

      Thanks for your comment, Patrick. It largely depends on how much IT your organization is consuming and the type of business you are in. First, at a certain scale, anything is cheaper to own than rent. For example, if I only need a car two days per month, it’s much cheaper to rent it. If I need a car every day, however, it’s going to be much cheaper for me to buy and own that car. If you are a web-based organization, IT is at the heart of your business. Without it, you’re toast. Every minute that your IT infrastructure is down is costing you money and customer loyalty, which can negatively impact your bottom line. If you are only using public cloud for dev and test, it definitely slows things down for your dev team, but you probably won’t lose customers. Again, it depends on what you’re using cloud for, how much you’re using, and how critical it is to your core business. We have developed a calculator to compare the TCO of a Piston Enterprise OS private cloud over one to three years vs. renting services on AWS. We’ve discovered that there’s a tipping point around 13k per month. If you’re spending more than that per month on AWS it’s probably worth having a look at your in-house options.

      • http://cloudchronicle.com Patrick Pushor

        As David suggests – I think you need to be careful just comparing cloud charges (EC2 for example) with hardware costs. The calculations need to be more encompassing than that. Good to know you have a way to measure it, though – tools like that are very valuable.

        • http://www.pistoncloud.com/ Gretchen Curtis

          Absolutely, we base our calculations on TCO. That’s what really matters. Thanks again, Patrick.

        • http://www.pistoncloud.com/ joshuamckenty

          Patrick,

          The TCO calculator that we developed at Piston Cloud is based on the Full-Cost-Accounting (FCA) calculator that we developed at NASA. We had to price the cost of the NASA Nebula offering when we hosted applications for the Whitehouse – those prices are a matter of public record.

          The calculator takes into account, and is adjusted for:
          – Regional power costs
          – Regional staffing costs (fully loaded)
          – DC footprint expenses (whether owned or co-lo)
          – CapEx (with or without depreciation)
          – Software licensing

          When comparing to other offerings, such as AWS or a VMWare-based private cloud, we typically make ROI calculations based on the most favourable list pricing (although in reality, many of VMWare and Amazon’s largest customers don’t pay anything close to list price.) We also calculate CapEx based on list pricing – again, this is not necessarily what our customers will pay in volume.

          Bandwidth costs are usually estimated based on likely workload – for many prospects, these are already sunk costs in their LAN environments.

          As others have pointed out in the past, the biggest factor for the “simple” economics case is load variability – but putting that another way, most large enterprises have enough workload DIVERSITY to achieve the cost efficiencies of being “multi-tenant”.

          Outside of headcount (which is typically the dominant factor in TCO), there are the per-incident costs, the ability to provision workload-appropriate cloud infrastructure (including SSDs, low-latency networking, or alternate ratios of RAM to CPU), and the bizarre but very-real tax advantages of carrying depreciating assets on your own balance sheet (instead of ‘donating’ such depreciation to your vendors).

          As a final point, I don’t believe Gretchen was referring to physical assets in the concept of “home equity” – but rather, the “system inertia” of a large corpus of data. is the new lock-in.

          • http://twitter.com/khazret_sapenov Khazret Sapenov

            Joshua,
            Given that Gretchen is talking about ‘own rather than rent’, I assume she means private/on premise cloud infrastructure, that has barriers to entry in form of upfront capital requirements, that is not an option for many customers and doesn’t entirely support the notion of elasticity, which is one of important cloud postulates. As a consequence, peak load boundary is limited by the depth of your pockets (in financial sense), and even if you magically scale down the load, you still have to pay fixed costs for all resources (hardware, software, support etc).

            You may increase utilization of your infrastructure (what you call a ‘diversification’), but that doesn’t help a lot.

            More efficient hardware would accommodate more load, but you still have to: a) pay for it (what is industrial level SSD cost?)
            b) depreciate/replace it (what is MTBF for average SSD?)

            As for big data, it just supports points above on transition of fast growing data to public cloud, since you’ll have to provision some compute resources to analyse it and get some valuable insight.

  • http://twitter.com/DavidAndGoliath David

    Cheaper to own vs rent: Certainly valid until you then take into consideration the cost for sysadmins, though “renting” doesn’t exactly null the requirement for them — it leaves a lot of the responsibility on the cloud provider’s side mitigating mental bandwidth that your sysadmins need for more critical stuff.

    Your landlord doesn’t…: Not entirely true, providers succeed when their clients succeed. You’ll rent more systems from softlayer when you need more systems. Win win, this is applicable in any industry — whether you’re supplying soda to a grocer or network capacity to a company.

    There goes the neighborhood…: That is also applicable on shared, dedicated and colo. You’re inevitably next to strangers unless you control 100% of the stack from top to bottom, and even then you can be affected by all kinds of internet garbage floating around. That’s where *redundancy* plays a role, not becoming an island.

    Build home equity: Meh, truly invalid in light of just how quickly hardware becomes obsolete.

    The truth is all this teaches anyone is that they should build redundancy into their applications — that applies equally to someone with their own racks full of owned systems, rentals, or cloud based solutions. Inevitably a switch or hard-drive will fail somewhere and you should hire people that know how to have applications grapple around that on the fly, vs. waiting for it to happen & then scrambling.

    • gretcurtis

      David – thanks for your feedback. I agree about headcount being extremely expensive. A large part of what makes Piston Enterprise OS awesome is that, through automation, we are able to dramatically reduce headcount in the data center. In an enterprise environment with thousands of servers, the savings really adds up. I also agree that not every provider is created equal when it comes to customer service. Softlayer, specifically, seems to really rub people the wrong way in this regard ;) I should have probably emphasized that this blog post – and our product – is aimed at enterprise companies that deliver mission-critical services and applications to thousands of users internally at their organization, and specifically enterprises that deal with regulatory issues. For many of these organizations, the limitations of public cloud make it a non-viable option.

  • Pingback: What We Learned From The Amazon Web Services Apocalypse | ServicesANGLE

  • Pingback: What We Learned From The Amazon Web Services Apocalypse | DevOpsANGLE

  • http://profiles.yahoo.com/u/V7LGTBIAONDXFOC4A7LRH6LD7U George

    In the conceptual world of IT, your arguments have merit, but unfortunately, when reality hits the pavement, I can assure you that it is just as easy, if not more so, for a company to have downtime in their “Private cloud” vs in the public cloud. As for the owner taking pride, that is a load of hooey – the datacenter is one of the items where costs can be squeezed where necessary. If the choice is between a sales person or an IT person getting the ax because of budget cuts, I expect 8 times out of 10 it will be the IT person. I’ve walked through too many IT centers on Wall Street where wires are strung every which way and when the admins are asked if they have a clue which NIC connects to which switch, they will often laugh. The beautifully run private datacenter is often the exception and not the rule. At least in my experience which stretches 20 years and over hundreds of sites.

    Where you are spot on is the issue of fitting the profile. As long as you fit in the median in terms of performance requirements and architectural preferences, you will be ok. However, this means that you have to spend a considerable amount of time and money working around the profile if you exceed it in any way. That’s where the costs can quickly skyrocket.

  • http://twitter.com/benkepes Ben Kepes

    *hitting head on brick wall as he types*

    Since when was the world quite so binary? Last week JP Rangaswami decried the private cloud as a completely flawed concept, this week it’s PistonCloud trying to put every single organization on earth into a particular pigeon hole. Organizations are different, organization pressures and goals are different, the IT that different organizations need to meet their aims are (yes, there’s a theme here) different.

    Trying to suggest that one flavour of IT is right for everyone is like trying to suggest that one type of Cola suits all – and as both pepsi and coke have seen, that is a message that simply doesn’t resonate with the world…

    Meanwhile this sort of FUD simply makes our entire industry look bad…

    “shakes head in frsutration*

    …sad Ben

  • Pingback: Inside the Cloud | True Ventures TEC Program