The use of Microservices in the creation of new applications is a trend that is becoming increasingly popular among development teams that adopt the Agile methodology and that have to build the software to make the best use of the resources in the cloud.
The design of Microservice applications - through the interconnection of multiple services that are capable of performing specific functions - is able to make the development, updating, and testing processes of parts of the most complex systems more agile.
Not only the advantage is the possibility of being able to independently develop components that in the past needed to be tested and released in bulk. But also, it is possible to differentiate the execution environment among on-premise, public or private cloud hosting solutions, according to cost or safety issues. With Microservices it is also possible to re-use the functions in different applications, to expose functions externally to customers and partners, and to take advantage of them as building blocks for new applications, reducing development time.
Microservice development requires upstream an effective segmentation of application needs in independent services that are as reusable as possible.
The practices to the definition of Microservices
The Microservices development does not escape from the general rules that today suggest the use of very small development teams to guarantee the effectiveness of the results: from two to five people maximum, according to the "two pizza-size team size" concept theorized by Jeff Bezos (according to the volcanic Amazon CEO, “If you can’t feed a team with two large pizzas, it’s too large.”).
The principle of single responsibility (SRP) has an important role in the development of Microservices, namely that each software object, as well as each service module created, must have responsibility for a single function of the application. A principle introduced by Robert Cecil Martin, one of the authors of the manifesto for Agile software development and a reference point for innovation in this industry.
Beyond the general principles, an approach that is becoming popular for the creation of Microservices is the Domain-Driven Design, often shortened to the acronym DDD, and which has proved to be very valid for dealing with the complexities of distributed systems. In the DDD, the identification and segmentation of the "Bounded Context" become really important because it is the limited contexts within which it is appropriate to set the boundaries of each service. DDD also helps to create an effective collaboration between the experts of the application domain and the developers. So, it is possible to define the conceptual model of the services useful for solving specific problems for the next approximations.
Advantages of the Domain-driven design approach
Domain-Driven Design (DDD) is an approach to software development theorized by Eric Evans (and explained in the book "Domain-Driven Design: Tackling Complexity in the Heart of Software") to address complex problems by linking the implementation with an evolving model. Applied to Microservices, DDD helps to focus the project objectives on key aspects for the application logic, therefore to base the development on entities that have an effective functional sense.
The DDD approach can be put in place by bringing the assumptions of Bounded Context into implementation. A Bounded Context defines the model application context, that includes the points of the application in which the model is used and the boundaries at the organization level.
This approach allows keeping the model consistent over time, avoiding influences from the surrounding ecosystem.
DDD helps to avoid risks of excessive fragmentation of the model, which implicate problems of integration and consistency of information. For this, DDD includes a series of principles to help developers integrate the code and carry out tests by sharing ideas to guide the evolution of the model. In addition, DDD helps to create connections between different application contexts and manage the inclusion of existing services, which are not object-oriented logic native.
A significant area of use of DDD relates to the ability to reuse legacy software. In a White Paper entitled "Getting started with DDD when surrounded by legacy system" Eric Evans explains in detail the possible ways to effectively use the DDD approach in the modernization of existing applications.
10 key drivers to accurately define Microservices
Experience suggests to collect the following elements to define the boundaries of a microservice:
1. What does it do (functions and responsibilities of the entity)? What is the role of the structure of the application?
2. How it communicates with other Microservices;
3. The technologies used (it is possible to use languages and different framework, some of them are more suitable than others for specific functions);
4. Requests for each function (performance and accessibility);
5. Isolation needs between static services (which do not change over time) and services with frequent evolutions (the aim is to reduce the components involved in the changes);
6. Isolation needs between critical and non-critical functions (in order to prevent the spread of any problems).
7. Isolation needs among services that have independent lifecycles (code commit, to frequently test functions).
8. Isolation needs for services that depend on external functions (to avoid having to stop the entire application).
9. Grouping interdependent features;
10. Safety: how to isolate the functions that manage or process sensitive data.
Regardless of the approach chosen for the definition of Microservices, attention to functional requirements, structural aspects of the application, and skills are the keys to the project’s success.
© MIA s.r.l. All rights reserved