The term microservices came up at a conference for software architects, in May 2011, to represent a style of system architecture, not the size of the services that comprise it, as the name might imply.
The purpose of the microservice-oriented system architecture is to develop systems that are more flexible, scalable and easier to maintain than the monolithic system architectures normally used.
Why are microservices important to business?
Naturally, the objective of the companies is to keep up with the evolution of the market to achieve more and more excellence, cost reduction and agility to create new products and services to stand out in the market.
To that end, the system architecture also needs to evolve. What is important for these systems?
- They must offer customers a rich, interactive and dynamic user experience across multiple platforms, including mobile devices.
- They must be highly scalable and available, as well as run in cloud environments.
- They should be updated smoothly, that is, updates should not cause interruptions or instabilities that disturb users.
Microservice-oriented architecture makes it possible to build systems with all these attributes, unlike monolithic applications. Microservices allow:
- new processes or services to be made available without impacting existing processes and services.
- changing processes and services without stopping the entire system.
- optimizing the use of cloud infrastructure.
- reducing maintenance complexity.
In this way, the development team deploys new services throughout the life cycle of the application in a simpler and faster way.
How monolithic architecture works
The main application development languages provide abstractions to break the complexity of systems into modules. However, they are designed to create a single monolithic executable, for which all the modularization is performed on the same machine. The modules share processing resources, memory, databases and files.
A regular monolithic architecture for a complex system can be represented by the figure below, for which all business functions are implemented in a single process.
Over time, the system grows and becomes more and more complex, consuming more and more resources. Some substantial maintenance challenges also arise:
Increased complexity and size over time: The system becomes so complex that maintenance becomes more and more expensive and slow, as developers have to navigate through several codes.
High dependency on code components: Many functions are interdependent and intertwined, so adding or maintaining system components can cause inconsistencies or unexpected behavior.
The system scalability is limited: It requires the entire system to be replicated even if the new instance needs only part of its functionality, which results in higher than expected costs.
Lack of flexibility: It requires developers to be tied to the technology originally chosen for the system, even if it is not the best choice for some situations.
Difficulty putting changes into operation: Any change, however small, requires restarting the system, which results in operational risks and requires monitoring by the system’s development, testing and maintenance team.
How the microservice architecture works
A single application is developed through the microservice architecture as a set of small services, each running in its own process. Each service is developed according to a specific set of business rules and implemented independently.
Thus, it is possible to break some barriers of the monolithic architecture model:
More stable service maintenance and evolution: Developers deal with codes that perform a single function, and each single service does not grow indefinitely as the system grows.
Low level of coupling and interdependence of services: Accordingly, maintaining a service does not directly interfere with other system functionality.
System scalability: It is achieved by deploying and replicating microservices independently through the infrastructure of servers, virtual machines and containers. This makes the system’s growth and adaptability much more flexible.
Cost reduction: As each application only uses the services it needs, costs are directly associated with the system’s functionality and usage load, so there is no need to charge costs associated with unused functionalities.
Technology flexibility: It is not necessary to tie developers to a specific technology, as the coupling of services is low. In this way, the best technology can be used to meet each case, in addition to the possibility of continuously evolving the system, thus reducing the risk of technological obsolescence.
Ease of putting changes into operation: The changes in the system are made through the changes and evolution of the services. Thus, no system needs to be rebooted to continue operating. The development team monitoring the change is the team responsible for the services that will be changed.
Considerations for adopting the microservice architecture
According to Martin Fowler’s analysis, a complex system using microservices has a lower maintenance cost than the application system with monolithic architecture, as exemplified in the graph below:
Martin Fowler -Microservice Premium
However, one of the barriers to adopting a microservice-based architecture may be the higher initial cost compared to the cost of a monolithic system, as the need for extra effort to manage microservices must be taken into account.
Major players in the market may see this as an opportunity to provide tools that help teams manage microservices in order to reduce the barrier to adopting this architecture.
Microsoft is already doing this with Azure Service Fabric. This feature acts as middleware to facilitate the creation and management of microservices at the corporate level. An interesting feature of Service Fabric is that it can operate regardless of whether the platform is in the cloud or not.
Is adopting the microservice architecture risky? In the case of complex systems, any chosen architecture has risks. You need to pay attention to the following factors related to microservice:
- Increased coordination complexity.
- Communication between microservices.
- Governance.
Therefore, these factors must be well planned for the adoption of the architecture to be successful, and proper execution must become part of the agenda of the organization’s technology department.
