zlacker

>>borisj+(OP)
I think the author has a point with one-way doors slowing down the adoption of distributed systems. The best way to build two way doors is to push for industry adoption of a particular API. In theory the backend of these APIs matter little to me, the developer, so long as they are fast and consistent. Some examples that come to mind is that Apache Beam is a "programming model" for Data pipelines, Akka is a "programming model" for stateful distributed systems, OpenTelemetry for logging/telemetry, and Kubernetes for orchestration. Oh, and local development is a strong preference.

>>awkii+r5
It boggles my mind that people accept architectures where the only dev story is a duplicate cloud instance of the required services.

Being able to bring the whole application up locally should be an absolute non-negotiable.

>>mikepu+Ta
> Being able to bring the whole application up locally should be an absolute non-negotiable.

This usually doesn't work that well for larger systems with services split between multiple teams. And it's not typically the RAM/CPU limitations that are the problem, but the amount of configuration that needs to be customized (and, in some cases, data).

Sooner or later, you just start testing with the other teams' production/staging environments rather than deal with local incompatibilities.

>>cybera+We
> Sooner or later, you just start testing with the other teams' production/staging environments rather than deal with local incompatibilities.

That's probably about the time when your development pace goes downhill.

I think it's an interesting idea to consider: If some team interfaces with something outside of its control, they need to have a mock of it. That policy increases the development effort by at least a factor of two (you always have to create the mock alongside the thing), but it's just a linear increase.