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.
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.
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.