Containerization != Modernization

#containerization #appmodernization

Question: “Is the Application ‘A’ modernized?”

Answer: “We containerized Application A.”

Q: “So, Application A is now modernized. Right?”

A: “Application A is deployed on containers running on the target platform”.

Q: “……”

The terms Modernization and Containerization are often used loosely, even interchangeably. In general, our industry has not done a great job of standardizing the usage of these terms. In this article, I present my point of view on the differences between containerization and modernization and why these are two distinct concepts.

Application Containerization (that is, packaging applications so that they run in isolated user spaces using the same shared operating system) is absolutely the same thing as Application Modernization, at least according to two constituencies:

• Vendors who realize that if they don’t play up the two most frequently used jargons in the cloud space i.e., Containers and Modernization, they will not stand a chance.
• Infrastructure teams that realize that if they don’t take that pitch, they have not much left to sell.

Speaking as neither of those constituencies, this article will focus on what is right for the customer.

Before discussing any subject, it is important to understand the definitions of some commonly used terms. This article will describe what containerization and modernization are, and then will highlight the 4 key misconceptions about this subject in descending order of fallacy quotient.

Definition: Containerization

Before we understand containers, lets understand their predecessors – virtual machines.

Virtual machines (VMs) are an abstraction of physical hardware. They provide the ability to turn one server into many servers. The hypervisor allows multiple VMs to run on a single physical machine. Each Virtual Machine includes a full copy of an operating system, the application, necessary binaries, and libraries.

There are a couple of limitations with VMs. To run each application, we would require loading a full copy of an operating system, binaries, and dependent libraries, taking up several Gigabytes. Since each Virtual machine also runs a full copy of an OS, they can be slow to boot up.

Containers address the above issues well.

Unlike virtual machines, there are no separate copies of OS. Instead, multiple containers can run on the same machine and share the OS kernel with other containers. Each container runs as an isolated process.

Containers include runtime components -- such as files, environment variables and libraries -- necessary to run the desired application. The complete set of information to execute in a container is the image. The container engine deploys these images on hosts.

Containers consume fewer resources than a comparable deployment on virtual machines because containers share resources without an entire OS to underpin each application. For this reason, the time taken to boot up containers is far less compared to virtual machine bootup.

Definition: Modernization

Typically, what is legacy is modernized. So, what is legacy? Any technology, platform, programming language, framework that is a few years/decades old is generally termed as legacy. This definition, in our view, is one dimensional. A more holistic way to define legacy is anything that is not fit for purpose. It could be software, hardware, business processes, architecture, or experience. For e.g. if an ecommerce application built using latest web and mobile technologies and deployed on cloud doesn’t provide the desired customer experience, the application is qualified to be called legacy [from an experience dimension].

With that context, let’s look at the types of modernization [not in any particular order].

• Infrastructure Modernization - When the base foundation that hosts the applications is upgraded and the latest - be it storage, networks, virtual machines, containers, cloud environments and so on, the infrastructure is said to be modernized.
• Architecture Modernization – when the applications adhere to the basic principles of loose coupling, tight cohesion, separation of concerns, modularity, ease of deployment and management and so on, the architecture is said to be modernized.
• Technology Modernization – when the programming language versions, platforms, frameworks, libraries are refreshed and run on the state-of-the-art technologies, the technology is said to be modernized.
• Experience Modernization – when the end users consume the business capabilities in a way that is intuitive, fluid and more importantly that enables them to get the job done with minimum effort, the experience is said to be modernized.
• Operating model Modernization – when the development and deployment methodologies, application life cycle management, team constructs are laid out, adoption of automation levers etc. are revisited in context of the prevalent ecosystem, the operating model is said to be modernized.
• Process Value chain modernization – when the end-to-end value chain of a business capability is re-imagined and optimized to align with the business drivers, the process value chain and the business models are said to be modernized.

There could be more.

Modernization is not an all or none game. It doesn’t mean that all the above must be implemented for an estate to be labeled as modernized. Modernizing the estate even along one of the above dimensions is also termed modernization. A mature organization will not let modernization along ‘a’ particular dimension whitewash the other dimensions and therefore is aware of the pros and cons.

So, why is it that containerization and modernization are often used interchangeably when there seems to be not much in common?

It is not uncommon in our industry that anything new is touted as a panacea for all problems created hitherto [Object oriented programming languages, SOA, Microservices, DevOps, Cloud, Containers, and more recently AI]. There are voices that demystify these narratives and there are voices that hype up these narratives. Containerization is one such popular victim. There is little doubt that containerization is a technique that is immensely useful in optimizing OS resources and achieving the desired isolation and scalability for a certain class of applications. But to stretch the narrative to position containerization as modernization itself is taking it a bit too far. This kind of approach will result in sub-optimal landscape of application architecture and increase in the support and maintenance efforts therefore resulting in spiraling operational costs.

There are two big fallacies that are in vogue. Let’s examine them.

Containerizing an application and running it on cloud makes it cloud native.

Nothing farther from truth. Thankfully, the hype surrounding the term “Cloud native” is melting down. Customers, analysts, and partners alike are converging on the definition. Cloud native is about how applications are developed and deployed not where they are deployed.

It is about the ability to being able to make changes and rollout applications faster, it is about being able to manage the lifecycle of an application using automated DevSecOps pipelines, it is about being able to architect the apps using services that are highly cohesive and loosely coupled, it is about being able to deploy them so that they can be scaled up and down on demand. 12factor.net is a bible on cloud native applications.

Therefore, merely packaging the application to be able to run on a container that is in turn deployed on cloud doesn’t make it cloud native unless it adheres to the characteristics laid out as per 12factor.net or a similar philosophy.

Once the app is running in a container, application issues disappear

Absolutely not. Imagine an old car with pickup issues and engine problems. Driving that car on a F1 track will not make the issues go away. For a while, the smoothness of the track may camouflage the actual issues with the car but the core issues with engine remain. Similarly, modernizing the infrastructure and to some extent technology tooling doesn’t mean the fundamental issues with the applications go away.

A few of the non-functional aspects of the application may appear to perform well when you deploy them on infrastructure that is nimble and automated. Good to that extent but do not get deceived. Examine the application architecture, fix the design issues, and decouple the application components to make the application scalable and resilient at every level.

So, does it mean that it is mandatory to rearchitect the applications before containerizing them? Not necessarily. There are use cases and scenarios, like the ones mentioned below, where containerizing applications without rearchitecting may be necessary.

• Containerizing applications and deploying them on cloud [btw, its not necessary that containerized applications must be deployed on cloud, they can run on-premises too] is a good way to achieve portability across multiple cloud platforms.
• Situations where there is an urgent need to migrate applications from on-premises to more modern environments is achieved by using containers. While it may serve the migration purpose, it doesn’t give all the benefits of a modular container architecture.
• If the applications are already designed as microservices, containerizing those applications will provide the necessary isolation and scalability.

It is important to realize why you embarked on containerization journey and reset the expectations of the outcomes accordingly.

Conclusion

These are just a few of the key takeaways and there are many more. If I must distil all the learnings into headline items, here they are:

• True benefits of containerizing applications will accrue if the application is architected well [a reasonable definition of “well” is as per 12factor.net principles]
• If the applications are already architected well, containerizing them is great and has multiple benefits.
• Packaging an existing application that is not “well” architected and expecting to reap the benefits of containerization will lead to higher operational costs and should be avoided.
• There are scenarios where rearchitecting the applications is not necessary to containerize them if the costs and benefits are well understood.
• While there is no one definition of “modernization”, it helps to look at it from dimensions of infrastructure, architecture, technology, operating model, process value chain and experience. Based on what is important in a particular context, the definition of modernization could be painted such. At least, that way, there is a standard and unambiguous way for everyone to use a common vocabulary.