Git is currently the default choice for source control. We may take that for granted today, but it was not always a clear winner. Mercurial was a serious contender for the DVCS crown, but perhaps the fiercest competition came from the status quo.
Some of the arguments that I am hearing about Docker today remind me of the arguments against Git in 2010 while it was rocketing towards ubiquity.
Arguments like...
- "My team is already invested in tech x..."
- "I don't particularly want my source control to be distributed..."
- "But we hardly ever branch..."
The heart of these arguments is the same:
"It solves a problem that I don't have"
Fair enough. Git and Docker both have a significant learning curve and can be a costly switch. This is not a change you should take lightly.
But maaaaaaaybe...
There are clear benefits to both Git and Docker. Containers are safe, convenient, and consistent for developers and deployments. They eliminate certain classes of problems, and they lower the barrier to innovation. I don't think there is much argument over that. The disagreement is over the value of those benefits.
That is why I am reminded of Git...and Cloud vs. On-Prem...and Java vs. C++ before that.
Point is: Docker may not address your biggest concerns, but it might still be worth it.
What do you think?
Will Docker be requisite for programmers in the same way that Git is today?
Top comments (27)
I think that knowing how to use containers will be a prerequisite for devs, but I'm not sure if it'll be docker.
We don't use (explicitly) use docker where I work - we use Heroku, which handles all of that for us
I think it will depend on the speed cloud providers add managed/serverless services and the quality of those.
If they do it good, most devs won't need vm/container skills.
If they do it bad, vm/containers will be the only viable solution.
ooh, great point!
Depends on what you're doing. If you're a frontend dev, you may be less likely to need Docker to set up a dev environment. If you're writing a GUI app, even less likely that you'd need Docker. But, perhaps when that frontend dev hits
git push, then that kicks off a CI/CD pipeline that at some point uses Docker. Is the frontend dev using Docker? Not really, but Docker is being used.Git, however, can be used and is useful to almost anyone that writes code and wants to store it in some repository. This can include frontend code, or anything else.
I do think containers are becoming more and more important in how we build and deploy software, but Docker isn't the only runtime, and there may be some devs that just wouldn't benefit from Docker, but would benefit from Git or some version control.
I dockerized my front-end apps cause it gives hot reloading functionality -v + the other benefits joe describes
I would think containers for development use are even more vital for the front end dev. I loved being able to spin up a tiny cluster of services locally to run my front end against.
I would agree with Harry. I think the focus on Docker is concerning. Containers are a very useful technology and I believe devs will need to be literate in container concepts and technology in a large way in the future. However I think the commoditisation of these technologies and subsequently the skilled developers is a negative outcome. This is why I believe a diversity of implementations, of all technologies, is important and to be encouraged. So let's see a rainbow of container technologies in the future: Docker, rkt, Dynos, etc.
I agree with you, Docker has done a great job of marketing so I think a lot of devs (myself included) conflate the concepts.
I think it's similar to Git in that way as well, a lot of newer developers conflate Git and source control - not realizing that there are other options that might suit them better.
Great post, Joe! I'm no Docker expert, but it's so helpful in the right scenarios! The other day I was following a lengthy list of instructions for setting up some open source software on my machine. NOT something I wanted to spend my Saturday on. Luckily for me, someone had already Dockerised it for me. :]
That was the real eye opener for me. I've setup search engines before...getting the right version of Java, and Tomcat, getting my environment variables set for the current thing I'm working on (which meant UNsetting them for other projects I had worked on), then finally configuring the service.
I just did the same thing other day, but I was able to spin up ElasticSearch and Kibana in minutes. Docker even took care of the downloading :)
I think this is an overlooked but really important point. Containers are not just about the deployment enjoyment. You don't need to install MySQL/MongoDB/Tomcat/nginx/etc locally anymore to do work, just spin up a container.
Want to try that new CMS? Spin up a container. When you're done your machine isn't polluted with a bunch of files, environment variables, or modified path. Every dev should know how to do this.
Can you give an example ? I never thought about using Docker like Git, well I just started to learn about Docker anyway
At our company, we code in javascript and deploy with svn and run it with pm2, we copy production code to svn and then on the server pull from svn and restart pm2 process. How this will work if I use docker to deploy
Thanks
I don't think that Docker will replace Git - I just think that one day Docker might be as common as git: Something that developers are expected to be familiar with.
In your case you could use docker to "container-ize" your code, so you deploy the container instead of the source code. The benefit is that the container can also hold everything your code depends on - specific versions of JavaScript for example.
Additionally, docker can make things easier and more consistent for developers too. For example, you could create a Dockerfile for your dev environment that bundles up your build dependencies - so things like NodeJs, Bower, WebPack, etc.
I don't know if Docker would make your life easier or harder, but it might be worth a look just in case :)
You can set up a ci/cd system (like what gitlab is offering) to have this flow:
Whenever a new commit came into mater branch, update the production docker image
Then have gitlab (or your automated deployment system) update images in your swarm
Do you mean that docker can replace git, or 'will docker become a necessity for development as git is today'?
More the latter. I'm wondering if developers will soon need to have a basic competency in Docker (and I say Docker rather than "Containers", because of it's popularity and command line tools).
Kinda like Git - most programmers just need to know the basics to do their job: add, commit, push, pull - so long as there is somebody on the team that knows how to get them out of trouble. Maybe x years from now Docker will be the same, all devs will be expected to know the basics: build, run, stop, docker-compose-up.
It's tough to predict the future, but I think that it's worthwhile to get familiar with it just in case :)
One might even say it's worthwhile to git familiar with it :)
ba dum cha!
I think he means the second one
Yes! it is!
Git is so essential for a coder, and Docker is getting more and more essential for a developer!
Git and docker are so cheap to learn, and so easy to use.
If a coder's resume don't have git & docker in the skills list, I don't think that he/she will good at the job.
I think that containers present an interesting problem for devs who have only ever worked in Windows. Whilst there's nothing wrong with that at all (use the tool which enables you to do the work in the best way), there's a clear mindset change required for containers.
Having to change from a non-Unix like operating system paradigm to a Unix technology (containers have been around since the 70s, so they're hardly new) requires a slight change to how devs approach their work. Sure, there are Windows based containers, but the majority of "DevOps Professionals" (tm) will be using the Linux variety. Which can (and does - ask me how I know) cause issues when Devs who haven't experienced OSs other than Windows are forced to think about their applications running in containers.
As others have said, the push for serverless and functions (which can use containerisation) will help folks to get over that hump.
I'm not sure that containerisation will be a Dev specific skill but I think it has become a DevOps specific skill, and that we'll all be pushed towards DevOps in the near future (if not already).
[As a side note: some of the big names in the DevOps industry have "moved on" to DevSecOps. They're also saying that it's a natural evolution to start including other things, like DevSecAdminOps. I'd check out the DevSecOpsDays podcast for more information on where the industry is heading]
Totally, for a simpler healthier lifecycle and faster and safer deploys you need docker!
I'd argue that it's not necessarly Docker (because with a "runtime" like OpenShift's templates it's pretty much auto-generates) - but Kubernetes sure is. Write your App, click "AutoDevOps" in GitLab - there you go, dependecy scanning, CI/CD and deployment to k8s. Kubernetes provides an equal playing field for every cloud provider, and it's "infrastructure as code" - perfection IMHO.
Also, typing
helm install mediawikihas got something on it's own ;)You're definitely onto something here. Even if it doesn't make sense organizationally to transition to containerized services in production, injecting Docker into the average developer's workflow can save a significant amount of time in the long-run. The key here is demonstrating the flexibility and power of what Docker can offer as a generic development tool. You don't need to containerize your critical applications right out of the gate. I imagine the fear of transitioning to using Docker from a technical-business perspective is derived from the misguided assumption that it'll inevitably come at an exorbitant cost. The conversations probably involve things like, "Now we have to change everything downstream from this decision. We have to change how our applications are managed, deployed, and monitored. We have to account for staff retraining, etc." Essentially, there's no adoption moderation. Instead of embarking on a massive technical overhaul, you can use Docker primarily to onboard new developers by containerizing a basic development environment or kick around small proof of concept ideas for internal projects. I'd bet that even as serverless technologies continue to gain popularity, having a foundation in working with containerization tools will become a standard part of the dev skillset.
I think there are some really powerful benefits, such as portability. You can mirror your production env with all the services you need in containers, without any of the strings attached. Since nothing is polluted to your physical machine, it stays lean. The ability to package code and share it with coworkers is extremely useful since you can ensure you're all running precisely the same setup, avoiding lots of compatibility problems.
Security scanning is coming very soon, not just scanning the dependencies of your code but going more in-depth with the OS it's running in, any other services you rely on (think DBs, caches, web servers etc), and tracking security issues upstream. GitHub has started doing this for Ruby and JS, I think Docker can do this for containers, NPM is now doing it for packages, it just all needs tying together. This is something I'm really excited to see more of in the future - end-to-end security scanning. Right from down at the kernel up to your application layer.
I also find it really useful for testing apps against different versions of services and dependencies - just update what you need to, run your test suite and see if it works. Considering upgrading something? Upgrade, run tests, evaluate time needed to fix. Of course, that relies on a comprehensive test suite, but then again, you should already have that 😉
Docker has this certain flow I don't think I will know How to explain, for the future of dev docker is the real deal
DockerHub the new GitHub