Discover Why Docker Containers Are Cool

The Gist: I share how I came to discover Docker Containers and share thoughts on taking advantage of the technology.

Dealing with production errors are a normal course of doing business when developing application systems.  What drives people batty is when something that is tested, accepted, and deployed into another environment does something unexpected or flat out breaks.  I’m talking about the ubiquitous “Works on my machine…” phrase that can seem all too familiar.  Most of the time, even as one tries to create reasonably similar environments something is usually different about them.  I recall numerous occasions when I needed to troubleshoot production or testing environments to try and determine why things were different when compared to another environment even as code packages were the same.

Somethings Different Alright

Trying to determine differences between environments is a fun challenge and proves to be a good investment of developer time.  *Said no one.*   The worst is having to spend a few days trying to resolve the issue – clear waste of budget.  How and why does this come about?  When you consider the frequency of hotfixes, patches, and CVEs (Common Vulnerabilities and Exposures*) you come to realize that software updates, upgrades, and security fixes should occur frequently.  Now if you have separate and distinct environments for each stage of an application this means each environment must be updated.  Well, what if some updates lag or have install issues, what if ops can’t get to it just yet?  Do you hold up deployments?   Probably not.  With all the changes that are occurring to an environment its possible that not all updates occur to all environments at the same time or at all.  So sooner or later these environments drift away from their original specification.

Welcome Docker Containers

So about the time I had finally figured out why code in one environment was not working in another (supposedly mirrored) environment is when I first heard about Docker.  This phrase caught my eye right of the bat:

[Because of the Docker engine] containerized software will always run the same, regardless of the infrastructure. Containers isolate software from its environment and ensure that it works uniformly despite differences for instance between development and staging.

So instead of deploying just the application itself, package up the code and all of its dependencies as a unit.  This image can be version controlled and deployed. Now you have the exact same image on your laptop as in production and any other environment as needed and be assured that the exact bit-for-bit release with its dependencies is executing in all places.   This isn’t a silver bullet but the barrier to entry is not that high.  Certainly new tools and procedures will be necessary but the investment in containers can open up other possibilities and opportunities.

What You Can Expect When Containerizing Apps

Around the time I had learned about Docker Platform as a Service vendors were emerging.  In short, the folks over at Heroku put together a great write up on considerations for building apps: The 12-Factor App, which addresses the types of considerations when deploying on their platform.  I referenced this information as I tried my hand at creating a Docker container for a web application I supported.  The app had its share of technical debt to deal with and needed some TLC refactoring.  The biggest one was removal of any hard-coded configuration.  No app should do this anyway, so the app was modified to pick-up configuration settings via environment variables.  Secondly, logging needed to be addressed – instead storing logs as files, route them to STDOUT.  This ensures logs do not disappear if the container is terminated or fails.  These events are collected by the execution environment and can be sent externally.  Today’s cloud offerings have gotten better and newer architectural approaches like microservices have gained traction.   As such NGINX’s Microservice Reference Architecture extends the 12-Factor doc and seems to be a great starting point to get the most out of the approach.

Docker Container Use Cases

Shifting a legacy application to containers has an immediate benefit of removing the problem of environment disparities but it also presents other opportunities:

1. Supporting a Delivery Pipeline: with automated testing its easy to envision using containers to facilitate this:  creating the image with code and dependencies, running tests against the image, and if everything checks out prep the same image for deployment.
2. Need to update or patch dependent libraries?   see #1
3. Remove Unused Stuff: Remove all unused software apps, utilities, and libraries (like SSH and cURL) from the image thereby reducing your surface area from cyber attacks.
4. Discovered a Bug? Rollback to the prior version of the image.  Containers startup quickly and your assured that the exact image necessary to run the prior version is ready to go.

There are other things to consider like managing and monitoring deployed containers but as you can expect these tools exist.  The point is if you’re seeking to improve your development processes or when you want to find ways to deliver products faster, containers are a technology worth considering.

PayPal’s Journey to Docker Containers

PayPal turned to Docker to help with developer efficiency and operations. PayPal used Docker Containers as a centerpiece for application packaging and operations aimed at addressing issues around myriad application stacks and architectures to relieve pressure on operations to understand and deploy it all. PayPal was able to realize important benefits even as the applications themselves did not change.  Some of the payoffs:

• 50% increase in developer productivity in building and testing applications
• operators and administrators enjoy a single set of operating procedures no matter the application

I think the lesson here is to first determine problem areas and areas of friction to your achieving goals then figure out how tech offerings can propel you forward.

Indeed the container based application strategy appears to be growing.  Furthermore, Docker and AWS are making it easier to deploy container based apps on AWS.   It’s no secret that I’m juiced about containers.  Its not just about code — it’s about delivering software based solutions more efficiently.  Container based solutions can be a big part of that vision.

Onward!

*  CVEs: just check out how many there are! Try searching for ‘javascript’ or ‘windows’