With the recent boom in containers, everyone wants containers everywhere, without realizing their utility and impact.
I’m hearing more and more people saying we need to containerize everything (which uses vms these days) and obviously with related tools / software. Some even claim that moving to containers will modernize the application and let customer enter in the “IT 4.0” ages.
My job is a post-sales role, to make things happen, but also to advise and guide clients – I can’t tell clients to follow such ideas “just because <buzzword> is shining”.
We will go through this problem of container and modernization, and demystify myths and realities …
What are containers, high level?
I mentioned in a previous article that containers and virtual machines (and, in some ways, composable infrastructure) are on the same level: this abstracts hardware, drivers, and firmware, but it’s not at the level if “Cloud”, neither “IaaS” or “PaaS”.
A VM runs on an underlying hypervisor, the VM is made up of an operating system, libraries, runtime and binaries to be executed.
A container runs on an operating system and is made up of a part of the operating system, libraries, runtime, and binaries to be executed.
Containers are a way to package a runtime, its libraries and binaries, and at the same time provides an isolated execution space in an underlying system.
Difference is what is shared – for vms you share the hypervisor, for containers you share the operating system.
Whether it’s a container or a vms, it does not influence or move the needle of how your application code is executed.
What is a modern application?
A “modern application“, in 2020, relies on microservices. Not SOA, not client/server – microservices are the holy grail.
Microservices in a kind of detailed pattern of application behavior, this usually means:
- each “service” is part of the application, small systems that only do one thing and do it well
- each service should be developed individually, have a separate lifecycle and distinct scaling model.
- communications between services use dump pipes (and not intelligent pipes such as ESB as SOA does)
- the entire application could consist of hundreds to thousands of services and could scale up to thousands of execution units
Microservices enable greater flexibility, scalability and portability, but at the cost of underlying infrastructure, workforce, reorganization and transformation.
Microservices = Container?
This is where we start to see myths and immaturity.
No, “microservices” does not mean containers. Again, container is a way to isolate and package, but microservices are part of a system and can run on anything.
An application designed by microservices can be built with any type of underlying infrastructure ranging from physical server to PaaS and FaaS – it only need a runtime to run the code / binaries.
Microservices are not locked to any orchestrator or runtime such as kubernetes or containers. It is even the reverse, one of the objectives of this application architecture is to avoid any dependence on underlying systems.
Another myth is that vms take too long to deploy and start. In fact, operating system takes time (this is the case any physical / vm / container), but virtualization itself is very fast. Think of technologies like “Instant Clone” that can clone and turn on hundreds of vms per minute, or unikernels that could boot in 20 milliseconds.
One final myth: placing binaries and libraries in a container will not allow scaling or flexibility if the binary has not been developed for this purpose.
Modernizing Application and containers
From the previous paragraphs, you probably already understood that there is no relation between packaging/isolation form factor (container, vm, physical) and modern application development.
Ingesting libraries, runtime, and binaries from a VM (or baremetal) to a container will not magically convert this app into a modern app.
Let’s take a concrete example, one of my old applications from 2003, from my time as a Java developer. This application controls (automatically or with manual override) mirrors of an Heliostat system for an energy supplier, goal is to align with position of the sun, helped by a specific camera.
Made in Java 1.4 and Swing, developed with MVC method. It is composed of 8 services (main user interface manager, manual commands, coordinates dashboard, menus and popups from the UI, network client, network server, motor controller (in Assembly) on parallel port, reception and translation of images received from the camera).
Some are multithreaded, some use sockets/pipes but not all have these properties.
Each physical server was running 4 instances (due to LPT ports, interrupts… in the good old days!), Which worked perfectly on an HP rack gen1 with 1 GB of memory and its single processor core. Client machines, Pentium III, were running the application in client mode.
Conversion to vm or container, approach #1:
- Infrastructure-centric method. A full instance would be converted into a single container, depending on available “converters”. So I should end up with a single vm / containers allocated with 256MB of memory and 250m cpu.
- Difficulty and conversion time? Very short, takes hours/days. Choose a compatible container base (alpine seems like a good one), deploy an openjdk runtime which is still compatible with used components, add .java files and some tools, add a compile command (RUN javac -deprecation -classpath /opt/helio/HelioServer.java), set the entry point (CMD [“java Heliostat”]) and we’re good.
- How much value does this bring to my app? Absolutely nothing. Zero added value. This helps Infrastructure to backport this from old Debian Woody to a newer system, but at the cost of risk of failure. Technical debt is still there.
Conversion to vm or container, approach #2:
- Code reuse and adaptation. Review code, without redoing everything, and try to reduce technical debt: separation of services and encapsulation of pipes in agnostic communications. Each group of services will end up in a container- server part would use 4 different containers, client part would consist of 5 different containers.
- Difficulty and conversion time? Moderately long time, takes weeks/months. Not so simple since you have to reverse engineer and have developers who know the code and method of when it was developed.
- How much value does this bring to my app? This brings the application back to life, it helps to pay off part of the technical debt. Value is there, but it’s still an “old fashioned app”: old UI, still uses LPT ports.
Conversion to vm or container, approach #3:
- Recoding the app! We restart from the beginning: collect use cases, requirements, constraints, redo the hardware purchase list, etc.
- Difficulty and conversion time? Very long, takes months/years. Technically little less difficult than approach 2 because there is no need to reverse engineer the original code. On the other hand, several other profiles are necessary (architects, lead, scrum master…), non-technical difficulty is enormous.
- How much value does this bring to my app? Original app is dead, a new one is born. Technical debt is gone, this could be a true modern app and cloud native.
Obviously, approach 3 is the most beneficial. But it’s also the most expensive, and it must be worth it (typically my app won’t be worth investing millions 🙂 ).
On the contrary, approach 1, which is the most often used, is not very expensive, but still not for free and the only value it brings is to have a newer underlay system.
I would say if the cost of the original system is a concern this solution could be considered, otherwise it’s just tech for fun.
Converting an application to a container does not turn it into a modern application.
The most common approach (#1) is also the most useless in practice, it only allows to extend the deadline of hosting.
This could be a viable choice for applications doomed to die off in the near future, but when the application is significant, simple conversion is at best a waste of time, with false hopes and misleading display just to tick the box “we use containers”.
N.B.: Some even add more buzzwords to the unnecessary containerization, for example “machine learning will modernize the application in native cloud”.
To me, adding so many buzzwords on emerging and/or recent technologies goes beyond marketing message, it’s an attempt of enchantment derived from Scrabble.
Application architecture cannot be magically transformed by the Technology stack alone. It requires a true story of transformation.
Suitably qualify your applications and apply the most accurate transformation, but don’t get carried away by buzzwords.