[bob1029]

I've been side-stepping this whole conversation by using as little infrastructure as possible. I'd absolutely be digging into IAC abstractions if I had a circus on my hands and no say over why it had to be a circus.

Going into a "cloud native" stance and continuing to micromanage containers, VMs, databases, message buses, reverse proxies, etc. seems absolutely ridiculous to me. We're now using exactly 2 major cloud components per region: A Hyperscale SQL database, and a FaaS runner. Both on serverless & consumption-based plans. There are zero VMs or containers in our new architecture. We certainly use things like DNS, AAD, VNets, etc., but it is mostly incidentally created by way of the primary offerings, and we only ever have to create it 3 times and its done forever and ever - Dev cloud, Prod cloud, DR cloud. And yes - we are "mono cloud", because any notion of all of Azure/AWS/GCP going down globally and not also dragging the rest of the internet with it is fantasy to me (and our customers).

When you literally have one database to worry about for the entire universe, you stop thinking in terms of automation and start thinking in terms of strategic nuclear exchange. Granted, one big thing to screw up is a big liability, but only if you don't take extra precautions around process/procedure/backup/communication/etc.

The benefit of doing more with less also makes conversations around disaster recovery and compliance so much easier. Our DR strategy is async log replication of our 1 database. I really like the abstraction of putting 100% of the business into one place it magically showing up on the other side of the flood event.

How about this for a litmus test: If your proposed solution architecture is so complicated that you would be driven to IAC abstractions to manage it, perhaps we need to re-evaluate the expectations of the business relative to the technology.

[llama052]

> Going into a "cloud native" stance and continuing to micromanage containers, VMs, databases, message buses, reverse proxies, etc. seems absolutely ridiculous to me.

Honestly you're just paying the cloud provider to manage these things behind the scenes for you. Which is fine but also has its own risks. If you can keep your product that simple for the business then that's pretty incredible.

I do suspect that's not a common situation though, at least in my experience.

[nonameiguess]

This is a nice perspective from the developer of a single application, but as a platform developer, I'm usually dealing with using IaC tooling to set up multi-tenant environments. I can't just deploy one database because there may be 50 different teams working on 50 different sets of problems, some of them basic research, some of them products, some of them purely exploratory, and there are often legal restrictions on who is even supposed to be able to make a network connection to a particular database, so simply using roles and users built into the DBMS engine itself isn't good enough to achieve the required separation, not to mention they need to be encrypted at rest with different keys. This often needs to be done across separate accounts within the same cloud provider for budgeting and accounting purposes as well, so they couldn't just share a resource even if it was otherwise okay for them to potentially step on each other's work.

[gunapologist99]

ransomware, cancellation, billing snafus, attackers, insiders,..

https://threatpost.com/hacker-puts-hosting-service-code-spac...