Cloud Pricing is ridiculous ... made the comparison between a dedicated server and cloud offerings of microsoft, google, amazon ... rackspace (SO EXPENSIVE) and you pay 5 times in the cloud for the same.
Restaurant prices are ridiculous ... made the comparison between groceries and menu offerings of McDonalds, Taco Bell, Burger King ... Olive Garden (SO EXPENSIVE) and you pay 5 times at a restaurant for the same.
---
You're not paying for hardware. You're paying for hardware, expertise, services, and convenience.
On-prem or colocation may be a good choice. But limiting your comparison to raw computing power mischaracterizes the decision.
While undeniably true, you have to look at the levels of redundancy. With a dedicated server, if the box dies you're offline, if the storage dies you may lose data, etc.
Plus, there's also a premium just for access to the ecosystem/APIs. You are often paying for the theoretical convenience of being able to spawn additional instances programmatically.
Absolutely true - however, in a true "apples to apples" comparison, if you're only running a single EC2 instance (for example) and it dies you're offline as well - AWS does not "automatically" have a failover setup for you. In this case 2 dedicated instances with a load balancer is going to get you the same setup you'd get on AWS (only likely cheaper and a lot more powerful setup).
Like someone else said, your VM can die as well, the cloud provides some HA services but there are hosted/standalone versions as well. I think the real question is how spiky is your usage, even with renting bare metal you still can't scale dynamically like you can with cloud VM - if you need 5x the capacity to cover spikes you might as well use cloud and all the fancy stuff you get with it.
And you can use both at the same time (dynamically scale up through cloud, bare metal predictable workloads)
We're moving to AWS for our next release, managed by Rackspace. Had the same philosophy as you for years, and have saved a lot of money with DIY (maybe in the tens of thousands).
Turns out server admin is not my skillset, and it's caused problems, headaches and risks in the past.
I consider the additional cost going forwards in effect as our next hire and an important one. For small startups looking to save money DIY can be a good option, but moving onto the cloud at a later date can be a big burden.
Appengine (and I believe Elastic Beanstalk) are those magic buttons. I've used Appengine for years, and have loved not having to worry about patching, OS upgrades, scaling or redundancy.
If you're a small shop, this lets you concentrate on your core product instead of your systems. And by "small shop", I really mean "pretty big shop" - you're going to be a globally significant player before your Appengine charges get near a sysadmin's salary.
An ex-gig of mine lost their major customer, the new agency moved them to AWS (and poached a few staff, which is how I heard this story). The hosting(inc bandwidth) costs jumped to _nine times_ the previous arrangement, and the website performance dropped.
So far as I know, the guy who masterminded that has not been fired...
You're paying people to maintain your machines. You're eliminating the need for your own sys-admins to keep your servers up to date and patched. For small businesses who have no IT staff for instance, this is exactly what you want.
Yes, but cloud scales in a way dedicated servers simply cannot. I agree that a lot of people use cloud when they shouldn't, but there are a number of cases where it remains very relevant.
1. Eight socket R1 (LGA 2011) supports
Intel® Xeon® processor E7-8800 v4/v3
family (up to 24-Core)
2. Up to 24TB in 192 DDR4 DIMM slots
That's 192 cores / 384 threads with 24TB of DDR4 RAM
-----------
The amount that you can vertically scale with physical servers is far above and beyond what is offered by cloud services. Although I'm impressed that Amazon is now at the 2TB DDR4 RAM level.
> Scaling vertically only buys you time until you are forced to scale horizontally.
Why not both?
> That and "one huge server" is rarely the best design decision.
I never claimed to build only one server. Only that dedicated scales vertically far more than cloud.
There's absolutely nothing stopping me from buying multiple 4TB servers if I wanted to. The reason you go vertical is because Intel's QPI is ~25.6 GB/s (That's big-bytes: so over 200Gbit), far faster than any switch or router on the market. (10-gbit Ethernet, or maybe fiber at 40-gbit if you go really expensive)
You CANNOT scale processes faster than Intel's QPI. Vertical scaling gives you faster communications than even the most expensive switches on the market.
I do releases by baking a new virtual machine with the code+config built in and booting it. I guess it's possible to do that on real hardware, but calling it simply "harder" borders on disingenuous.
I basically do that for my Xen VMs with NixOps in the "no provisioner" mode. Would be exactly the same for bare metal, plus I get dev VMs that match the prod environment for free.
Keep in mind you get up to 75% discount at AWS for 3yr term upfront payments for reserved instances... (In reality, anything I use only seems to get a ~60% discount for that)
But nobody uses AWS 'cause it's "cheapest". That's completely missing the point.
It makes sense if you need to spin up several servers really fast. Like, "I can't wait 2 weeks for my Supermicro reseller to ship and build them" fast.
There is likely some optimal schedule where you start w cloud, order DIY replacements, and migrate, and repeat as you scale. Labour-intensive though.
What comparison? Can I simply ask the colo for a brand new dedicated server every time the machine dies or I want to do a new release? Do they offer services to provision, start, and load balance to new dedicated servers when the ones I have are at high utilization?
No? They don't? Maybe that's because you're comparing fundamentally different things that are only superficially similar to each other.
---
You're not paying for hardware. You're paying for hardware, expertise, services, and convenience.
On-prem or colocation may be a good choice. But limiting your comparison to raw computing power mischaracterizes the decision.