How Do You Handle the ‘Container Tax’ in Your Development Workflows?

I think the author of that article might be a bit new to containers. I'm not quite worried about the overhead; containers are transparent, so you know what’s happening inside. When things do break, you have good documentation in the container world to help you troubleshoot, as long as you keep it updated.

While I argue that developing directly inside containers does have its challenges, especially regarding visibility and configuration conflicts, I generally feel the benefits outweigh the drawbacks. It streamlines deployment and helps direct our focus on code that runs consistently across different environments.

From my perspective, using standardized environments for running and testing actually helps a lot. Artifact management becomes simpler, plus there's a huge ecosystem of tools available. I don't really see the container tax as a problem, to be honest.

Developing locally with tools like Telepresence or Docker Compose, while testing in a near-production Kubernetes cluster has worked well for us. For syncing dev tooling versions, we use Devbox, which handles it like a pro. It's even useful for CI/CD builds!

I’m not sold on the concept of a container tax. I manage a local cluster, write my own helm charts, and deploy locally without any major issues. It seems manageable if you define your builds properly.