I think we are agreeing here, we're just phrasing it differently. I didn't mean to imply there was a direct cost comparison; just that part of your payment is for them to fund someone's paycheck. In the grand scheme of things it's definitely cheaper to maintain a high ratio of machines-under-maintenance to systems administrators.
That being said, the difference is Amazon pays an administrator to watch potentially thousands of machines of which you may be using a tiny fraction. You're essentially paying for a very tiny fraction of an admin's time (somewhere) who isn't vested in your business nor does he care that your site is acting wonky. He's just answering and working through tickets (if you bought support). Cloud providers can be come markedly less helpful the instant you (attempt to) deviate from the very carefully maintained cookie-cutter pattern they've set out for you.
I think this is a false economy. You're just paying your provider to employ people that are capable of fixing these problems instead of in-housing them.
By and large, if you manage physical, owned infrastructure the same way you manage cloud resources. That is: automated configuration, monitoring, and deployment. The vast majority of the time it's the same process. You just need to make sure that your instrumentation is sufficient to notice when things aren't running correctly and remove machines from service until someone can figure out what happened. This could be in the form of an outside tech or in house support. Either way, at clusters of this size a loss of one, or even 5 machines should not be the difference between everything working and a colossal systems failure.
I've been on the other end of this spectrum too. Working with a very high profile company (that I unfortunately can't name) we were paying what I'm going to call an astronomical rate for managed cloud operations. Dedicated data center admins, systems administrators, the works.
We would have a problem with something like IO throughput on database instances. We would open a ticket, wait a little while, get a response. If we claimed it was hardware related (because we couldn't tell from our host's perspective) we got the response "it's not the hardware, everything seems fine." This would go on for days. Then eventually, after we had to prove the numbers were erratic or unresponsive we would eventually get a more helpful response. Maybe.
It's a very cold splash of water in the face when you realize that your hosting company, cloud provider, whatever is not in business to hold your hand. If you need more than their minimum level of support or require human interaction you will be sadly disappointed. These companies maintain their margins by automating hardware provisioning, homogenizing infrastructure, and making it as turn-key as possible. Which is all fine and good until you need something their infrastructure doesn't provide for. Like switch bandwidth. Like larger instances. Like all your VMs in a local rack.
You will have hardware problems in the cloud too and they will not be obvious. You will need the same degree of monitoring software you have anywhere else in any other environment.
From a "what you get" perspective I totally agree with you. I simplified the comparison to core count to have an easier basis to setup the rest of the analysis.
I would not be the least bit surprised if I halved those hardware numbers and it kept up just fine; mostly for the reasons you pointed out.
To be honest it's impossible to tell without actually measuring it. The #1 rule of scaling a system is to measure the variables your trying to optimize, make a change, and then take measurements again. So without knowing the kind of software that's running on this we have to leave everything in terms of a theoretical workload.
If you aren't doing graph operations, then 50 dedicated servers can do a pretty impressive workload. Add in graph-ops and all bets are off :-). The same could apply for user-generated content (eg youtube, facebook, vimeo).
Stackoverflow is another great example of a company that vertically owns their stack. Check out:
It's a classic lease vs. buy argument. If you only need a resource for a day, then relatively speaking, it's cheaper. However, if you pay the rental fee every day for a year, it gets more and more expensive than an outright purchase. The comparison largely depends on the time scale you look at.
The main reasons I'm aware of that provisioning dedicated servers take longer is because you have to deal with data center logistics. Which rack does it go in? Which VLANs does it need to be in? What bandwidth is the customer paying for and how will we route the uplink? If the customer has other machines can we put these new ones in the same rack without overloading the PDU?
There's a lot of hidden work that goes into data center management.
It was more of a comparison of the two extreme ends of the spectrum. Total hardware control vs. no hardware control. You're absolutely right that companies like iweb and softlayer offer great intermediate approaches. Personally, I have some great experience with softlayer but didn't want to make the article that long by including a third option/analysis :-).
Even still though, comparable hardware on softlayer's pricing looks like it's about $659/month. After 3 months it approaches a similar (but not identical) cost to the colo option.
That's why I made sure to document that. I have some clients that have an even higher disparity between their peaks and valleys that makes cloud hosting very viable. Auction type sites are a great example. As the time to an auction ending approaches zero everyone starts mashing refresh, but if nothing is going on the activity is almost zero.
I just wanted to clarify it isn't a one-size-fits-all.
I spent some time trying to put together some numbers. From the research it looks like cost pressure against traditional colocation options has forced the pricing to come down. It still looks like owning your own hardware is a viable, and if you have people, good option.
That was a large motivation behind this. I think a slightly larger problem then their lack of functionality is their arcane-at-best documentation. I'm trying to make the whole standard more approachable in general.
While I generally agree that the OpenSSL library is somewhat horrendous, this specific use-case addresses a very tiny subset of what the library does internally to do some real magic.
I used to work for a very large public facing certificate authority and there was a period in which one of the public CA systems used OpenSSL, so we had to be able to call several of the signing functions via a JNI extension. Why? Because OpenSSL has fairly remarkable support fir internal context objects that allow you to designate PKCS#11-interfaced hardware security modules for private key operations.
Yes, the levels of indirection are painful to read through and when you get down to the levels where you can actually do a signing operation you have multi-level points (something) of strange types, but it works almost magically when you need it to.
It's also the combined with the intersection of handling/reading certificates. The IO interface has to correctly handle PEM and DER information. Even if you can parse those structures all you're left with is ASN.1 annotated structures and ASN.1 is an exercise in pain.
So a library that can read a broad format of single-bit sensitive data, correctly decode and preserve the structure of ASN.1 entries, perform crypto operations, and then somehow make sense of it all across how many years is mostly likely going to be complicated as hell. Or at the very least, given my proficiency with C I think I would have a hard time coming up with a library that worked on as many platforms as transparently for as many years.
That being said, the difference is Amazon pays an administrator to watch potentially thousands of machines of which you may be using a tiny fraction. You're essentially paying for a very tiny fraction of an admin's time (somewhere) who isn't vested in your business nor does he care that your site is acting wonky. He's just answering and working through tickets (if you bought support). Cloud providers can be come markedly less helpful the instant you (attempt to) deviate from the very carefully maintained cookie-cutter pattern they've set out for you.