According to a recent O’Reilly study on the adoption of microservice architecture (MSA), almost one-third of respondents say their employers are implementing or migrating to microservices for a majority of their systems. More than three-fourths of the respondents have been using microservices.
In the foreign market, microservice architecture is used by such giants as Twitter, Facebook, Amazon, Spotify, Uber, Google. Netflix estimates that it uses around 700 microservices to control each of the many parts making up the entire Netflix service: one microservice stores what shows you have watched, one deducts the monthly fee from your credit card, one takes a look at your viewing history and uses algorithms to suggest a list of movies that you will like.
So what is actually Microservice Architecture?
A new user of MSA (Microservice Architecture) at first exclaims, “I studied these microservices back in my early student days,” and they are partly right, but only partly.
Let us find out why, but first of all, let us look at some key concepts.
MSA is a method of creating software products by developing modules that are independent of each other. Each part of the application is responsible for doing specific discrete tasks and can be changed or extended without adding new features in the others. The services communicate with each other through messages.
A system with MSA is strong and independent. According to this idea, such a system no longer needs to consider scalability, since it can run on different technology stacks and fix its errors easily. This approach allows faster development and flexibility in providing support.
In practice, this may seem to be an overloaded and rather fragile construction, entangled in itself and its connections. To efficiently manage the cascade of microservices as a single organism requires a sufficiently high qualification and seamless work to coordinate this “hive”. Such systems are difficult to understand and require a special attention to the architecture, including from analysts.
Macrocosm of Microservices
To get a better understanding of microservices, let us compare or even oppose them to a large monolithic software system.
Unlike a monolithic system, each microservice implements its own function, has its own database, and, in some cases, uses its own technology stack.
Let us focus in detail on the most important features of microservices.
They are small in size and responsible for a minimal individual functionality. If we look for an analogy, this is one piece of the Lego set that is used to create the Millennium Falcon.
A microservice architecture is the embodiment of High Cohesion patterns: high cohesion and low coupling. A microservice has to be an independent component, i.e. a unit with code that can be replaced or updated independently.
Low coupling means that any change to one service should not affect the others. To achieve such an approach, you must ensure that each service knows as little as possible about each other.
Defining the microservice boundaries is the most important step. This will affect the rest of the service's life, and will also have a serious impact on the team responsible for it.
One of the most well-known techniques of splitting into microservices is to determine the business capabilities of an application and create one microservice for each of them. Business capabilities are functions that will be available to users when they use the application.
For example, “Order creation management” is transformed into a separate order creation service, and “Payment management” – into a separate independent payment microservice that can be built into dozens of platforms.
One of the most important tasks is to be able to correctly identify the smallest independent business function, which in the future can be transformed into a separate microservice, and to explain the rationale for that decision. In the beginning, it may be difficult, but everything comes with experience, and in the future it will not require significant effort.
To minimize errors when defining the boundaries, you need to think about them first. Therefore, Monolith First is a generally justified approach, in which the system is developed first in a traditional paradigm, and then when established areas appear, they are decomposed into microservices.
The important thing is that the benefits from splitting should exceed the amount of complexity from revising these boundaries.
This approach to the incremental formation of a set of microservices is similar to the iterative development used in Agile, also called Evolutionary Design.
Design Principles for Services in a Microservice Architecture
On the very surface in large-scale projects, there is a methodological issue of transition to microservices.
In short, it is caused by:
Different product design principles that bring chaos to understanding how the microservice hive works.
Different priorities and focuses – in which it is not clear where, why and when to move.
Different understandings of customer needs. This is a significant problem because the product is implemented specifically for the customer, otherwise why does the customer need it at all?
These problems can be solved by introducing non-architectural design principles for services in a microservice architecture, which systems analysts can rely on in their work.
So declaring unified criteria of service delivery quality, and performing actions for closing the needs of external or internal customers will allow systems analysts to clarify and simplify interactions when agreeing on quality criteria for services with a microservice architecture. It will make it easier to systematize the existing chaos.
There are six time-tested principles that service owners need in order to define and agree on quality criteria. These principles are important to other systems analysts and process engineers when they develop and modify services.
Let us go over them in more detail and begin with the “Know Your Customer” principle.
Each service must know their suppliers (service Before) and consumers (service After or a Customer). Changes to the service must be coordinated with the internal consumer, the supplier.
For example, if you are a general product service for parent capital, you should definitely understand that the consumer is a Mortgage Stream, and the supplier is the Pension Fund. The design should take into account all the wishes/requirements of the Mortgage Stream within a set of attributes or a list of processed documents, as well as the demands of the bank customers themselves on the issues of the parent capital, which may not be addressed immediately, but may be affected in the near future. Therefore, when planning microservice development, these issues are better to consider at the start.
Now let us look at the “Watch Your Health” principle. It means that the service owner should monitor the declared quality criteria and identify deviations and their causes. The company should build unified standards of quality metrics for monitoring microservices.
Monitoring is crucial. When it comes to microservices, in order to respond in a timely manner to possible roadblocks during integration or in operation, it is necessary to attach at minimum a high-level monitoring tool such as Grafana, Kibana to microservices, and it is better to tackle this issue systematically. Otherwise, neither support specialists nor highly skilled developers will be able to quickly figure out the causes of a number of problems that may arise.
The “SMART Digitization” principle means that the service owner should strive to promote the service in all possible channels of interaction with the customer.
One thing that should be clear is
what exactly it is that you want to achieve,
how you are going to measure the result,
how the goal is expected to be achieved, if at all.
Suitability of the goal.
The moment in time by which the goal must be achieved (or, the task accomplished).
Systems analysts always need to weigh the risks and make the managers focus on the economic feasibility of rolling out potential features. The omnichannel nature of the implemented solution, i.e., the mutual integration of isolated communication channels into a single system to ensure seamless and continuous communication with the customer, has to be taken into account.
The “Maximization of State-Through Processing” principle says that microservices do not create duplicate documents and attributes, they eliminate duplicate data, and they populate data for the process automatically from the source wizard.
In simpler terms, the implementation of checklist items results in removing duplication of work, minimizing human error of manual data entry, and automating data enrichment from other services through various integrations, as the microservice database itself is limited and not dependent.
The “Secure-by-Design” principle implies that the service owner tries to ensure security at all stages of the production process – from inception of the service to its decommissioning.
This helps to avoid situations when, for example, the status model of the master system and a microservice do not match, which brings a host of problems, de-synchronizing the process.
The “Evolve Together with the Artificial Intelligence” principle means that the microservice owner seeks to leverage AI capabilities to create intelligent services.
We are all moving with the times, and today the use of AI, including recommendation systems and other cool things to create automatic recommendations on how to improve the service for customers, has become normal. But to understand whether you can use the AI capabilities right now, you need to give clear answers to the questions on the checklist. If you can check all the items, it is time to think about adding certain AI features to the service, which will make it more popular for the customers and improve quality.
Life Hacks to Make Working with Microservices Easier
One of the challenges of working with a huge number of microservices is the need to organize and systematize them. Otherwise, you could simply end up drowning in various unrelated names of microservice APIs, and it would take virtually forever to search for answers in tons of documentation, what is what and how to link them all.
An important thing that will greatly facilitate reflection of the relations in the documentation is the correct naming of the API services, which will make life and versioning support much easier.
This approach can address this challenge and provide clear answers to a number of important questions. I suggest you keep this approach in your collection of useful information.
What next?
We’re done with theory. If you still have questions about the microservice architecture, I’m ready to answer them in the comments section.
In the next article, we’ll move on to the practical part of working with microservices from the perspective of systems analysts.
