Application Modernization: Is Microservice Over Monolithic Still a Question?

As part of Solutions Review’s Expert Insights Series—a collection of contributed articles written by industry experts in enterprise software categories—Yann Guernion, a Solution Specialist for NetOps at Broadcom, delves into application modernization and whether “microservice vs. monolithic” is still a debate worth having.

Containerization has become the de-facto standard for companies undergoing digital transformation, owing to the agility it brings to application architectures. However, the actual return on investment is a legitimate question since the added value of container-based architectures is deeply tied to the granularity of application components. As microservice architectures aim to replace traditional monolithic architectures, the main challenge is the amount of refactoring necessary to modernize and containerize the existing applications. To answer this microservice vs. monolithic question, it’s essential to discuss the merits of platform stickiness, cloud portability, and the benefits inherent in application modernization.

“Please, draw me a sheep!”

“Please, draw me a sheep” is a phrase from the famous novel The Little Prince by Antoine de Saint-Exupéry. In the book, the Little Prince asks the narrator, a pilot who has crashed in the desert, to draw him a sheep. The Little Prince wanted a specific kind of sheep, and the narrator struggled to create one that met his expectations. Eventually, the narrator draws a box and tells the Little Prince that the sheep he wants is inside. This satisfies the Little Prince, who explains that the box is just what he wants, as he knows the sheep is inside. Such is the promise of containers, as later revealed in The Little Price, “What is essential is invisible to the eye.” In other words, some things that rule the world cannot be seen or touched but are still incredibly important. 

A container contains an executable image of a complete environment, including code, libraries, tools, and configuration. Its immutability and isolation ensure predictable execution, regardless of the environment. This makes the container a valuable technology for exposing services without worrying too much about internal implementation. It also explains the popularity of containers for building microservices-based architectures and the success of “out-of-the-box” services available in repositories like Docker Hub.

The Benefits of Containerization

Containers should not be simply considered the ultimate evolution of virtualization technologies. On the contrary, they are of the older design and offer fewer features than virtual machines (VMs). The ancestor of containers is the ‘chroot’ command that appeared in the early 1980s on Unix systems. The strong adoption of containers by Google, Amazon, and other web giants also popularized the technology, making it appear almost a generic solution for deploying applications.

When an application has been designed for a platform like Docker Swarm or Kubernetes, the application components (or pods) become mobile. They can dynamically migrate from one cluster node to another. In addition, the overall elasticity of the application is transparently managed by increasing or reducing the number of active components according to the level of demand, which is a significant advancement. Thus, the deployment and maintenance processes of distributed applications in the form of containers can be simplified and managed independently of the underlying infrastructure, whether physical or virtual (because, yes, there is nothing that prevents containers from running in VMs, but that is another story).

If we compare containers to VMs, it’s important to note that containers are extremely lightweight as they do not include a complete operating system. The consolidation ratio achieved is often over 20 containers for one VM. But this is not the only direct advantage. A front-end application service capacity must be dynamically adjusted based on user demand.

Provisioning additional containers only requires a simple command line and can even be fully automated by the platform orchestrator. In contrast, starting up additional VMs needs more complex operations. Each has its resources, operating system, storage, and network, not to mention configuration issues, as VMs are not immutable components. This explains why containers have been widely adopted for modern distributed application design.

The Limitations of Containerization

If there is one thing to know about containers, it is that you cannot simply put your legacy applications into a container and expect to reap the benefits of a “modernized” architecture. It is impossible to containerize old applications to make them portable and elastic. Even though it is theoretically feasible to put your monolithic ERP or CRM in a container, you should not expect it to simplify operations, reduce dependencies, or solve performance issues. In other words, if you consider containers the same as VMs, you should not expect to gain any specific advantages.

Suppose the existing application architecture is not thoroughly revised. In that case, the impact of containerization will be, at best negligible and, at worst, will result in inferior performance compared to the initial implementation. Therefore, containerization stays inseparable from the application architecture. Even if containers are excellent at supporting application modernization, they create new architecture requirements, especially regarding the granularity of components. It is often bad news when you realize that extensive application refactoring is necessary to take advantage of containers.

Whether you are a company maintaining in-house applications or a software editor reshaping aging product lines, it is vital to evaluate each application on a case-by-case basis and weigh the potential benefits against the costs and risks of containerization. In both cases, it is necessary to perform a preliminary analysis and create a roadmap that aligns with business transformation objectives.

For each software asset, you must assess if its architecture can be converted to a service-based architecture, what impact redevelopment would have, and what end-user or business benefits could be gained. Remember that while technical debt can sometimes be a necessary trade-off in the short term, it rarely justifies itself in the long term.

A Sense of “Déjà-Vu“

Those of us involved in the intensive application refactoring preceding the Y2K transition will likely recognize in containerization similar considerations to those advocating the adoption of SOA technologies. In practice, containerization fuels the same challenges SOA faced with rethinking application modernization architectures. The stakes are, of course, different. Twenty-five years ago, it was about gaining business interoperability by introducing standardized protocols and interfaces such as SOAP or WSDL. Today it is all about boosting business agility by enabling flexible and efficient ways to package and deploy software applications that can scale horizontally.

Make no mistake. The advent of container-based platforms and new standards based on microservices calls for a profound overhaul of software architectures. Due to the significant investment, some organizations may find little business justification for transitioning their internally developed application to microservices. However, you should undoubtedly monitor third-party software vendors’ roadmaps, especially if you experience deployment, maintenance, and scalability difficulties.

It is always a good sign to see some gradual refactoring that introduces microservices, even when it makes the first upgrade a little more complex. It means the product you acquired is still actively developed, and its architecture is future-proofed. So, while considering application modernization, should you prioritize microservices over monolithic? Maybe you should tell your IT department or software vendor, “Please, draw me a sheep!”.