The $750/month savings cited here is not real†, but for the sake of argument let's pretend it is.
Is $750/month a significant amount of money for the company? In the USA, this is perhaps the cost of one engineer-day, and one could raise a year's worth of this money by successfully applying for a single additional credit card. (Not that I recommend bootstrapping with credit cards. But it has been done.)
Of course, it may be the case that a company could improve customer satisfaction, and therefore revenue, by double-digits by improving performance on optimized hardware. But if this is the case, where is the discussion of that? Where is the data: A/B testing, customer satisfaction, churn rate, monthly revenue? They should be front and center.
† Without getting into the reduced redundancy, the additional complexity of hosting multiple unrelated services on each instance, the "additional maintenance" referred to in the post, the lack of server capacity to cover emergencies and staging and load testing and continuous integration, and the risk involved in switching infrastructure out from under a working business-critical application... any estimate which doesn't include the cost of engineering time is wrong. All changes have engineering costs. Just talking about this idea is costing engineering time.
Yes, $750 is about one engineer-day. Someone is now going to be spending at least a full day per month managing your new hardware, running security patches, etc. Even if your sysadmin guy is cheaper than an "engineer" it's not going to be cheap.
You realize you need to do all that on the EC2 instances as well, right?
This is the common disconnect I see when people tout The Cloud as a solution to having system administrators - that somehow that instance of Linux running in EC2 doesn't require the same maintenance as a physical one. It does.
Surely you didn't mean to type "physical". Even if Amazon did nothing else, they'd still order, receive, unpack, assemble, rack, stack, power, cool, and network their servers with an economy of scale that I can't possibly match.
And who could ever claim that AWS requires no maintenance? It takes plenty; I should know. But the problem isn't that Amazon is necessarily less expensive, or more expensive, or more reliable, or less reliable. All of that depends on the context. The problem is that the context is rarely reported in this genre of blog post. These posts tend to fixate on the size of the hosting bill. This is the year 2013, and unless its business model is hopelessly flawed, the hosting bill is one of the smallest problems a new company will ever have.
But maybe I'm wrong about that, so I wish these writeups would provide more context to explain why I'm wrong in this or that particular case, and by how much. Yes, I see the hosting bill is down. But are the savings significant to the business? Did the migration take one engineer-day, or twelve, or thirty-eight? Did it reduce the size of the codebase or increase it, and which modules were affected? Is the time required for testing and reliable deployment up or down, and by how much? How has your planning for various disaster scenarios changed? Are you getting more or fewer alerts in the middle of the night?
No, you don't really. You don't need to spend time considering and researching different load balancers to see which one is the best for your use-case, running through your company's purchase process (in itself a big project), lead time, physical install, configuration, and monitoring. If you want an AWS load balancer, click EC2 > Load Balancers and config one. From "Hey, I'd like a load balancer" to having a functioning, active load balancer in literally less than five minutes. No jaunt to the colo necessary. And that's just one item - rinse, repeat for a pile of other aspects as well.
It's not true that AWS gets rid of the need for sysadmins, but it's absolutely not true that you do all the same sysadmin tasks on a cloud service.
This is why we have managed hosting. You can pay someone else to do all that, on a real, physical server, on a network they manage, and have it still come out as much cheaper than AWS. Yes, the turnaround time might be more than 5 minutes. Or, depending on who you go to, it might be less.
I agree. This is an optimization. For many startups, it's not worth prematurely optimizing hosting costs, especially when figuring out the MVP/establishing market/growing customer base.
You're seriously underestimating how much it costs. $750/day is probably low-balling it for anywhere in the country if you also count hiring costs/employee turnaround and training costs.
Also, for the skills implied, have you ever tried to hire a systems administrator who has experience in production environments with all of those aspects of back-end web servers? It's not easy, and it's not cheap.
I have, uh, pretty convincing evidence that $750/day is in the ballpark for the fully-loaded cost of a devops engineer in Boston. It certainly doesn't buy two days of an engineer in Boston.
But Boston is Boston, and SV is SV, and this is estimation, so I'll happily concede a factor of two. Okay. Suppose $750 buys you two engineer-days per month. Same question: Is the $750 important?
Is $750/month a significant amount of money for the company? In the USA, this is perhaps the cost of one engineer-day, and one could raise a year's worth of this money by successfully applying for a single additional credit card. (Not that I recommend bootstrapping with credit cards. But it has been done.)
Of course, it may be the case that a company could improve customer satisfaction, and therefore revenue, by double-digits by improving performance on optimized hardware. But if this is the case, where is the discussion of that? Where is the data: A/B testing, customer satisfaction, churn rate, monthly revenue? They should be front and center.
† Without getting into the reduced redundancy, the additional complexity of hosting multiple unrelated services on each instance, the "additional maintenance" referred to in the post, the lack of server capacity to cover emergencies and staging and load testing and continuous integration, and the risk involved in switching infrastructure out from under a working business-critical application... any estimate which doesn't include the cost of engineering time is wrong. All changes have engineering costs. Just talking about this idea is costing engineering time.