Zooming out, the infra trend I see is gaining flexibility and optionality by decoupling constraints. This lets us efficiently navigate the solution space.

Storage / Compute separation.
Infrastructure via API.
Serverless.
Service meshes.
Workload orchestration.

Innovation by challenging assumptions

https://hachyderm.io/@hazelweakly/113601483324077529

Hazel Weakly (@[email protected])

I'd love to see the infrastructure industry move towards a future where the concept of a runtime, its interface, its associated isolation level, and the packaging, are all disaggregated Containers != ephemeral. VMs != stateful. Containers != CRI.

Hachyderm.io

On the application side, decoupling hasn't happened. Not in the same way, imo.

Micro-frontends, island architecture, cell-based architecture, microservices, event sourcing.

I can't call them innovative in the same way that IaC or k8s were. Excellent? Absolutely. But did we gain optionality? Sorta?

The reason I'm bullish on further decoupling application packaging, runtime, isolation, execution, and other components, is because it's the first step towards building infra that enables true decoupling for software.

We've been building infra for infra, but now we need to build infra for everyone.

Here's my wishlist of infrastructure enablement for applications:

1/
Write once, compile to: IPC, RPC, FFI, native libraries.

I'm tired of writing the same "reusable" code in 20 different ways. If it's reusable, why can't I reuse it?

How many times do we have to re-implement config parsing? C'mon

2/
State propagation via: Event sourcing, DBMS, CDC, in memory, ...

Why does choosing an option change the entire architecture of the system, and involve rewriting your codebase?

ReactJS is 95% event sourcing, but somehow redux -> event sourcing is a full rewrite? Would love to see progress here.

@hazelweakly I think the answer to a lot of these is “leaky abstractions”, but none more so than this. But in this case, because people take advantage of it - event sourcing forces you down a hydrate-validate-notify cycle. And if we wrote all of our applications like that, it wouldn’t matter what persistence underlies it. But if you _know_ you’ve got a DBMS, then the temptation to directly mutate a column for performance is enormous. And then that changes every code path that touches it.