[efitz]

A recurring anti-pattern I have seen over and over is the app that is built and runs on a developer desktop, then becomes business critical and needs to scale and evolve, and eventually fails catastrophically. Maybe the SQL database design or storage system isn’t capable of handling the new I/O requirements. Maybe the creator quits and nobody else knows how it works. Whatever.

On-prem is like that. Yes, you have all the skills to originally stand it up. But you don’t know what you don’t know, and you make a bunch of resource trade-offs, usually by not implementing stuff that you’ll never need (until you do).

That was the point I was trying to make.

As I said though, the unique value of cloud is letting you focus on a business specific problem instead of reinventing wheels that have already been invented many times over.

As other a have pointed out, other benefits are scale-on-demand, pay only for what you use, and agility - if you have a great idea you don’t have to do a PO and wait months for a server.

[electroly]

How many more years do you suppose we need to run on-prem before you can accept that we understand our needs? It's been 10+. We've been running on-prem for a lot longer than we've been running in AWS. Again, there's this sort of paternalistic suggestion that people can't possibly understand how to run on-prem. But we've always been on-prem. We've always maintained a SQL Server cluster. AWS is the new thing.

AWS vs. on-prem is always a tradeoff. You have to look at the costs and benefits for your particular situation to decide which is best. We decided to go with both, because AWS has benefits for our dynamic workloads and on-prem has savings for our static workloads.

[tpetry]

The cloud has the same problem but in a different color. One employee created and managed everything in AWS and then quits. You have the same problem that nobody really knows how to continue from that point. Why was it built that way? Why are the IAM rules like that? etc.

[namaria]

Yeah complexity doesn't go away, you just move it around. The trick is not standing up stuff, that's pretty straight forward with cloud or metal. The real talent lies in understanding that you need to pump the entropy somewhere so you should be aware of the trade-offs and make things that are well organized, explicit and have contingency plans for the future.

[dilyevsky]

Exactly. It actually makes this problem worse bc cloud apis lower the skill level requirement to the point that people who don’t know what they’re doing can create a lot of unmanageable headache in very short time span

[voidnap]

> On-prem is like that. Yes, you have all the skills to originally stand it up. But you don’t know what you don’t know, and you make a bunch of resource trade-offs, usually by not implementing stuff that you’ll never need (until you do).

But what you described sounds like a packaging / software distribution issue.

Like, someone writes a one off Python script or program to do a thing and a year later it doesn't work because the host machine is using a newer version of Python and the dependencies need to be reinstalled to the new site-packages and they didn't document if they used the package manager or a virtualenv and a pip requirements file or setup.py or whatever.

The "it works on my machine" thing isn't really a "cloud" thing? It doesn't really solve the issue of having a weird bespoke service that nobody understands. Even if it's so abstracted from a normal computer that it has some esoteric requirement like an OCI image to run software, if the Dockerfile/Containerfile or whatever that generates the image doesn't exist/work/make sense then you have the same problem.

> As I said though, the unique value of cloud is letting you focus on a business specific problem instead of reinventing wheels that have already been invented many times over.

Reinventing the wheel like with docker ansible terraform kubernetes nomad aws?

Recently I was asked to help a company receive out of office replies to their web service that sent mail from Amazon SES. The client was sending mail from app.foo.org (with MX SPF for amazon) and wanted to receive them to foo.org (MX and SPF for outlook). Setting Reply-To or some other headers to foo.org worked in testing but not in practice. I maneuvered the amazon product menagerie and set up SES to get notifications on out of office replies and that also worked in testing but not in fact. Even then it would not store a list or provide details in the dashboard about replies without further using lambda or SQS or something. Every deficiency in an amazon product is "solved" by another amazon product. You're swallowing a horse to swallow a fly. In the end I just added AWS to the foo.org SPF records along with outlook's and set the From header accordingly; way simpler, didn't need to any more AWS products, and knowledge of DNS is more portable than knowledge of AWS. AWS is in the business of inventing wheels and trying to get you stay in their wheel ecosystem.

Not to contradict everything you're saying like you're wrong or something. I wonder what the circus is like for those of you who run it. Everything you say reads like high-level manager/sales engineer marketing talk from someone who spends all day in meetings. Not to say I'm an authority and that your voice is illegitimate; I'm just a resentful out of touch NEET waiting for the world to change to the point that I have nothing left to offer it.