[patio11]

The cost of the database to an enterprise is not dominated by how much the license for the software costs, the hardware costs, or the electricity costs. It is dominated by how much you have to pay in headcount to manage it. At many companies, that app would have two people whose full-time job would be "Do everything Heroku ops would do, except slower and suckier."

I get this same question from some potential customers for AR, too: "Why would I pay you $X a month when I could buy a competitor's dedicated appliance for $X and then just pay for phone calls?" "Who is going to maintain that appliance?" "What do you mean maintain?" "Like, if a security vulnerability is discovered in a technology AR uses, I stay up all night. Do you have a guy like that?" "... No." "Do you know what a guy like that costs?" "... Uh, plumber money?" "Doctor money." "Shoot."

[jiggy2011]

To be fair I'm surprised how often I see a rack mounted solution sitting in an office somewhere with no patches applied since ~2005.

"Your email has always been slow you say? That's because it's been running a botnet C&C server for some considerable time"

[jkat]

The cost can be so out of whack that it can become cheaper to hire talent. Two things make this truer: the person might have spare time to do other things, and sensitivity to things that PaaS are poor at: raw processing speed, memory or SSDs.

I've seen it over and over again with SaaS: server monitoring, logs, statistics, ...

We had an internal fight recently about how to manage our logs. Group A wanted to spend thousands a month on Splunk. Group B spent a weekend setting up logstash + kibana and deploying it in production.

Server monitoring? Nagios. Stats? statsd+graphite. Even if you have to outsource setting it up, it'll probably be cheaper from the very first month.

[rscale]

Two key points:

1) Many companies already have most of these skills, or can acquire them cheaply and reliably via a service contract. The cloud isn't the only way to outsource operations.

2) The performance/reliability constraints imposed by certain popular cloud platforms can create very expensive development work, distracting developers from doing things that actually create value for customers.

I worked with a successful firm that was close to outgrowing their dedicated server and was considering going cloud. They sketched out an architecture that would get everything to fit into nice little EC2-shaped pieces. But there was a problem: it would take a ton of developer time.

Instead, they spent a fraction of the expected developer cost on some serious hardware, and they were done nigh on instantly. Their developers then used that saved time to do things that actually delivered more value to the customers.

The cloud is awesome when it fits, but it doesn't always fit.