The docker setup is just one part of it. There are sometimes extra considerations - let's call them environmental factors - that can begin to increasingly build complexity until it becomes a significant source of problems. You can try to avoid them, ignore them, or make your own solution. But once you face them all, and measure how much productivity and reliability is lost dealing with them, suddenly Devcontainers makes sense.
First environmental category: your dev environment itself.
What platform are you using? What architecture are you using? Do you need a VM? How will you mount filesystems? How will you handle networking - through the VM or on the native host? How will you handle HTTPS proxies - on the docker client, on the docker server, in the VM? Do you need a custom DNS resolver? Do you need additional applications for your platform, like AWS or GCP CLI tools and credentials? Do you need more applications, some of which may have specific version requirements (for example, Homebrew famously does not support old versions of software)?
Second environmental category: CI/CD.
How should I do a build, test, and deploy from my laptop? How should I do a build, test, and deploy from a CI/CD server? How can I make sure I get the same result from either? How can I reduce the number of dependencies in the deployed form, without getting different results at runtime? How can I re-use things from my local machine in the CI/CD so that I don't have to maintain two different ways of doing the same thing?
- In the best case: you have no problems at all, and everything works automatically.
- In the worst case: one of a hundred different things can break your dev environment. You end up spending an inordinate amount of time just "maintaining your dev environment", rather than writing application code. And the more developers there are, the higher the probability of time is spent on "environment work" rather than "making the product".
- Besides all of that dev environment work, you end up replicating your whole process in a completely different CI/CD system, and now you're maintaining two separate yet identical things.
A solution to all of these environmental factors combined is Devcontainers: https://containers.dev/overview Because it's one standard, all sorts of tools can now take advantage of it. This means different devs can use different tools to solve the same problem with the same config file.
First environmental category: your dev environment itself.
What platform are you using? What architecture are you using? Do you need a VM? How will you mount filesystems? How will you handle networking - through the VM or on the native host? How will you handle HTTPS proxies - on the docker client, on the docker server, in the VM? Do you need a custom DNS resolver? Do you need additional applications for your platform, like AWS or GCP CLI tools and credentials? Do you need more applications, some of which may have specific version requirements (for example, Homebrew famously does not support old versions of software)?
Second environmental category: CI/CD.
How should I do a build, test, and deploy from my laptop? How should I do a build, test, and deploy from a CI/CD server? How can I make sure I get the same result from either? How can I reduce the number of dependencies in the deployed form, without getting different results at runtime? How can I re-use things from my local machine in the CI/CD so that I don't have to maintain two different ways of doing the same thing?
- In the best case: you have no problems at all, and everything works automatically.
- In the worst case: one of a hundred different things can break your dev environment. You end up spending an inordinate amount of time just "maintaining your dev environment", rather than writing application code. And the more developers there are, the higher the probability of time is spent on "environment work" rather than "making the product".
- Besides all of that dev environment work, you end up replicating your whole process in a completely different CI/CD system, and now you're maintaining two separate yet identical things.
A solution to all of these environmental factors combined is Devcontainers: https://containers.dev/overview Because it's one standard, all sorts of tools can now take advantage of it. This means different devs can use different tools to solve the same problem with the same config file.