Microservices Architectural Pattern

We’ve seen increase in adoption of Microservices architectural pattern over the last years as a better alternative to the Layered and the Service-oriented architecture. And a lot of new and hot buzz words are attached to this pattern in the field like CI/CD (Continuous Integration/Continuous Deployment).

From my article “Software Architecture & Design”, you will remember that (if you read of course) microservice architecture is a SOA (Service-oriented architecture). This means that the core software components in a microservices application are services. Functionalities and operations are achieved by communicating with service components through REST calls or some other messaging mechanism. This is a simplified illustration of this pattern.

Firstly, we have the famous concept of a Service. Service could be anything from a single function to a group of classes that cooperate to achieve some sort of functionality. It could be a single file or a bunch of modules. The size or the granularity of service is decided in the design phase, and actually, it is an important decision. Because even though there is some sort of freedom in defining the size of a service and how many functionalities it consists of, we need to be aware of the risk of falling into some haunted patterns like creating layer. This pattern is called the microservice pattern because service components should be micro. In other words, they should be single action services, and a service have a very specific tasks like generating PDF invoices, sending emails, processing payment cards, and etc.

Another concept is Independently Deployable Units which are the services. This means that services or service components should not be functionally dependent on other services. They should be independent and separate from each other which is the whole point of microservices architecture. The system should be loosely coupled. If a service needs something it doesn’t have or cannot perform its job, then it needs to call the service that can provide the necessary data to accomplish the task. That is achieved through the messaging mechanism in place, for instance, by communicating through APIs.

Last basic concept about microservices is the Topology notion. This pattern could be implemented using 3 common topologies (there are more than 3) which we will talk about in next sections. We will see microservices systems could be built using different approaches and the term topology indicates the specific approach used.

If you are familiar with Layered Architecture, we have layers which are relatively big consists of modules and packages that are dependent on each other. In such systems requests comes from the top-level layer and keep going down to the data persistence layer to make some change. Implementing microservices architecture is just breaking those layers into independent functionalities which of course will introduce new challenges such as duplication of functionality and data. In other words, we break down the monolith until we get to the point in which the applications major components are services. Before implementing this architectural pattern, the major components of the system were layers which encapsulated those services in an interdependent manner meaning that services in the layered architecture were tangled and dependent on each other and existed in one place. After implementing microservices these services become independent. These service components could be all distributed over a network or they could be in one place or somewhere in between these two.

We mentioned in the above that we can implement microservices architecture using different topologies. Now, let’s talk about most common 3 topologies.

REST API based Topology:

This topology is used for small to medium applications that have a small number of service components. Most of the time, the services are fine-grained meaning that they are single action services, and they perform only relatively small actions. So, this approach makes more sense as calling and communicating with these services hardly effects to the overall performance of the system. Such systems are characterized by a relatively thin REST API layer in front of the services that can be used by clients to access the functionalities of the system.

REST Application based Topology:

Another common topology is the REST application-based topology. This approach is similar to the first one, but the difference is instead of a thin REST API layer in front of the services, you’ll find a thick User Interface Layer depending on the system. This thick client app could be used directly to call the services or indirectly through a thin API layer. The layer could be even an entire web application that does much more than REST calls to the microservices. In this topology, the system tends to be larger and a little bit more complex than the first one. Also, service components in these systems are much more larger. I don’t mean that it is like service-oriented architecture. What I mean is that in this approach, service components tend to be larger than services in systems that are built using the first topology.

Centralized Messaging Topology:

Last topology to discuss in this article is kind of a similar approach to the service-oriented architecture’s messaging mechanism that uses a message broker. In the microservices pattern, it’s much more lightweight. In this pattern message broker is not as sophisticated as the service-oriented architecture messaging middleware. It does not perform any of the big tasks like message conversion or anything like that. Message broker in the microservices system allows for more control over services and the communication mechanism such as synchronous message and error handling. So, requests coming from clients need to pass through two layers; the User Interface Layer and the Message Broker.

These are just some approaches that we can use to build microservices architecture. As I said before, there is some sort of freedom into choosing how to implement this pattern. This decision takes many considerations into account that impacts the way system is built.

Advantages:

· Scalability

· Extensibility

· Ease of Deployment

· Ease of Maintenance

· Optimization

· Reusability

· Fault Tolerance

Limitations:

· Difficulty of Development

· Difficulty of Testing

· High Latency

· Monitoring

· Transactions