It depends.

In certain stacks that can be relatively "self-contained", like Java, where you just need a version of JDK, it can be easier to just install it on the system and run/debug/develop your application locally, even if you can deliver it inside of containers. Why? Because remote debugging can be a bit of a bother to setup (in any stack) and sometimes the IDE integration works better without containers, provided that you actually embrace coupling your development process to the IDE.

In other stacks that would be more complicated to setup, like PHP, it can be better to run even your local environment inside of a container, bind mounting any of the files that you need into it and working that way. If done correctly (e.g. you don't suffer too much because of file permissions, should your host OS use NTFS), it can be similarly easy to the Java example, though remote debugging setup will be a must.

As for other complicated pieces of software, like databases (MySQL/MariaDB, PostgreSQL and so on) or object storage (MinIO/Zenko, or another solution that's similar to S3), key-value stores (for example, Redis or memcached and so on), it's almost always going to be better to run them in containers.

It's not so cut and dry, though, because all of the software that you don't need to develop/debug but just need running locally can also run in containers with no issues. The problems start when you try doing something fancy - like wanting to run the applications you're developing locally with Skaffold and rebuilding them on code changes, which in practice will be slower and more resource intensive than doing that natively on the system.

Of course, what's true for me and my projects, might not be true for someone else.

Great summary. I would add that a common pattern I end up following, mostly working on JVM apps, is to run the app itself locally but run its dependencies in containers.

> people are using them for their dev environments [?]

Yes, we use a container for dev environment so that we can share the same env across all the team. If it's decided that we need 1 more tool in our toolbox, the script that generates the container is updated (the script is version controlled in the repo too), the CI/CD generates a new container version, all the devs can now use the same NEW environment.

We actually use the container as image for (remote) virtual machines, so we don't really compose multiple containers.

The container has all the tools (for several languages) that we use as a team.

IDEs and debuggers can connect through ssh.

> post-development workflow do you ever use separate containers for build and test?

We build different flavors of the final packaged application, for example:

- production flavor: uses a minimal, nonroot container base image (see: https://github.com/GoogleContainerTools/distroless)

- debug flavor: includes few extra debug tools inside the container

Docker is very convenient when it comes to maintaining uniformity across different developers machines. Once the boilerplate is done, 'docker compose' will stand up complex projects in a matter of minutes (depending in machine/internet speeds). Every startup that I have worked at uses docker and, honestly, I would question why one wouldn't want to use it.

Most of my work has involved rails or golang. Live debugging of go isn't really a thing. Rails on the other hand is usually done via a gem where you manually type in breakpoints and go from there. Regardless, it all works in containers.

Keep in mind that depending on your OS and docker setup, you can just have your container read files from your local filesystem. So edits are immediately reflected in your container and you don't need to build a new one when making changes. It is pretty flexible.

What do you mean live debugging isn't a thing? Delve integration into Goland makes setting breakpoints and analyzing variables great.

Of course it's nothing like Python where you can stop execution and start manipulating variables...

Certainly delve exists and I'm sure it is fantastic, but it just isn't something I have ever needed to reach for when developing with go.

A trend is to move towards using containers to replicate most of your production environment in your dev environment.

This has a bunch of purported benefits (you maintain one way to run your app, you test all the deps while developing), but note that it's never exactly the same setup.

It also has a bunch of issues like performance (in a large team, images change often, which means redownloading image layers or entire images; starting up containers adds an overhead too, especially noticable with running unit tests), flexibility (unless you run a full cluster locally, it's usually harder to work on multiple branches of your software at the same time since containers would be configured to use the same internet ports) and complexity.

I think an ideal would be containers for local dev work without tying them to production images so they can be optimized for different goal, but I've never seen that. The big issue there is that Dockerfiles are not composable (ie you can't have a install-deps sub Dockerfile that follows the caching semantics).

At work I use whatever my team uses. For personal/side projects I tend to use either a VM or a Docker container for dev purposes. The main reasons are:

- a bit more of security. If I download a third-party dependency and it turns out that it executes `rm -rf /` in the background, well, only my container will result destroyed and not my personal machine. For serious malware, well, I guess it doesn't matter if I use containers (but I'm less concerned about this because being that paranoid would make my side projects feel like work)

- all the tooling gets installed in the VM/container, so my personal machine doesn't get polluted with gdb, pdb, compilers, linters, modules, packages, etc.

- I have a Mac, so I usually work on Linux VMs/containers

Just use it if you find the need and it's the right tool for the job at hand.

As a tester I use containers for setting up clean test environments, when writing code I use it to get the latest and greatest dev environment from a common depot and on CI platforms it is useful to get all the tools and environment you need setup for you.

It works for every language, some are easier to set up than others though, I never got a debugger to work in a container but never had the need to.

It's best to use the same image for dev test and prod, but not the same running container.

> dev environments or if they're developing on their host

It's usable for both. Some people go one way some the other. It definitely makes developing in a container on a mac easier if you don't have to worry about compatibility with the target environment.

> If you use a container for only your post-development workflow do you ever use separate containers for build and test vs the final packaged application?

Yes, most of the time, mostly because the tests require extra dependencies which are not needed in prod.

Thanks for the info. Using different containers for build and test vs the packaged app makes a lot of sense.

> easier if you don't have to worry about compatibility with the target environment.

I develop on Windows and deploy onto Windows right now, and as we get everything onto .Net Core (and maybe eventually) Linux I'm thinking the same thing. If I can build/test/run my app and service on the same target OS it can only make life better.

Any good guides for this or am I overthinking it and anything on containers will work?

I've often been behind a slow internet connection for which downloading container images can add hours of waiting to my day so I "just say no".

I tried it for a toy project in Python and Jetbrains Pycharm supported python installation (completion, navigation of libraries) within container perfectly. Then I moved to VS Code, installed a few extensions but it didnt work at all.

A whole virtualmachine and I can make snapshots and transfer it to another machine!