Docker is famously easy to experiment with. But for enterprises with monolithic applications that are interested in Docker, there is little information about how to actually use Docker. And significant debate — even among Agile enthusiasts — about whether or not the microservices model is even worth the trouble.
If you have monolithic applications and want to improve application agility, how do you determine if Docker is the answer? Do the deployment benefits of containers make up for the upfront effort to partition or rewrite your applications? Here are four key questions you need to ask before you containerize an application:
1. Do you want Docker or microservices?
Docker is a software solution to effectively deploy microservices, but it does not automagically create microservices processes or teams. Before you start using Docker, you first need to decide if you want microservices with all of its benefits and risks. Then you need to travel the difficult road to build or refactor microservices applications, of which Docker is only a small part.
That said, there are certain components of monolithic applications that can be containerized: standalone or single-purpose components are particularly well suited for early experimentation with Docker, especially if they don’t maintain any sort of local state. These services mature quickly, are horizontally scalable and can wrap up complex functionality into an easily deployable package.
2. Are you operationally prepared to manage multiple languages/libraries/repositories?
Last year, we encountered an organization that developed a modular application while allowing developers to “use what they want” to build individual components. It was a nice concept but a total organizational nightmare — chasing the ideal of modular design without considering the impact of this complexity on their operations.
The organization was then interested in Docker to help facilitate deployments, but we strongly recommended that this organization not use Docker before addressing the root issues. Making it easier to deploy these disparate applications wouldn’t be an antidote to the difficulties of maintaining several different development stacks for long-term maintenance of these apps.
3. Do you already have a logging, monitoring, or mature deployment solution?
Chances are that your application already has a framework for shipping logs and backing up data to the right places at the right times. To implement Docker, you not only need to replicate the logging behavior you expect in your virtual machine environment, but you also need to prepare your compliance or governance team for these changes. New tools are entering the Docker space all the time, but many do not match the stability and maturity of existing solutions. Partial updates, rollbacks and other common deployment tasks may need to be reengineered to accommodate a containerized deployment.
If it’s not broken, don’t fix it. If you’ve already invested the engineering time required to build a continuous integration/continuous delivery (CI/CD) pipeline, containerizing legacy apps may not be worth the time investment.
4. Will cloud automation overtake containerization?
At AWS Re:Invent last month, Amazon chief technology officer Werner Vogels spent a significant portion of his keynote on AWS Lambda, an automation tool that deploys infrastructure based on your code. While Vogels did mention AWS’ container service, his focus on Lambda implies that he believes dealing with zero infrastructure is preferable to configuring and deploying containers for most developers.
Containers are rapidly gaining popularity in the enterprise, and are sure to be an essential part of many professional CI/CD pipelines. But as technology experts and CTOs, it is our responsibility to challenge new methodologies and services and properly weigh the risks of early adoption. I believe Docker can be extremely effective for organizations that understand the consequences of containerization — but only if you ask the right questions.
Jason McKay is the senior vice president and chief technology officer at Logicworks.