Yes, it’s simple at the beginning but it takes a lot of effort to move to non-port based solution for anything.
Cuts are small at the beginning (oh, this service should use other PostgreSQL, so lets have two - oh but I my code doesn’t specify port in an config file, so let me put on direnv - oops IDE didn’t pick up env file) but they grow quickly.
Containers are standard nowadays and allow going for Kubernetes if one wants. With solutions like Justfile or Taskfile its reasonably ergonomic.
It’s a problem future me will always, happily solve.
If my system is large enough and complex enough, it _likely_ means the business behind it is successful. I will always solve “dumb problems from past me” for a successful business than the alternative of not having a business.
I agree to the principle in general, but non-reproduceble execution environment with free-for-all internet access is unimaginable time sink.
Business tends to topple on unreliable promises or annoying customers through the bad tech and I’ve seen a few that are gone because of it.
Unicorns won’t fall on such problems but semi-good Average Joe’s product might. No one is going to hear about it even if such products make bulk of software in global code volume.
Containers (on low technical level) are simple, performant and scale well.
Depends on which type of scale you are running. And it's not worth overengineering a project for a scale you hope to achieve some day. It will take away engineering resources from building something that provides value today
Yes, it’s simple at the beginning but it takes a lot of effort to move to non-port based solution for anything.
Cuts are small at the beginning (oh, this service should use other PostgreSQL, so lets have two - oh but I my code doesn’t specify port in an config file, so let me put on direnv - oops IDE didn’t pick up env file) but they grow quickly.
Containers are standard nowadays and allow going for Kubernetes if one wants. With solutions like Justfile or Taskfile its reasonably ergonomic.