It is more trivial than it seems. How did people manage a Postgres instance prior to RDS? Of the entire feature list, what parts of RDS do you use?

1. Dumping a backup every so often?

2. Exporting its performance via Prometheus, and displaying in a dashboard?

3. Machine disk usage via Prometheus?

4. An Ansible playbook for recovery? Maybe kicking that into effect with an alert triggered from bullet 2 and 3.

5. Restoring the database that you backed up into your staging env, so you get a recurring, frequent check of its integrity.

This would be around 100 to 500 lines of code of which an LLM can do for you.

What am I missing?

There is a lot more - Aurora to handle our spiky workload (can grow 100x from normal levels at times) - Zero-ETL into RedShift. - Slow query monitoring, not just metrics but actual query source. - Snapshots to move production data into staging to test queries.

Besides this we also use - ECS to autoscale app layer - S3 + Athena to store and query logs - Systems Manager to avoid managing SSH keys. - IAM and SSO to control access to the cloud - IoT to control our fleet of devices

I’ve never seen how people operate complex infrastructures outside of a cloud. I imagine that using VPS I would have a dedicated dev. ops acting as a gatekeeper to the infrastructure or I’ll get a poorly integrated and insecure mess. With cloud I have teams rapidly iterating on the infrastructure without waiting on any approvals and reviews. Real life scenario 1. Let use DMS + PG with sectioned tables + Athena 2. Few months later: let just use Aurora read replicas 3. Few months later: Let use DMS + RedShift 4. Few months later: Zero-ETL + RedShift.

I imagine a dev. ops would be quite annoyed by such back and forth. Plus he is busy keeping all the software up to date.

> I’ve never seen how people operate complex infrastructures outside of a cloud

That’s your issue. If all you have is a hammer, everything looks like a nail.

I have the same issue with the junior we hire nowadays. They have been so brain washed that the idea that the cloud is the solution and they can’t manage without them that they have no idea of what to do instead of reaching for them.

> I imagine that using VPS I would have a dedicated dev. ops acting as a gatekeeper to the infrastructure or I’ll get a poorly integrated and insecure mess.

You just describe having a real mess after this.

> I imagine a dev. ops would be quite annoyed by such back and forth.

I would be quite annoyed by such back and forth even on the cloud. I don’t even want to think about the costs of changing so often.

>That’s your issue. If all you have is a hammer, everything looks like a nail.

While I admit lack of experience at scale I had my share of Linux admin experience to understand how it could be done. My point is that building a comparable environment without cloud would be much more than just 500 LoC. If you have relevant experience please share.

>I would be quite annoyed by such back and forth even on the cloud. I don’t even want to think about the costs of changing so often.

In cloud it took 1-2 weeks per iteration with several months in between when we have been using the solution. One person did it all, nobody in the team even noticed. Being able to iterate like this is valuable.

I wanted to comment on this but mistakenly put the answer here. Sorry.

https://news.ycombinator.com/item?id=44335920#44346481

>What you see as “rapid iteration” looks a lot like redoing the same work every few months because of shifting cloud-native limitations.

This is not the case. The reason for iteration is the search for solution in the space we don’t know well enough. In this particular case cloud made iteration cheap enough to be practical.

I asked you to think about what it would take to build well integrated suite of tools (PG + backups + snapshots + prom + logs + autoscaling for DB and API + ssh key management + SSO into everything). It is a good exercise, if you ever built and maintained such a suite with uptime and ease of use comparable to AWS I genuinely would like to hear about it.