You'd still save a lot of money compared to cloud servers, need little admin work (the same compared to compute instances – amazon's EC2 servers), and have a reliable server. Providing the servers doesn't take forever, either. Some bare metal servers are up and running within 120sec, though, you can't just shut them down and stop paying like cloud servers.

Companies that offer these services are OVH.com and softlayer, though softlayer always seemed to be a bit expensive. I'm sure you'll be able to find similar companies though.

I can see that this makes little sense to startups because the admin work is way more expensive but for bigger companies, this should not be the case (I don't consider Spotify and Netflix a startup anymore).

Isn't that what Amazon does? (even though they are virtual servers)?

You'd still save a lot of money compared to cloud servers,

Can you post some numbers? A 24 core 48GB Dell server with 3x120GB SSD's costs around $11K, or around $300/month for a 36 month lease.

An 8 core 15GB 160GB AWS c3.2xlarge costs around $200 each per month with a 3 year reserved instance. 3 of them will fit in one of the Dells, so it would cost around $600/month, or about $300 more than the raw purchase price for the hardware alone.

But also with that price you get network, power, cooling, rack space, maintenance, etc, so it's not clear that buying and running that server is significantly cheaper.

Some bare metal servers are up and running within 120sec

How long does it take if you want 500 of them? And 2 hours later you want to turn them off. Then 2 hours after that you want to bring them all back online again.

you can't just shut them down and stop paying like cloud servers.

But that's the big value-add in Cloud servers, it's capacity on demand so you only pay for what you us -- need to spin up 500 servers to run month-end processing? You only need to pay for them for the few hours or days a month when you need them.

Further, you can add multi-datacenter or multi-region redundancy at very little additional cost - you don't need to keep those redundant servers running when you're not using them.

See http://www.pythian.com/blog/virtual-cpus-with-amazon-web-ser... for more details.

I have a feeling that a lot of faults that in the google infrastructure result in 2 minutes down time, or even just a raised eyebrow in the ops centre would put most SME's (or event big corporates) on there arse for a week. Do you have a spare generator? If main power goes how long do the UPS keep you going for ? If you have a dc fire what happens... These are things that you can plan for but need real capability to deal with, capability that needs scale.

Take for example something old school and established (ZzZzZ) - accounting.

Say you are an accounting firm with an established IT infrastructure and you now want to launch a new service that will allow new smaller clients to perform certain tasks even a single one (say fixed assets devaluation for deductibles). The core of the service is a messaging API as it's an accounting application it's usage wont be fixed and the product team estimates that on a normal week it will handle 20,000 requests, on a end or the quarter week it will handle 500,000 and at the end of the financial year it will handle 2,000,000 how do you scale this?

Say a single server will 20,000 request so you have here a 1 to 100 scaling between peak and normal usage which means that if you own your own infrastructure you are paying for 99 servers to idle during most of the time. Even if you can some how manage to do some inner-organizational thin provisioning you will still be wasting allot of hardware because as it turns out most of your other internal services also follow a similar usage trend so that might not be an option to begin with.

Now you can rent VPS/IAAS from say Amazon or Rackspace but then you still have a huge overhead sure you'll pay less for usage because those 99 instances will be down but you still need to pay for other resources e.g. reserved IP addresses and storage, you need to practice and test the machines every couple of weeks/months and you need an live-ops/sys-admins with balls of steel to be confident enough to agree to spin up 99 instances at the very last moment and hope that everything will work out smoothly.

But even that doesn't really solve it because it doesn't allow you to be flexible with onboarding new costumers, it can't predict various trends like a change in legislation or a holiday weekend prompting people to use your service earlier / later than expected.

But if you say just use a PAAS/SAAS messaging service all of this goes away, you don't worry about scaling as long as the service can handle your peak traffic, you don't worry about waste because you pay what you use so if you've only sent 18796 messages in week 37 you pay for that exact amount, you don't need to worry about some promotion that the marketing and product dev team was running that caused an influx of new customers without telling you, and you don't have to really worry about down time, backups, and even security (as long as you get sufficient assurance from your service provider) because as long as their service is up you are up and running.

Not to mention that often it can takes weeks for new hardware order to be approved / delivered / provisioned.

Cloud? Just dial it up... Well, if you are at Netflix scale, you probably couldn't just dial it up, and would have to work with the vendor to ensure adequate capacity was available for your use.

As for hardware failures in general, you can afford to have some complete extra servers on hand doing nothing most of the time with the amount of money you'd save on renting bare metal instead of paying for cloud. Or if engineered properly, you'd be using all the machines at once but be able to afford to lose half of them, and failover automatically.

Yes, a cloud (bunch of VMs on a cluster) is going to be more reliable than a single machine, as you get hardware redundancy. But a cluster of machines with hardware redundancy is going to be much more reliable than a bunch of VMs on a cluster, as there's less complexity involved without the cloud stack, and thus fewer points of failure.

Public clouds are an efficiency gain for both the datacenter and the end user. The bottom line to me is more engineers are focused on operating and improving the public cloud than the state of the art managed dedicated racks from 2014.