Characteristics of Microservices
Can we see Microservices really as the new SOA? Might it be the replacement of SOA? I am sure that both statements are not correct. Microservices specialize the SOA paradigm and should be well considered as any other architectural pattern. In the first of a series of articles I want to explore this and establish where we can use this paradigm to our benefits.
The definition of a service is “a component that is running in its own process/runtime”. It communicates with other services through inter process communication facilities like rest or messages. What is the difference between the standard application architecture and applying a Microservice style? Looking carefully will show that the application components are extracted into autonomous services. When combining these services the functionality application is being exposed.
Within a SOA the Microservices style advocates to keep the endpoints smart and isolate all business logic in there, meaning all logic! The ESB should merely be responsible for routing and piping the message to its correct service. Although this makes very much sense it does not come to me as a revelation but more as a obvious choice. Putting on my architect hat I would never advocate putting business logic in the ESB. This doesn’t make any sense from a responsibility point of view nothing new.
Within a Microservice the data management should be decentralized. This means that the service is responsible for its own data. The data may only be exposed through the API of the service. This model was already used by my colleagues about 20 years ago and is also nothing new. However it is a fundamental choice if you implement this constraint in your services or system. Mainly because you will always need to go through inter process communication for retrieval of certain data, which can have performance issues, when the services are not properly designed or when you work with legacy application silos.
The notion to keep data encapsulated in its component is off course one of the core object oriented principles and will provide you also advantages in terms of functional stability and data integrity. One of the large advantages of this principle is that you will have the freedom to use a specific and tailored data storage solution per Microservice. For example using a NoSQL in one service while others use a traditional relational database. This also prevents the anti pattern of integration through the database, which in enterprise environments can cause cascading issues through architectural layers.
The concept of decentralized data management is taken even further in the usage of tools, according to Martin Fowler could also be picked by the team which manages the Microservice. This is I think a big caveat and could cause an architectural chaos if this is not properly managed. Think about potential license costs or exotic tools which suddenly create a dependency on maintaining and operating a certain Microservice in your landscape. Governance of this will be complex and cumbersome and I doubt if such freedom really pays of with the potential overhead it could introduce.
Design for failure
Design for failure is one of the characteristics that is part of Microservices. This is basically saying design your system in such a way that failing or unavailable services will not break your system. Given that each Microservices is exposed through a remote protocol this is often easier said than done however applying proper patterns will help you overcome such challenges. Monitoring tools are therefor helpful when using this architectural style but do not forget that your first line of defense is handling the failure!
A Microservice should be mapped to business capability. What we mean with this is that we analyse the business in terms of functions and capabilities and map that to the Microservice. An example would be for a insurance company to create Mircoservices like Claim, Policy, Payment. However designing the API for these services will be key in exploiting the advantages of this architectural style. I believe that in the time we where advocating this approach from a component based development perspective that this was the most challenging aspect for our clients while adopting this architectural style. The challenge is how to partition the business capabilities and the granularity of the methods on the component. Making the API to granular will result in many small functions and force the process to be implemented by the caller. Creating coarse grained API methods can counterpart this effect but then often the usage becomes complex as these methods require more sophisticated data structures to allow for flexibility and functionality.
Process of operating and developing Microservices is favored to be agile and considered a good practice to have a dedicated team on one or more services. Interesting enough I see this approach really take off. I think there are many advantages of having a team do both development and operational activities and support one or more Microservices throughout their lifecycle. Why David Sprott reacted like he did in his blog did not make much sense to me. I think a process drives technology, development and the software lifecycle and that all these elements are essentials parts in making it a success.
Wrapping it up
I hope this article has given you some overview of the characteristics of a Microservice. Although the topic of Microservice is extensive it is something you will need to consider or at least be aware of as a architect and or system designer. Some people really see this as the new way of creating distributing systems other will say its just Component Based Development or Service Oriented Architecture renamed. I will explore these areas more in other articles on this subject.