The Cloud Procurement Pecking Order

I was planning to go to this meeting here in town about “Preparing for the post-IaaS phase of cloud adoption” and it brought home to me how backwards people are generally thinking about cloud. So now you get Ernest’s Cloud Rant of the Day.

What people are doing is moving in order of comfort, basically.  “I’ll start with private cloud… Then maybe public IaaS… Eventually we’ll look at that other whizbang stuff.” But here’s what your decision path should be instead.

Cloud Procurement Flowchart

  1. Is it available as a SaaS solution?  If so, use that. You shouldn’t need to host servers or write code for many of your needs – everything from email to ERP is commoditized nowadays.
  2. Can I do it in a public PaaS?  Then use a public PaaS (Heroku/Beanstalk/Google App Engine/Azure), unless you have some real (not FUD) requirements to do it in house.
  3. Can I do it in a private PaaS? Then use Cloudfoundry or similar. Or do you really (for non-FUD reasons) need access to the hardware?
  4. Can I do it in public IaaS? Then use Amazon. Or do you really (for non-FUD reasons) need it “on premise” (probably not really on premise, but in some datacenter you’re leasing – which is different from being outsourced in the cloud why)?
  5. Can I do it in a private cloud? This is your final recourse before doing it the old fashioned way – unless you have extremely unique hardware requirements, you probably can. Also, you can do hybrid cloud – basically private cloud plus public cloud (IaaS only really). This gets you some of the IaaS benefits while complicating your architecture.

What About The Cost?

This seems to be inverted from how people are inching into the cloud. But the lower on this list you are, the less additional value you are getting from the solution (assuming the same price point). You should instead be reluctantly dragged into these lower levels – which require more effort and often (though not always) more expense. “But what about the cost,” you say, “the cloud gets more expensive than me running a couple servers?”

You need to keep in mind the real costs of your infrastructure when you do this – I see a lot of people spending a lot of work on private cloud that really shouldn’t be. If you simply compare “buying servers” with “cost per month in Amazon” it can seem like you need to go hybrid after a couple hundred thousand dollars appear on your bill. But:

1. Make sure you are taking into account your fully loaded cost (includes data center, power cooling, etc.) of all assets (servers, storage, network…) you are using to do this private. Use the real numbers, not the “funny money” numbers – at a previous company we allocated network and other shared costs across the entire company, while “our IT budget” had to pay for servers – don’t be a goon,  you should consider what it’s costing your entire company. Storage especially is way cheaper in the cloud versus enterprise SANs. 

2. Make sure you are taking into account the cost of the manpower to run it.  And that’s not just their salary (fully loaded with benefits/bonuses), and the proportion of each layer of management going up that has to deal with their concerns (Even if the director only has to spend 30% of his time messing with the data center team, and the VP 10%, and the CTO 5%, and the CEO 1% – that’s a lot of freaking money). It’s also the opportunity cost of having people (smart technical people) doing your plumbing instead of doing things to forward your company.  I would argue that instead of putting in the employee’s salary, you’d do better to put in your revenue per employee!  Why? Because for that same money you could be having someone improving product, making sales, etc.  and making you additional revenue. If all you look at is “cost reduction” you are probably divorced enough from the business goals of your organization that you are not making good decisions. This isn’t to say you don’t need any of that manpower, but ideally with more plumbing being outsourced you can turn their technical skills to something of more productive use. 

3. Make sure you are taking into account the additional lag time and the cost of that time to market delay from DIYing. Some people couch this as just for purposes of innovation – “well, if you’re a small, quick moving, innovative firm or startup, then this velocity matters to you – if you’re a larger enterprise, with yearly budget cycles, not so much.” That’s not true. Assuming you are implementing all this stuff with some end goal in mind, you are burning value along with time the longer it takes you to deliver it – we like to call that cost of delay. Heck, just plain cost of money over that period is significant – I’ve seen companies go through quite a set of gyrations to be able to bill 30 days earlier to get that additional benefit; if you can deliver projects a month earlier from leveraging reusable work (which is all SaaS/PaaS/IaaS are) then you accelerate your cashflow. If you have to wait 12 months for the IT group to get a private cloud working, you are effectively losing the benefit of your deliverable * 12 months.

4. Account for complexity.  The problem with “hybrid cloud,” in most implementations, is that it’s not seamless from on prem to public, and therefore your app architecture has to be doubly complicated.  In a previous position where I ran a large SaaS service, we were spread across AWS (virtual everything) and Rackspace (vserver, F5 LBs, etc.) and it was a total nightmare – we were trying to migrate all the way out to the cloud just so we could delete half of the cruft in all our code that touched the infrastructure – complexity that caused production issues (frequently) and slowed our rate of delivering new functionality. The KISS principle is wrathful when ignored.

I’m not saying hybrid cloud, private cloud, etc. are never the answer – but I would say that on average they are usually not the right answer, and if you are using them as your default approach then it’s better than even money you’re being inefficient. Furthermore, using SaaS and PaaS requires less expertise than IaaS which uses less than private cloud – people justify “starting with private” because you are “leveraging skill sets” or whatever – and then 6 months later you have a whole team still trying to bake off OpenStack vs Eucalyptus when you could have had your app already running in a public PaaS. I’m not sure why I need to say out loud “delivering the most amount of value with the least amount of effort, time, and expenditure is good” – but apparently I do. Just because you *can* do something does not mean you *should* do it.  You need to carefully shepherd your time to delivery and your costs, and not just let things float in a morass of IT because “these things take time…” 

5 Comments

Filed under Cloud

5 responses to “The Cloud Procurement Pecking Order

  1. 1. Even if you add the fully loaded cost of things like power and networking, running your own infrastructure in a colo environment is significantly cheaper once you get to large scale e.g. $100k/m plus on AWS et al.

    2. It’s not true that moving to cloud infrastructure means your team doesn’t have to engage and you can save on costs of people – you still need those teams to build the infrastructure correctly (using the right APIs and architecture) and to do ongoing management (instance lifecycles, building new infrastructure for new projects, etc). It’s just you don’t need people to deal with hardware or raw networking. The skillsets change, not the need for people.

    3. Lag time is relevant and is a great use case for cloud – it makes it very easy to prototype and scale out for both test and production before you know what your traffic patterns will be. Once you have predictable workloads then that’s the point to move over to considering running things yourself.

    As a reference for this, see the case study at https://blog.serverdensity.com/saving-500k-per-month-buying-your-own-hardware-cloud-vs-colocation/ for how Moz moved off AWS. This is a very similar pattern seen across companies as they scale. See also http://www.feld.com/archives/2014/07/amazons-scorpion-problem.html

    • Thanks for your added tips David. Determining traffic patterns was once a task my team and I overlooked on a project, the consequence of which was several tens of hours spent trying to determine the cause on a production system which had worked perfectly as a prototype.

  2. David, you stole most of the words out of my mouth. I have found that the hybrid of hosted physical servers removes most of the complexity from costing the network, power, etc. This, sort of hybrid, has been cheaper in almost every analysis I have consulted on or been part of.

    Though, conceptually, I believe the future should be what Ernst describes.

    One final note. It *is* possible to do Hybrid PaaS with OpenShift. If you build your applicaiton to take advantage of cartridges, they can definitely be ran at OpenShift.com or on promise with OpenShift Enterprise.

  3. Hey David and Scott. You have some good points, and like I say it’s not “never the time” to go on prem but you have to be careful about when.

    1. Sure, at some point it does become cheaper. I just caution people to use real compares. Like that Moz article you link cites a $4000 database server. In my last corporate IT gig I was unable to convince our admins to go under $7500 for any Dell – “of course it has to have redundant power supplies and all kinds of RAID…” – even though I just wanted minimal nonredundant systems because I planned to make them resilient at the private-cloud level. “Sorry, we have to support them,” they said. Make sure your compare is with what you’ll really use, is all I’m saying.

    2. You don’t necessarily need fewer people – but those people have better things they could be doing. If you’re using the cloud (plus basic DevOps stuff) then “Oh no, we need to go add a new customer cluster!” is an afternoon of work not 4 months of work (I have the project plan from when it was 7 months.) Your operations engineers are able to do things (since they aren’t working at the raw materials any more) that deliver a lot more value. When I was running a hybrid cloud team, I always got cross when instead of my highly skilled, highly paid DevOps engineers doing something with their day that moved the needle forward, hearing “oh we have to drive down to the colo and swap out drives and stuff.” I might as well be flushing money down a toilet if it’s just going to plumbing. Those same 3 ops engineers, in a cloud environment, can accomplish real business goals in that day. That’s why I say it’s not about the salary but about the revenue per employee.

    That’s why I completely discount the statement in the Moz article that “Many will say that the real cost is hidden with staffing requirements but that’s not the case because you still need a technical team to build your cloud infrastructure.” But you are spending that staffing money on receiving less value. Engineers working with public cloud can get you 100 servers in the next 15 minutes – if I walk into your office and use your private cloud, and I can’t get an API key and get 100 servers in that 15 minutes (and/or can’t deliver my new product as quickly) then this statement is provably untrue. Cloud is a force multiplier – one engineer can get 10x the work done, and move on to higher value activities, than if they are 100% utilized on plumbing.

    3. And that segues to point 3. Sure, you can get it working in cloud and then if it’s stable you can build out hardware. But – if that same set of engineers could be building you a new product that’ll deliver $Xk/month gross margin, or can be building out private cloud to reduce costs from the previous solution – even if it takes them the same time to deliver a private cloud as it does to build out a product in a new one (and I’d consider that somewhat atypical), you’d need to be saving $X in costs from the difference. Which is possible, of course – but it’s a far sight from what I see more commonly which is “well now my Amazon bill is $120k and I could put in 6 months of work to get that to on prem for $100k. Obviously it’s a win!” It’s not obviously a win, and making cost decisions in isolation from considering revenue opportunity with that same investment is terrible – it’s of course done in many enterprises where IT has lost touch entirely with the business, but it shouldn’t be.

  4. Pingback: DevOps Newsletter 195 - Server Density Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s