Release early, release often. And listen to your customers. This famous philosophy (abbreviated RERO) by Eric Raymond is now the de-facto product planning strategy of web application developers. It enables developers to quickly react to customer needs, and shape their application based on customer feedback.

The RERO approach required web application creators to look at where they lose time. Development takes the biggest chunk of time, followed by QA and then by deployment. Rapid application development methodologies like Agile and Lean development reduced the time for development. In recent years, automated testing, continuous integration and continuous deployment have made deep in-roads into reducing time for QA and deployment.

Even as I write this, companies are innovating on how to make their app deployments even faster. The latest trend-setter on board is Docker. Docker helps web application creators cut down time in configuration management and deployment.

Is your web application deployment fast enough?

Time for a reality check. How much time do you spend on application deployment? If your answer is anything above 10 minutes, you have an opportunity for improvement. Whether you use an automated tool for continuous integration/delivery or use your trusty Bash script, there are ways in which you can limit your deployment time to a few minutes.

Before we look at how exactly we can save time, let’s see the top ways in which app developers lose time during deployment:

1. Resolving application dependencies – The most common deployment issue where you absolutely need that function in version 3.9.1 to make it work just right. And yes, to get 3.9.1 of XYZ, you’ll need 7.3-rc1 of ABC and 4.1.3 of JKL, which may have their own other dependencies. Good luck doing that in 5 production servers with slightly different OS versions.
2. Resolving software conflicts – The not too un-common issue in servers hosting multiple web applications. Web application ABC needs PHP 5.6.13, where as application XYZ will not work above PHP 5.4.45. You’d need to do a fine balancing act to make sure nothing gets broken even while you get all that’s needed for apps to run.
3. Chasing down “mysterious” incompatibilities – We’ve heard this all too often – “But it worked perfectly in Dev!”. No matter how carefully you maintain your QA and Production environment, something or the other changes eventually, leading you down those detective sessions where you locate an obscure library path that is broken.
4. Updating and testing deployment scripts – The more daring of us use automation tools, and it does save time in building environments, but brings with it another issue – writing fool proof deployment scripts. When a dependency change, you need to fix that, AND make sure the scripts can detect an issue and fix that.

So, what’s the way out?

Simplifying deployment using Docker

The central issue here is that you have to maintain different server environments. What if there’s no server environment to maintain? What if you get a new server with freshly installed new software for your shiny new code? This is what Docker makes possible.

Docker uses a light-weight server virtualization technology that makes it possible to spin up a new server instance with a simple spec file (called Dockerfile). Here’s how it works:

1. The developer creates a Docker container in a Dev machine.
2. The developer builds and tests new features in the Docker container.
3. The new code is committed to a repository along with a Dockerfile to create the exact same container.
4. Deployment is done in QA or Production servers using the Dockerfile so that the server environment will be replicated EXACTLY the same.

See the brilliance of the approach? No more time spent chasing ghosts and performing balancing acts.

Perfect. So, how do I get started?

Glad that you asked. The nitty gritty might be a little too big for this article, but here’s the low-down.

1. Develop using Docker containers – Get used to the idea of using containers for development. Create one container for each web application. You’ll soon realize that it makes dev machines much faster as you need to run only one web application container at any given time.
2. Use Dockerfiles to record dependencies – Create Dockerfiles to record the changes you make to the server environment. Start with a minimal OS image like phusion/baseimage.
3. Deploy Docker in QA – Next step, put a minimal Docker host operating system on your QA machine, and spin up Docker containers using Dockerfiles committed to your repository. Even if you use build managers like Jenkins, Docker has images for it. Create scripts or update existing deployment scripts to create Docker containers on the fly. Update the QA process to put a successfully built image in a private Docker registry.
4. Deploy Docker in Production – This is the hardest step. First choose a scalable Docker host OS like CoreOS, and bring online an alternate set of servers that can take your traffic load. Update your deployment process (which can include manual steps or automated tools like Chef) to create new server instances from the latest Docker images you have in the registry. Once you know that everything works as it should, stage a switch-over, and you’ll be online in your new scalable, fast Docker infrastructure.

Wondering if Docker would gel well with your technology? Well, don’t worry. The Docker ecosystem is vibrant and supports all major web application environments like AngularJS, Node.JS, Ruby on Rails, Django, Laravel, etc. So, just go ahead and give it a try.

Conclusion

Customers love applications that are constantly updated. It is also easier for project managers to gauge customer feedback accurately when small changes (like color, feature placement, etc.,) are rolled out independently. Docker, with its light weight server virtualization technology, helps you further streamline your web application deployment process, and become a true high-velocity app creator.