> If you design a system architecture today, you cannot build the cloud infrastructure, get it to a working state, and then make an immutable snapshot of how the system works, and restore it later if the system changes or becomes unstable
You can. Here's what you'd need:
- a snapshot of the code (eg: git commit SHA)
- a snapshot of the DB schema that correlates to the code (eg: database using linear migrations checked into the code)
- a snapshot of the DB state when upgrades or downgrades take place
- immutable (remove & replace) infrastructure checked into the same git SHA
This requires writing infrastructure, DB schema, and some features a certain way. The problem isn't a technical limitation, it's that you'd have to know a good amount in at least three different domains to set this up, much less run and operate this system. It raises the bar for knowledge well beyond treating each of these systems as isolated systems. That's why most teams don't do it. It's far easier and more realistic for most teams to say" let's fail forward".
That's not true. Immutable infrastructure state should not be dependent on previous state because there is no state. It's remove and replace only.
If there's a piece of infrastructure that cannot be regarded as immutable and this is mimicking immutability behind an API (like a CDN) then it's not immutable. Understanding this and segregating that infrastructure away from totally immutable components (like servers, functions, load balancers, etc) is key.
The CDN mutability probably can be flushed out by some processes like etags but the most important problems are solved, just hard.
As I said, you need to know how that infrastructure is built. Terraform is just fine. If you call to spin up a VM with a disk that's been imaged to a standard, that is immutable. Functions can also be made immutable by programming in a way that takes into account potential shared state.
Ah, state is relative in this context. A VM lacks state when you determine the starting state. A function lacks state depending on how you code it and the contracts you have. A CDN is always stateful. Sometimes the Terraform state overlaps with an entities internal state but most of the time not. "Immutable infrastructure" state refers to internal state, not Terraform state.
You can. Here's what you'd need:
- a snapshot of the code (eg: git commit SHA)
- a snapshot of the DB schema that correlates to the code (eg: database using linear migrations checked into the code)
- a snapshot of the DB state when upgrades or downgrades take place
- immutable (remove & replace) infrastructure checked into the same git SHA
This requires writing infrastructure, DB schema, and some features a certain way. The problem isn't a technical limitation, it's that you'd have to know a good amount in at least three different domains to set this up, much less run and operate this system. It raises the bar for knowledge well beyond treating each of these systems as isolated systems. That's why most teams don't do it. It's far easier and more realistic for most teams to say" let's fail forward".