As an "onPrem" & "Big Data" guy I've been astonished at how fast the bill can run up.
We are in the middle of a cloud adoption where the big proponent started with "its just money, devs time costs more.. do what you gotta do" to "hey so we need to consolidate these 3 DBs, and X is on vacation so lets spin this service down, and lets not worry about multi AZ/region yet" .. all before we even have a PROD launch, lol.
In any case, was recently amazed at the cost of an RDS instance to host a meager 2B total records of vendor data. For the annual price I could buy one of the beefy servers I use to host 20% of my entire on-prem estate with 100s of vendor data sets. For my on-prem plant, 2B records is table stakes and we have datasets we receive that much data every day. Probably have something like 10T records of data across datasets if I had to speculate.
Similarly on the ops/infra folks cost save, for every on-prem infra guy they think they can RIF, they've hired a cloud infra guy who for sure costs more.
Likewise for the redundancy/backups/etc being "easy/free" in the cloud, we've already lost data in object store because of poorly execute combination of configuration & actions when try to do some permission changes/copy migration. It was completely unintentional and not noticed for weeks. No one actually executed a literal rm command at the time. Just because the object store advertises zero loss / versioning / etc, you really do still need to do backups.
Clearly theres a lot of ephemeral & burst compute / variable cost stuff that totally belongs in the cloud. However for internal apps at a firm where the usage is largely scaled with staffing levels, the amount of fixed compute makes it hard to argue every app and every use case belongs in the cloud.
That is the core argument. It can be true, but it's not always true. The larger your cloud footprint gets, the less true it often becomes. It's also not true if you are doing something that really slams one of the cloud's high cost areas like outbound bandwidth or tons of sustained compute.
If you are running a business or department it's your job to run these numbers properly and not listen to mindless cloud salespeople or developers brainwashed by them.
The cloud is great for prototyping. As you scale there usually comes a point at which the cloud cost line crosses the "hire one or two people" line. If you think you have to hire five or ten people, your architecture is probably too complex.
Of course the cloud industry really pushes complex architectures hard because they know this. Complexity works in their favor on both ends. It makes it harder to get off managed services by adding labor costs and it also means you have to run more stuff in their cloud.
It's interesting to think about the process that lead to this: "its just money, devs time costs more.. do what you gotta do"
Are cloud vendor salesmen doing jedi mind tricks? Or are these decisions just made by incompetent people? Who researches this kind of stuff? It's some kind of a management trends history subject.
There’s also a lot of politics around OpEx vs capitalEx.
In prior firms we’d have to go hat-in-hand for $3M of hardware every 3 years on an upgrade cycle. Of course few were around long enough to be on the requesting or approving side of this upgrade cycle and it would drag out painfully. Sometimes we’d try to get creative and go more just-in-time and come back for $500K every 6 months but the pain would just be more frequent.
On the other hand, $150k/mo slowly growing adds up to more in the longterm, but no senior manager ever has to approve a single $500K-$3M purchase request.
Depends on where the budgets go - salary goes into something they have to answer for - "cloud infrastructure" goes elsewhere in the budget they don't have to answer for.
There's also the thousand cuts - if you want a big server, you will have to do lots of discussion and arguing about the cost there of, but if instead you're adding a small monthly cost, the arguing isn't as much.
You keep doing that and suddenly someone notices that half the budget is AWS, at which point the "move onsite" dance begins (until the next time the big server argument happens).
I think Elon Musk got technically demoted but at any rate shuffled around for wanting to use Microsoft for the servers, Paypal ended up using Unix instead.
If RDS is expensive, you can always spin up your own DB deployment, you can use an EC2 instance, or you can just run it via ECS or EKS.
You buy those beefy servers, and where do you put them? you need a data center, where you need data center grade internet lines, you need staff to maintain all that.
> Similarly on the ops/infra folks cost save, for every on-prem infra guy they think they can RIF, they've hired a cloud infra guy who for sure costs more.
I disagree, you will need less cloud infra people, who will likely cost more, however everything will end up being more reliable than having a legion manually maintain everything.
> Likewise for the redundancy/backups/etc being "easy/free" in the cloud, we've already lost data in object store because of poorly execute combination of configuration & actions when try to do some permission changes/copy migration. It was completely unintentional and not noticed for weeks. No one actually executed a literal rm command at the time. Just because the object store advertises zero loss / versioning / etc, you really do still need to do backups.
Did you ever lose data by properly putting something to S3 or Glacier and not doing anything with it?
> However for internal apps at a firm where the usage is largely scaled with staffing levels, the amount of fixed compute makes it hard to argue every app and every use case belongs in the cloud.
It's actually easy to argue:
- the world is not going to stay stagnant, if I need 1 more server tomorrow, I can get it in minutes on the Cloud, use it and get rid of it whenever I no longer have a need for it.
- the on-prem costs are downplayed, people usually just talk about the cost of the metal and forget the upkeep and extra staff required
- the on-prem reliability can be very questionable, hardware failures can cause disasters
- cloud stacks can be easier to maintain and hand over, you have less hardware and less operating systems to worry about
In any case, was recently amazed at the cost of an RDS instance to host a meager 2B total records of vendor data. For the annual price I could buy one of the beefy servers I use to host 20% of my entire on-prem estate with 100s of vendor data sets. For my on-prem plant, 2B records is table stakes and we have datasets we receive that much data every day. Probably have something like 10T records of data across datasets if I had to speculate.
Similarly on the ops/infra folks cost save, for every on-prem infra guy they think they can RIF, they've hired a cloud infra guy who for sure costs more.
Likewise for the redundancy/backups/etc being "easy/free" in the cloud, we've already lost data in object store because of poorly execute combination of configuration & actions when try to do some permission changes/copy migration. It was completely unintentional and not noticed for weeks. No one actually executed a literal rm command at the time. Just because the object store advertises zero loss / versioning / etc, you really do still need to do backups.
Clearly theres a lot of ephemeral & burst compute / variable cost stuff that totally belongs in the cloud. However for internal apps at a firm where the usage is largely scaled with staffing levels, the amount of fixed compute makes it hard to argue every app and every use case belongs in the cloud.