Approaches to containerization

IT leaders are looking at containerizing their existing traditional applications as a means to accelerate their cloud adoption. I have shared my learnings from working with clients on the different approaches to containerization for custom applications built using distributed technologies.

Are you having similar experiences with clients? Do you see similar or different approaches and when they are applied? Please do share your experiences.

Containerized applications should exhibit some essential characteristics. I am listing the most important ones below:

Immutable: you should not modify containers when it is running. That means no updates, no patches, no configuration changes. You build a new image and redeploy it.

Stateless: Containers are ephemeral (short-lived). Store data outside containers. Use a cache service or a datastore.

Benefits of containerization:

• Reduced operational costs from better utilization of infrastructure estimate
• Improved time to market, developer productivity, environment parity
• Better scalability, observability
• Containers are one of the preferred deployment models for Microservices based architecture.

As you containerize, consider ongoing support from the vendor for COTS / packaged applications, licensed middleware & database components.

Approaches to containerization

Brute force containerization involves discovering the processes/services of existing applications on a physical or virtual server at an operating system level. In this approach, you don’t use the source code to build the image. You can consider this approach for non-critical applications that don’t change in the future and need to be optimized.

Upgrade and containerize involves upgrading the programming language version or the application server version. This approach typically requires analysis to determine the remediation needed. Red Hat Migration Toolkit for Applications, Cloud Transformation Advisor are example tools that help. You will have to at the least remediate deprecated features. You can consider this approach for non-critical applications that you need to optimize and mitigate the technical debt.

Change the middleware and containerize involves changing the middleware or database as you containerize. Examples include Weblogic to Liberty / Tomcat, WebSphere Application Server to Liberty / Tomcat, Oracle to PostgreSQL, MSSQL to MySQL, etc … For Java applications Red Hat Migration Toolkit for applications, Cloud Transformation Advisor are example tools that help. For databases, there are several OpenSource, and Hyperscaler provided tools that help. You can consider this approach for non-critical applications that you need to optimize, standardize and move to alternate middleware (as clients prefer OpenSource alternatives).

Modularize and containerize involves decomposing the monolith. You get benefits of containerization if the containers are light, have quick startup time, and scale quickly. You can consider this approach for non-business critical applications, but you need to change frequently, optimize, scale better, and improve time to market.

Rearchitect, Rewrite involves using architecture styles like Microservice, Even Driven architecture. You can consider this approach for business-critical applications. Containers suit well as a deployment option. Many clients are also looking at serverless possibilities based on the use case.

In the above approaches, make sure the immutable and stateless behavior is in line with the expected non-functional requirements of the application.

Database containerization is an evolving area. Clients are containerizing selected small to medium size databases with non-stringent non-functional requirements and learning.

Source and target: Clients are currently using multiple platforms for the applications — physical servers, virtual servers, variations of Docker, variations of Cloud Foundry, etc. Most clients choose Kubernetes-based platforms like OpenShift, EKS, AKS, and GKE to run containers. While some clients are building the platform using the DIY (Do It Yourself) approach.

Depending on the source, target and approach, there are many OpenSource and 3rd party tools available. In IBM we use purpose-built AI and automation accelerators to identify candidates for containerization, analyze application dependencies and automate containerization.

There are many other concerns like the operating model, ways of working, client culture, and day two operations that I am not addressing in this article.

Are you getting into similar conversations with clients? What other/different trends and approaches are you seeing? Please do share your experiences.