Microservices and containers: the new architecture paradigm | SDG Group

The microservices and containers-based architecture is emerging as the new approach for building distributed mission-critical applications.

The microservices and containers-based architecture is emerging as the new approach for building distributed mission-critical applications. The idea behind is to rethink the applications not as a single and monolithic entity but as a collection of independent services that work together. 

Every microservice can be written and implemented with the more suitable language or technology exploiting the capability of containerization. This to meet, in the best way, the peculiarities and requirements related to a specific need. With this new architectural paradigm, it is possible to have all the necessary flexibility to develop an enterprise application without the compromises, usually, present in a monolithic application. 

Rethinking the current way of designing architectures

The definition of an application based on microservices and containers is mainly concentrated to the business logic. In fact, the focus is the definition and the organization of microservices as isolated and reusable entities that implement a portion of business logic and the way to allow the communication between them. Whereas talking about conventional application, the focus is on the investigation of the technology that covers requirements and constraints.

One of the key differences between microservices and a monolithic application is the number of active processes. A traditional monolith runs on a single process that can be replicated to support scale, but microservices all run on their own process. As a result, microservices are able to scale based on the load attributed to each single service rather than the load seen by the system as a whole. 

Rethinking a monolithic application as a collection of a separated processes can be a powerful mechanism for scale and feature encapsulation but it adds a complexity to communications between entities. The means by which communication happens throughout a service-oriented architecture (SOA) is critical to the success of an application based on microservices and containers approach.

Defining Microservices

Microservices architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. (Martin Fowler and James Levis, “Microservices”, March 2014.)


To support Microservices, it is mandatory having a light-weight mechanisms, small independently deployable services, scalability, and portability. Those requirements can be met by using containers. Containers are usually described as runtime environments with many of the core components of a virtual machine and isolated services of an operating system designed to make packaging easy and execute these micro-services smoothly. Containers are not a new technology. They have been around Linux world for a long time. 

The most known containers technology is Docker that satisfies all the capability necessary to build microservices in an independent and portable environment. The Docker containerization platform has come up with an enabling engine to simplify and speed up the life cycle management of containers. There are industry-strength and openly automated tools made freely available to ease the needs of container networking and orchestration. Thus, producing and sustaining business-critical distributed applications is becoming easy. 

Business workloads are methodically containerized to be easily taken to cloud environments, and they are exposed for container crafters and composers to bring forth cloud-based software solutions and services. Precisely speaking, containers are tuning out to be the most featured, favored and fine-tuned runtime environment for IT and business services.

Some of the large internet companies including, but not limited to, Netflix, eBay, and Amazon changed their architecture by adopting the microservices and containers approach. This is a clear sign of the success of this technology. Also, it represents the current and future trend of the application architecture.


Benefits

The choice of changing the architecture by adopting microservices and containers has been driven to exploit their major benefits:

• Thanks to containerization, each microservice is totally independent of other ones in terms of resources;
• The small dimension of microservices makes simple to understand how it works and the logic behind;
• The developers are more productive and also the tasks can be parallelized;
• The application starts faster and speeds up deployments;
• Each service can be deployed independently of other services - easier to deploy new versions of services frequently saving time;
• To implement microservices, it is possible to use the more suitable technology and this can be done without taking care of the technology used for the other ones;
• Easier to scale development. It enables you to organize the development effort around multiple teams. Each team is responsible for one or more single service. Each team can develop, deploy and scale their services independently of all of the other teams;
• Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system;
• This approach emphasizes the agile development methodology;
• Eliminates any long-term commitment to a technology stack. When developing a new service you can pick a new technology stack. Similarly, when making major changes to an existing service you can rewrite it using a new technology stack.
  
  

Drawbacks

As every approach, an architecture based on Microservices and containers has a number of drawbacks to consider:

• Developers must deal with the additional complexity of creating a distributed system;
• Testing is more difficult;
• Developers must implement the inter-service communication mechanism;
• Implementing use cases that span multiple services without using distributed transactions is difficult;
• Implementing use cases that span multiple services requires careful coordination between the teams.

To a successful implementation, it is important to address these potential issues.

To sum up, the microservices and containers architecture represents the current frontier of the way to implement applications. The adoption of this architecture increases the initial effort to define the patterns but simplifies the maintenance and the natural life-cycle evolution of every complex application.