[KronisLV]

> Make sure production environment differs from developer environments in as many ways as possible.

I feel like this, in some capacity, is borderline inevitable in the modern architectures with a bunch of external services, or at the very least will 100% require that your devs are connected to the Internet all the time to be able to do anything, vs systems that are 100% self hostable.

Or even just running a complex Kubernetes cluster with a service mesh and other solutions on the test/staging/prod infra vs loosely mapping to more lightweight options locally, unless you have a super beefy setup. And even then, if everything is split into multiple separate services far enough, you just won't be able to run everything locally, meaning that you need to use some of the components from shared dev environments which will inevitably lead to stepping on each other's heels.

Once you go past something like Docker Compose for local environments, things can go sour.

[Spivak]

The way I think about this without going insane isn't "developer environment must be exactly the same as production environment" because like you said, you'll never do it — there's too many things you can't replicate locally.

So I flip it around — production should work exactly like the development environments. If there's a a difference between the two that matters we update production to match. You want to talk to other services by a well-known container name instead of an env var we pass? Sure, whatever we can do that.

[hinkley]

I used nginx as a forward proxy a couple times before Docker was a thing. Poor man’s service mesh still has some utility.

[teddyh]

Im some ways, this is an unsolvable problem, due to entropy. You can’t even step into the same river twice.