“The Microservice Architecture is the anarchists’ answer to the monopolization of integration.”
The key ingredient of Microservices Architecture (MsA) is not just the smaller-than-SOA-services, but the decentralization and simplification of the development of these services.
In an MsA, different teams are encouraged to develop simpler services, to release them quickly and to release them often. This is hard to accomplish using SOA where services are rarely completely loosely coupled and often part of a Mikado-style web of services.
Microservice architecture vs. Service Oriented Architecture
As mentioned in other posts on Microservices Architecture, the focus of these Microservices is on business capabilities rather than technical capabilities. This means that the entire stack of components underlying these Microservices is managed within one team of experts. This gives more autonomy to the teams that develop these services. Decentral governance of service development sometimes proves difficult to adopt in organizations as it could clash with existing culture. However, these differences are never insurmountable. The autonomy of the team reduces the need to have agreements and formal specifications between the database, middleware, business logic and UI. This is an ‘internal’ advantage of MsA over traditional SOA. Which may have its effects on ‘the outside’ as well.
“A proper Microservice is ‘designed for failure’ “
As indicated in our earlier posts, a proper Microservice is ‘designed for failure’ and offers a service independent of other services. This may seem impossible as services inevitably dependent on other services. However, the idea behind this concept is that services do not require other services to be available all the time. They are designed to be resilient to failures and will simply create a backlog of work for those services that were temporarily unavailable. This way services can be designed to be independent of each other operationally.
Technically a service interface still needs to be defined and this will result in dependencies as well. Other services from other teams of experts will rely on these Microservice interfaces. Although there is no final answer to this dependency problem, MsA offers some interesting solutions which it borrows from RESTful Architecture and HTTP such as HATEOAS and ETags.
Caching options
Due to the small size of Microservices, the information is very suitable for caching. Combine this with -again- entity-tags, a concept from the HTTP protocol, and efficient client-side caching is possible. This is a tremendous simplification of infrastructure compared to centralized caching solutions.
How come we didn’t think of this before?
With all the hype surrounding the Microservices Architecture it may seem that there are no advantages left to SOA at all.
Why did we even do SOA and ESB in the first place?
There are still some significant advantages that SOA holds over MsA and which are harder to address in a MsA. A typical SOA on an ESB provides much greater control over what is disclosed and how it is disclosed by enforcing service policies on the boundaries. Regularly an organization deploys adapters to integrate existing systems with the Service Bus. These adapters sport a framework that is supportive of the policy enforcement. Given the decentral nature of MsA this would be harder to implement and enforce from within the organization.
Other common SOA components that (almost always) come out of the box are monitoring, logging, error handling and integration. Again, MsA has a bigger challenge addressing these points. Another advantage, which is at the same time a disadvantage of SOA, is the ability to develop standardized messages which greatly enhances integration and orchestration efforts. This blessing in disguise comes with its dark side: rigidity. A typical SOA-service is notoriously hard to modify just because of this standardized message model and its integration dependencies.
Now what do we do?
The advantages of Microservice Architecture over Service Oriented Architecture are clear, however they may not always fit the goals of the organization. To decide whether a SOA or MsA is a better fit, one should look at the needs of the organization, the results the organization wishes to achieve, the cultural fit and the existing competencies that are available or need to be attracted. Of course we are always willing to help bring your ambitions to life!
More about Microservices
Check out our previous blogposts:
