As a developer, do you even bother with containerisation?

Nice question! For me it depends a bit on the project:

Working on a project together with other people and using external software/services (ex. databases), it can be a lot easier to set up your development environment. Make sure you run the same version and configuration. This makes collaboration easier and eliminates bugs/discussions/weirdstuff due to differences outside your code. A little bonus, it's easier to wipe and strart fresh.

For personal projects I also tend to use it when having a lot of external services/tools as well. You do not want to install everything globally, especially when tools have no or poor version management. You might need different versions of a CLI or piece of software for different projects. In that case I also like to use containers.

In case of a small project where I just need a database, I pull in a container without containerizing the project itself. Just because it is easier to set up the database. A bonus, it's nice and clean to use a database per project. I just mount the data volume inside the project directory and throw it in gitignore to keep everything together.

When I work on a small project myself, I won't. The pro's do not outweigh the effort.

So I always check if I have components or challenges in my project that need containers to solve the problem. If I don't, I won't.

In the projects I work on, Java for the backend and JS for the frontend, we use containers for the side services (database, mailhog, etc.), driven by Docker Compose. This requires everyone to have the correct JDK installed (these days, either JDK 8 or 11, soon we'll probably add 17; on Linux it's easy to install JDKs side-by-side and switch between them) and the latest version of Node (either LTS or current; though we build with LTS for prod), which is generally the case.

Some of those projects are packaged as containers too for deployment, and that's our team's job to maintain the Dockerfile.

On a couple of legacy projects, we're still using old versions of Node, so we're using containers locally (rather than forcing everyone to use NVM.

Some other teams at work, using PHP on the backend, also use containers for running their code in development (code is bind-mounted into the container), as that allows them to use different versions of PHP, Apache (or Nginx), and Composer for each project.

On our build servers (Jenkins), everything is built inside containers so we don't have to install anything specific on the machines.

Hi Anthony, using container for development is pretty common nowadays, following are the reasons that come to mind right now (imo and experience):

• Stable and predictable dev environments
  This is especially good if you have a large team, every large team I've worked with I've either used docker or introduced docker to the team

• Developing as close to prod env as possible

• Troubleshooting, debugging production issues

docker-compose is pretty standard in using docker for development but tooks like kind, skaffold are also there if you want to develop like prod kubernetes environment. Buildpacks are also really great, and require no dockerfiles!

I'm also writing a series on using docker for both dev and prod here

Yes, it's clearly one of the duties of the developers to build* a container, because they know their application the best, like the dependencies and how to scale the application. And in the end a container is a perfectly standardized delivery object for the ops guys.

(*) = The actual build of the container in the target environment is of course the job of the CI/CD pipeline. The developer's job here is to deliver a Dockerfile or whatever is required to build the container image.

However, I don't use a container for the code I'm working on during development. I'm not sure if auto-reloading, debugging, module installation, etc. can work in containers as well as outside containers at all, and it seems like it requires a lot of preparation in my development environment anyhow. So far I haven't seen the benefits of it and that's why I still develop my code outside of containers. But of course I install dependencies like Redis, MariaDB, messaging tools, etc. as containers.

With the tech stack I typically work with, Typescript/Node, I rely on things like PM2 to bring up multiple instances of a project's server with environment variables to dictate which services are going to be used, so I can keep an entire distributed microservice ecosystem in the same project. You get all the portability without needing to separate the codebase. Now as the project gets bigger, it does make more sense to dockerize it and deploy them into space, but until you get that far, containers should not be the first thing you think about.

Containerization should be an after thought, but making sure your code can run in a container is the bare minimum you should do to make sure you aren't coding yourself into a corner.

Early deployments to AWS/Heroku/Vercel/Firebase or whatnot can give you the added benefit of knowing how it will behave in production, but it shouldn't be the driving force behind how you code.

Typically generating the container is specified by DevOps, SysAdmin, etc type people in the organization, so having the engineers worry about it creates unnecessary labor on our side of the workflow. CI/CD should alleviate this so you don't really think about containerization and it makes the workflow even that much simpler.

I usually do not like installing alot of tools on my system. Setting up a Dockerfile with everything basic you need for development is faily easy and you can reuse it with little adjustments. Since it's sandboxed you can also play around with things without to worry about leftovers.

It depends for me, I start developing simple apps, then if the stack grows, I don’t immediately containerize, but I know it is a future task that if done could help me get up and running quickly in the future or if I would share what I’ve been working on, is easier for the people to setup the environment with the app containerized than installing all the necessary dependencies one by one

I like early containerization if I know I will need to scale the project.
On top of docker and docker-compose I use portainer locally. It's basically a GUI for managing docker and works really nicely.

Dockerfile + docker_compose is very useful.
It replaced the vagrant that we used back in the days

Yew