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.

>>choege+EF1
In theory it should be the cloud providers themselves maintaining the locally-runnable stand-ins for their services, but as it stands you basically either get it as a third party effort (MinIO for S3) or in cases where the service is just a hosted version of some existing OSS product (Postgres for RDS).

Either way, once the local version exists, then the job becomes maintaining all the infrastructure that lets you bring up the pieces, populate them with reasonable state and wire them into whatever the bits are that are being actively hacked-on.