Building cool apps >> deploying them in a fancy way.
When starting work on a new Django project, I don't use Docker.
Why would it be otherwise? Nothing has to be deployed. Reproducibility is not a crucial topic. Everybody is on the same page. It will get fancier in time, but only when there are real issues which
require more work.
My development environment is as simple as possible when starting out.
Because there's no real problem it can help me with at that point.
I want as few distractions between me and the main focus of my work as possible.
Yeah, Docker is Cool, But...
That does not mean it's a must have.
Don't get me wrong. When there's a clear job for it, Docker is a tool I cherish very much.
After all, there's so much cool stuff you can get done with it:
- Easily reproducible builds
- Less complex deployment setups
- Automated development environments
- Hassle-free testing environments
- Easy-to-orchestrate workloads (Sometimes. Most people don't really need k8s & co)
But for each of those points, you should have stumbled over the pain you they address first, or should be anticipating it with high certainty. You don't go and build them "just because" when you're working on something which matters.
Just Enough Docker
"It's awesome! Way faster than Vagrant when working locally, and soo cool for deployments."
-- me, ~2014
Docker had me hooked from the first time I heard about it. But it's just one more tool. There's a "playing around for fun and learning" phase in the beginning, but then it calms down and you only use it if there's something you want to achieve with it.
Once everything behaves as expected, I call it a day and move on to more important topics. Stuff that matters. Stuff which created a compelling context to reach for Docker in the first place.
What's Your Goal?
When you are a solo developer, or member of a small team, you want to focus on what's important -- making progress on the actual project you're working on.
If you're the ops-y person in a larger team, your job is to make sure that your teammates are set up for success. You take care of infra stuff, so they don't have to.
Building ever-fancier setups it not that exciting. Enabling people to get stuff done which matters is.
Docker can help you to stop wasting time on distracting issues, and focus on user-facing features.
Every hour you invest into Docker is an hour you could have
used to make your app better. If Docker isn't saving that hour for you or anybody else, you might as well have done something else. Without the upside of saving time & effort in the future, reaching for Docker would not make any sense.
Personally, I will always aim at getting all the infrastructure/development setup issues out of the way and get on with life. To work on stuff that matters.
--
Originally published on vsupalov.com
Top comments (9)
I think that the other comments on this article are missing your point! As developers, more tools tend to lead to more work. It’s easy to fall into the trap that new technologies tend to lure us in with: shiny new toys that “make our lives easier.” Every tool you add to your tool belt also creates new problems to solve and more work to be done, regardless of how great the tool is. Docker is revolutionary in making containerized apps easy to work with - but that doesn’t make it immune to unforeseen complexities. Great post!
Docker adds accidental complexity, true. But the amount of accidental complexity it removes on stages after the writing of code makes the added complexity laughable.
Being a developer is not only pouring code into a repo.
Choosing a technology is a matter of weighing tradeoffs, and sometimes laughable complexity to one person can be enormous complexity to another. If docker works for you under all circumstances, then I hope to one day be as well-versed in its intricacies as you :)
Nothing against using the right amount of Docker or any other helpful tooling. But there's the possibility to have too much of a good thing. Beyond a certain point, the overhead caused by tooling can outweigh the benefits it was intended to bring.
Whew, thanks! Completely agree with you. There's a balance between having too much tooling around your work (and the price it entails eventually), and "avoiding Docker" despite the upsides. Thanks for your comment!
If docker is not saving you time, you're doing it wrong.
Yep, that's certainly a thing that can happen. But there's a sweet spot beyond which it's not saving you time anymore. One can be dockering too far.
Except that your teammate has lost 2 hours setting up all the necessary things to work with the code for later realize half the errors were caused by mismatching Python versions.
After you solved all the development environment problems and then went on merrily on your code, comes the deployment time and then the company (doesn´t matter if it's you or an Ops team) loses lots of hours fixing problems with the code once put on Docker (I have seen things...) and making it ready to deploy it.
In my opinion, avoiding Docker at the initial steps it´s just kicking the can forward just to be hit in the face by it later. Coding inside Docker comes with a change of mindset for most developers I worked with. The mindset changed more to a production state code than "it´s my local code so I will just do this thing and fix it later".
Totally with you on this one. Reproducible environments are amazing! And automation beats documentation, which is a clear win for using Dockerfiles.
My point is not about avoiding Docker, but about investing the right amount of energy at an appropriate time in the project's context.