Part 1: How to Migrate Applications to a Container-Managed Microservices Architecture

PART 1: The era of monolithic enterprise applications is over. To stay competitive, companies must transition their applications to microservices and container-managed architectures.

For decades, software companies have developed monolithic enterprise applications. This architecture was reasonable since the support required was manageable, and the system worked well within a limited scope of applications that did not require scalability. But problems emerged as systems grew larger and more complex. The typical response has been to break monolithic applications into smaller, autonomous microservices, each deployable and sustainable by an agile team of software engineers, making cross-team collaboration redundant.

Microservices architecture (MSA) is the solution to the problems associated with the traditional backend monolithic applications. But just splitting applications into containers doesn’t make them automatically scalable. Proper planning is needed to determine how these individual containers run.

The goal of migrating legacy applications is to provide a more agile and scalable environment for individual modules and features on the site. This allows the modules and features to be more easily managed and updated than monolithic platforms. Running such an environment leads to performance improvements for each migrated feature.

Key Drivers of Microservices Architecture

To remain competitive, businesses must innovate and launch new products that outperform the competition. At the same time, they need to be flexible enough to meet the changing needs of the customer. Migration to MSA enables them to do both.

Microservices are an architectural solution for designing complex, mostly web-based applications. They have evolved from the service-oriented architecture designed to overcome the fact that monolithic architectures were not designed to scale horizontally. There are ten primary benefits for re-architecting a monolithic system into microservices:

  1. Scalability – It is easier to scale only the most essential services at the appropriate times than scaling the whole application.
  2. Availability – Application consist of many microservices, which means redundancy of required services at a lower cost.
  3. Fault tolerance – If any single microservice fails, the other microservices will continue to function.
  4. Agility – The development of microservices requires small agile teams that speed up the development process.
  5. Polyglot persistence – Microservices allow for the creation of central data persistence and can have services-based local persistence.
  6. Maintainability – Maintainability is all about fixing issues and installing upgrades of specific services. Microservices improve maintainability by allowing the installation of small servicers.
  7. Software stack agnostic – Microservices allow a choice of technologies for the services, and services do not have to have the same microservices.
  8. Faster development – Using smaller components enables application teams to take advantage of continuous deployment, which means faster time to market.
  9. Clear separation of services – Microservices manage the separation of essential and non-essential services very well, which improves the security of the software.

While there is little doubt that microservices-based applications are becoming more popular, the adoption rate has been slower than anticipated. According to a survey conducted in early 2020 by O’Reilly Media, less than two-thirds (61%) of respondents said they have been using microservices for a year or more.[1]

However, the survey suggests the shift to microservices will accelerate. Sixteen percent of respondents said they are beginning to adopt microservices, and almost a quarter (23%) said they plan to switch in the near future. (See Figure 1.).

Figure 1

How to Migrate Applications to a Container-Managed Microservices Architecture

Source: O’Reilly Media

Container Technology Overview

Containers are ideal platforms for deploying microservices as they are packages of software that includes everything microservices need to run, such as code, dependencies, libraries and binaries.

Containerization allows developers to run applications in isolation while sharing the same operating system (OS) resources. Virtualization provides a similar capability but with its own OS. And virtual machine systems (VMs) can run different operating systems and host multiple applications whose mix may change over time. Alternatively, a container will typically have a single application.

Unlike VMs, containers share the OS kernel instead of the full copy, which is like having numerous VMs on a single host. Although it is possible to put microservices in multiple VMs, containers are more commonly used since they take up less space and boot up faster.

Both microservices and containers are destined to play a significant role in the enterprise re-architecting process. However, containers hold significantly more benefits for developers, the development process and the organization.

Docker Alternatives for Containerization

Docker is one of the most popular choices for building and running containers. It is based on a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running and distributing the Docker containers. The client and daemon can run on the same system, or the Docker client can be connected to a remote Docker daemon. The Docker client and daemon communicate using a REST API over UNIX sockets or a network interface.

There are many Docker alternatives available:

  1. Java containers. Jetty, Tomcat, WildFly and Spring Boot are container technologies that enable standalone Java applications. They have been used for years to incorporate parts of the Java runtime into the app itself.
  2. Unikernels: Applications commonly found running in a Docker container require only a fraction of the advanced capabilities offered by the virtualized environment that they run in. Unikernels are designed to optimize the resources needed by a container at runtime. They map runtime dependencies of the application and only package the system functionality required at runtime into a single image.
  3. LXD: LXD is a next-generation Linux system container manager by Canonical Ltd. LXD containers are built and operated with the same tools as traditional VMs but can achieve similar runtime performance as containers, and offer improved utilization compared to VMs.
  4. OpenVZ. OpenVZ is a container platform for running complete operating systems. It is different than a traditional virtual machine hypervisor because it requires both the host and guest OS to be running Linux. Because it shares the host OS kernel like Linux containers, OpenVZ containers are much faster and more efficient than traditional hypervisors.
  5. Rocket: Rocket containers emerged from CoreOS to address security vulnerabilities in early versions of Docker. In 2014, CoreOS published the App Container Specification (APPC) to drive innovation in the container space, which spawned many open-source projects, including Rocket.
  6. Windows Server Containers: The launch of Windows Server 2016 brought the benefits of Linux containers to Microsoft workloads. Microsoft has re-engineered the core Windows OS to enable container technology and worked closely with Docker to ensure parity in the Docker management tooling.
  7. Hyper-V Containers: Greater security can be achieved by hosting Windows Server containers in lightweight Hyper-V virtual machines, which bring a higher degree of resource isolation but at the cost of lower efficiency and density on the host.

Advantages of Containerizing

  • Efficient support for microservices. Scaling decisions can be made at a more granular level with a microservices architecture.
  • Resource efficiency and density. You can select where to apply resources to meet scaling needs based on smaller, more granular components, allowing for more efficient system optimization and organization.
  • Portability. Containerization can run on any desktop or laptop capable of carrying out a container environment. Applications are executed faster because they do not need the host operating system.
  • Massive and smooth scaling. Containers are lightweight and do not overload.
  • Highly efficiency. Containers are very efficient because they use far fewer resources.
  • Improved developer productivity and development pipeline. Developers stay as close as possible to production, and every service running on its own VM is required to reflect how the production application runs. Also, containers allow the development environment to be as fast as possible for interactive use.

Limitations of Containerization

  • Complex development, deployment and monitoring.
  • Challenges finding skilled developers.
  • Not all applications benefit from containers. Applications designed to run as a set of discreet microservices stand to gain the most from containers.
  • Limitations for running stateful applications.
  • Persistent data storage is complicated.


Altran recommends adopting the following containerization best practices:

  • Reduce the size of your container as much as possible.
  • Keep data outside the container.
  • Package a single application per container.
  • Decouple containers from infrastructure.
  • Optimize for the Docker build cache.
  • Container images are built from one source code version.
  • Images have tags following a standard.
  • Do not run containers as root as they can be corrupted.
  • Deploy containers with signed images.
  • Patch vulnerabilities by deploying new container versions.
  • Ensure the respective licenses allow third-party libraries and packages in the Docker image before adding them.
  • Identify and separate code, configuration and data. Configuration, data and keys should come from the environment.
  • If containerizing databases, consider shared (networked) file systems or block storage (volumes) that can be independently managed and attached to and detached from any host.
  • Do not modify containers between pipeline stages.
  • Use an orchestration system, such as Kubernetes or Docker Swarm.


[1] Loukides, Mike, Swoyer, Steve, “Microservices Adoption in 2020: Everyone’s talking about microservices. Who’s actually doing it?” Jul. 15, 2020, O’Reilly Media, Inc.


Valérie Sauterey

Amit Goel

Director – Technology

Amit Goel has over 22 years of experience in the architecture, design and development of cloud, big-data, analytics, Java/J2EE and portal-based middleware in domains and architecting solutions in service provide various applications domain covering consumer service delivery platform (having flavors – content (mobile/PC/IPTV), rating & billing, enterprise oriented. Extensive project co-ordination experience involving design and development, managing deliveries

Contact US Capgemini Engineering


You can work with a company built for now,
or you can with one engineering the virtual networking software of tomorrow.