Docker is omnipresent in the tech world today. If you are a solo developer or your team is currently using a PaaS like Heroku, you may be wondering what problem Docker solves and if it is worth adopting.
As with all technology decisions, you need to evaluate if Docker is worth your time. (Spoiler: if you are happy with your current Heroku setup, you probably don't need to switch.)
The main benefit of Docker images is build once; run anywhere.
What this means is the following:
Run anywhere you can install Docker
If you need to run your application somewhere, e.g., for demoing a client, you can easily do that if that environment has Docker installed. Pull the image and run with it with the correct environment. Also, if you choose to use Docker also during development, onboarding new team members takes less time because they need to install Docker.
Not dependent on Stacks of your PaaS provider
You are not dependent on the "Stacks" of PaaS offerings. Heroku, for example, retires their stacks from time to time. Your only way to find out if your app runs with the new PaaS stack is to deploy it and see if it works.
With Docker, you have everything packed into your container and can decide for yourself if and when you upgrade.
Testing a version upgrade also becomes as easy as changing the version number of your base image in your Dockerfile.
You can easily switch your hosting company
You may want to change your hosting environment (PaaS) for a project because it becomes too expensive, e.g., due to scaling because of a heavy workload or because you retire that project, but it still needs to be available.
With Docker, you can quickly move to another hosting provider and be sure that your app will run if they support Docker.
Run the same image in CI/CD and production
If you are currently testing your code in a CI pipeline, you probably have your build or runtime versions like for Node.js defined in your CI configuration.
When you test in your CI pipeline, you usually need to set version numbers for your runtime or build dependencies in the CI config, too, like the Node.js version number.
With Docker, you only need to define how to get your service started once in the Dockerfile, and you can then build your Docker image in CI, run tests on that and publish the same docker image to production.
Less infrastructure setup if you deploy on VMs or bare metal
If you did manage bare-metal servers before, Docker can simplify your setup, as you don't need to manage runtime dependencies and tools like Node.js on your production server. You only maintain and upgrade the docker runtime. (Although I would always advise against running your own infrastructure unless you know what you are doing.)
Conclusion
Docker can help you reduce "it works on my machine" errors, not only with colleagues but also with CI/CD and production. If you are satisfied with your setup and don't see much benefit in the points stated above, you don't need to change.
Are you using Node.js with Docker? Check out these 7 best practices!
Top comments (0)