Approaches to containerization

IT leaders are looking at containerizing their existing traditional applications 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, and 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 and Cloud Transformation Advisor are 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 and Cloud Transformation Advisor are examples of 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, Event 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-sized 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, many OpenSource and 3rd party tools are available. 

Tools to accelerate containerization

We use purpose-built rule engine/AI-based and automation accelerators to identify candidates for containerization, analyze application dependencies and automate containerization. Red Hat Migration Toolkit for Applications and Cloud Transformation Advisor are used to analyze the violations and remediation needed for Java applications. Our automated code remediation tools have a knowledge base of standard violations, vulnerabilities, and the code remediations needed. We use automation tools to generate the build and deployment artifacts needed to containerize applications (e.g. creation of Dockerfile, Helm charts). There are additional tools like JAX-RPC to JAX-WS conversion tool. Depending on the client's selected tools, the instrumentation is auto-generated for logging, monitoring, and observability.

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.