How to Convince Your Boss or Manager to Use Docker
As developers and sysadmins, we know the wins of using Docker, but how do you explain the benefits of using Docker to business people?
Quick Jump: Managing Multiple Projects on Your Dev Box | Getting New Developers Up to Speed | Unexpected Issues Are Appearing in QA / Production
I’m a big fan of learning by example, so rather than spew out tips like “you need to pivot your marketing proposal from developer satisfaction to quantifiable business metrics” I’m just going to list out a few common development / ops problems and then list how Docker solves them for both crowds.
This way you have a set script you can use for a bunch of different Docker problems, and you can choose which solutions to use based on how technical your boss or manager is and what applies to you. Feel free to make your own tweaks!
Also, it’s worth mentioning that these can be re-purposed for half a dozen use cases with minor changes, which is why I didn’t list out every possible problem / solution.
Managing Multiple Projects on Your Dev Box
Technical problem:
It’s really painful to manage multiple projects on my development machine because tools like rvm, virtualenv, nvm and phpbrew are confusing to use and they are causing lots of trouble, especially when I need to upgrade language versions and dependencies in different projects.
This can be re-purposed as a “setting up a development environment sucks” problem.
Technical solution:
With Docker, you can throw those tools away. Docker packages up your applications into a self contained “Docker image”. You can have an image for each of your apps, and it won’t matter if each app uses a different language version. It’s a 1 line change to upgrade or change versions.
Business solution / script:
In order to add that new feature you want, we really need to upgrade a component of our application but doing so is going to sidetrack things for a few days in development. I also need to set aside time to hold a meeting with QA and the ops team to communicate on what will need to change on the live servers. This may end up taking weeks in the best case scenario.
But, if I can be honest with you I discovered something great during lunch today. I was researching something that could drastically reduce the time it takes to create new features and upgrades. We’re talking at a scale of 2 days instead of 2 weeks for some new features.
It will take us about 2 weeks up front to learn the technology but we’ll be able to reap the rewards immediately after that. This technology is called Docker and some of the biggest internet companies in the world are using it to run mission critical components of their sites.
Getting New Developers Up to Speed
Technical problem:
Trying to on-board a new developer to the project takes an unreasonable amount of time and it involves multiple people having to troubleshoot multiple issues every single time. Not only that but we’re struggling to keep the documentation up to date. No one wants to touch the 18 page installation guide with a 100 foot pole.
This can be re-purposed as a “it works for me!” problem.
Technical solution:
Once you “get” Docker, you’ll see how to run and manage your whole project using a simple tool. New developers just need to run one command and relax because that command will build and start even the most complex apps on its own. The initial set up time is minimal too.
Business solution / script:
We’ve analyzed and determined that it takes on average 16 hours for a new developer just to get in a position to be able to run the site on their computer. It also takes 3 hours of time away from John and Jane to help troubleshoot issues that’s not covered in our installation docs.
With just a small time investment up front I strongly believe we can get on-boarding time down from a few full time days to under 30 minutes. I know it sounds almost too good to be true, but there’s no catch. Can you give us the OK to learn this technology? It’s called Docker. They are a well funded company who have been around for half a decade.
We can try it out in development first before committing to it, so it won’t be anything that affects the live site. We can be ready to on-board the next new recruit with it if we start soon.
Unexpected Issues Are Appearing in QA / Production
Technical problem:
When it comes to deploying code, all sorts of platform specific issues and application level bugs are popping up. Since the process of setting up the application is so much different between development and production, there’s a million ways for things to go wrong. Subtle version differences between system packages and processes are the root cause.
This can be re-purposed as a “deploying is hard” problem.
Technical solution:
Since Docker lets you easily build and distribute your applications, you can move fully working packages across environments. That means code that was running in development is the same exact code that winds up running in production.
It doesn’t matter if it was developed under MacOS, Windows or Linux. It will run the same on any OS (even a different distribution of Linux on your server).
Business solution / script:
We’re growing fast but our marketing team is saying they’ve witnessed a large number of our users tweeting out bad reviews about our product, and it’s related to the reliability of our site. It keeps going down for maintenance and users are experiencing bugs all over the place.
I truly believe that if we don’t do something to fix this soon, we’re going to lose traction and be labeled as incompetent.
In last Monday’s meeting, Jamie from the operations team mentioned they could drastically cut down on maintenance and bugs by adopting a technology that has been gaining steam over the last few years. A number of our competitors are using it already. With a time commitment of a few hours a day we can transition to using it within a few weeks.
Can we move forward with this? We’ll start small and see how it goes.
What lines do you like to use to convince people to use a technology at your company?