A limited number of organizations were born in the DevOps era. And many organizations have missed the container train.
This means that the majority of businesses are considering modern development practices, and already have a library of applications. So the question today is, Should they containerize them? There is no global answer. If there were, this issue would not be a sticking point for so many development teams. Answering this question is dependent on multiple variables for each application, and the answers are not the same for all companies.
Dimensions of Modernization
Deciding if you should or should not bring your existing applications into the modern development fold is driven by four dimensions.
- Perception: If the general perception is that all applications should be in containers, which of course is the space that Docker holds, then you will by default say yes.
- Value Gained: By containerizing your application, is the organization benefiting? Benefits can come in many forms: infrastructure, end-user value, faster, better release cycles to support the roadmap, etc. But for some applications, there is no benefit.
- Application Lifecycle: If your organization plans on end-of-life (EOL) for the application within the next two years, moving it may not be worth the effort.
- Application Architecture: If the application architecture is not conducive to modern development practices, the effort cost to move the application could be a waste.
If you grade your decision based on a yes/no for each of the above, then you will come up with a quick decision. However, you can make big mistakes answering any one of these. So I would suggest that you throw perception out the window, and focus on value and application architecture.
Application Architecture Goes Deep
Containers are an infrastructure technology. But containers have implications beyond infrastructure, and they’re huge. Containers are tightly coupled with application architectures as well.
Dimension 4 above goes deeper than most anticipate. There has been a strong “just containerize and figure it out later” movement. But saying “just containerize,” especially when those making the suggestion were not part of the original application’s creation, can be problematic—because monolithic applications, especially enterprise line-of-business applications, are called monoliths for a reason. They don’t up and move easily.
A lot of the development going on before web frameworks took over was in business applications that were backend heavy, and integrated into everything. The goal of many organizations’ homegrown business applications was to be the end-all be-all platform to run the business. (The opposite of microservices.) In those days, Service-Oriented Architecture (SOA) and Simple Object Access Protocol (SOAP) were the revolutionary concepts for breaking applications into smaller, discrete units with better connectivity. But they only focused on design patterns, not on how applications are deployed, or end-user value. In fact, the very structure of those applications was contrary to efficient deployment. Development happened in waterfall-based projects guided by business analysts whose primary job was to gate releases based on all functionality (there or not).
Sometimes the monolith being moved is a mini version of a much bigger one. Because a lot of application development back in the day was simply integrations between much larger systems in order to create continuity, or centralized portals and interfaces, you can’t move these applications without considering moving the entire web of them. And the other platforms may or may not be in your control.
This is why the current and future states of the application architecture are key considerations when deciding if you are going to migrate the application or not. If you move the monolith to a container, without the opportunity to break it down into smaller pieces, then you might not have any gain.
But this also means that if you do containerize your application, you need to think about other technologies like persistent storage solutions, so that you do not have to worry about moving the database as well.
It’s Okay to Say No
Containerizing your monolith is very much an opportunity cost calculation. Do you have more to gain than the effort it takes to move it? The answer for most organizations is going to be an obvious yes on some of their applications, and obvious no on the others. The ones that say no are not necessarily timid about modern development practices. There is a level of practicality, and an understanding that their systems probably have a short shelf life.
A large portion of monolithic applications can and should be containerized, and then undergo further modernization as to how they are deployed and architected. Considering all the right variables will dramatically increase success, and obtained value.
About the Author
Chris Riley (@HoardingInfo) is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling. In addition to being a research analyst, he is an O’Reilly author, regular speaker, and subject matter expert in the areas of DevOps strategy and culture. Chris believes the biggest challenges faced in the tech market are not tools, but rather people and planning.