TLDR; Docker is fantastic for development in small teams.
I became interested in Docker at PyCon 2014 after listening to a great introductory talk by @amjithr.
Back then I was part of a 3-man team working on the development of niche analytical software. Not having a dedicated team of DevOps personnel, we stored Docker in our “We’re not big enough for this yet” box alongside Chef and various other fancy tools.
In 2018, there appears to be a common misunderstanding when it comes to containerization: you need to be developing at scale to get into it. This is no longer the case.
Sure, you get benefits such as auto-scaling and fine-tuned orchestration by using Kubernetes and containers in production but is scaling really the problem you are facing right now?
Maybe containerization can solve problems you have even before your app hits the production-ready stages.
At Osedea, we code and maintain dozens of client projects.
Rolling out custom solutions for the larger projects (6 months +) is no issue, spending X days messing around with config files will not affect the bottom line and that 1–3% development speed gain will be worth it in the long run.
However, when you only have 4 weeks to develop a solution for a client with a limited budget, those X days can make the difference between hitting the deadline and missing it.
We established a few requirements when developing prototypes/small-scale projects:
- Development environment must be the same for every developer
- Setup time for small projects (1–3 months) must be minimal
- Consistency across small projects to reduce learning curve
We managed to overcome those using Docker and Docker Compose. We mainly use 2 open-source projects as boilerplates for our development environments: LaraDock and NoDock.
LaraDock
I personally started using Docker in 2016 after my Vagrant controlled Virtual Machine halted my PHP development for an entire day for the nth time.
Luckily for me, Docker Compose was out by then and made switching from a VM to Docker painless. The rest of our teams were quick to follow.
@MahmoudZalt’s LaraDock was the first major open-source Docker Compose project to provide a batteries-included development environment that went beyond “_we stuck everything into one container, hopefully that’ll work”; it gave each of my services their own container, and networked all of them seamlessly.
This was also the first large open-source project I became a core contributor on.
LaraDock has grown to having over 5000 stars,1500 forks and 180 contributors on github. I highly recommend it to any developer working with PHP.
NoDock
We found ourselves developing more and more Node backends and we had a desire to get started with blazing speed.
Our own NoDock, a Docker Compose environment for Node projects, came alive in late 2016, we began using it for client projects early 2017.
NoDock is made to be extensible, most of our projects start out with the default configuration then slowly hack/modify it to grow with the application. It currently sits at over 400 stars and 60 forks.
One of the biggest advantages of NoDock is the ease of managing multiple versions of Node across multiple repositories. We sometimes have 2–3 repositories configured in the same Docker Compose project to emulate our production environment and have the new developer run the project locally will take 15–30 minutes tops, including the image downloads.
. . .
Where the last few years saw most of the large tech companies move towards containerization and container-first approaches, 2018 will hopefully see even the one-man teams catching up and by the turn of the decade, running a VM for development will be distant memory.
Photo credit: Kevin Ku
