There has been a lot of discussion going on in the internet on Service Oriented Architecture (SOA) and Microservices lately. There were a lot of debates as to what makes them different from one another, and which one is better among the two. There were many valid arguments from both sides.
While some consider Microservices as the future of architectural style, many others still prefer SOA. Let’s get an idea on our contenders so we can come to a conclusion.
Microservices
Considered to be the modern day go-to architectural style for developing highly scalable applications, microservices addresses quite a lot of problems associated with large, cumbersome applications. It’s a service-based architecture with independently deployable services as the primary components.
It provides better control throughout the development, testing and implementation cycles, but has a limited service taxonomy when you consider service type classifications. It also makes use of an inter-service communication protocol (REST, JSON etc.).
SOA
SOA can defined in many different ways because this architectural style has been constantly evolving over the years. It was designed to bring order to sophisticated combinations of enterprise-level software by representing them as collections of services. SOA also uses service communication protocols. It can be considered as a superset of microservices.
It relies on a shared data model. The model will have complex relationships between numerous data structures and models, and multiple hierarchies. The tiered organizational structure of SOA facilitates service coordination and messaging functionalities.
Now that you have a basic idea, let’s get ready to rumble. For starters, let’s make this a three rounds bout.
Round 1: Services Decoupling – SOA is based on a shared data model. Therefore, you can expect it to have tight data coupling between services and other system components. This makes it quite resistant to changes. Some additional re-testing might be necessary in some instances to make sure that changes haven’t negatively affected any service.
Microservices architecture runs with a concept referred to as bounded context, which promotes an association between a single service and its data. It isn’t possible to completely eliminate sharing of services but it can be considerably minimized. Whenever sharing is required, it’s avoided by replicating common functions across services instead of using data sharing. Though this data decoupling facilitates deployments more often, it also cuts down testing scope.
Round 2: Messaging Middleware of SOA vs Microservices’ API Layer – SOA’s multi-tier model features a central messaging middleware layer. As for microservices, there is a non-coordinating API layer over the services that constitute an application.
Messaging Layer key points:
- Additional capabilities including message transformation, mediation, and routing.
- Elevated data and functional coupling degree
- Increased complexity
- Increased deployment and maintenance costs
API Layer key points:
- Simpler than messaging layer of SOA
- Easy to change granularity of services
- Easy to change internal data representations
- No modification required of the requesting application (for both changes)
Round 3: Coordination of Services – With a central hub controller, SOA maintains order in the execution of services. Microservices use inter-service communication protocols for the same.
A microservice can call another microservice whenever necessary so as to complete its function. The service that’s been called can call other services as well (a process called service chaining). Too much chaining isn’t advised and should be avoided as it indicates a degree of functional coupling with no benefits at all.
Conclusion and Verdict
Both subjects in question appeared good in the 3 rounds. However, one cannot replace the other as there are many other variables that indicate further distinctions between microservices and SOA.
While SOA can address a set of heterogeneous applications in sophisticated enterprise systems facilitating shared services across applications and functions, microservices is an optimal approach for web-based, smaller, less-complex applications. These applications do not require explicit service coordination.
Because of granularity and high independency of services, the microservices’ model finds a place with continuous deployment models of software development.
The verdict from the above arguments would slightly tilt in favor of microservices. But both of them can be highly effective depending on the context where they are used. Microservices approach can deliver agile applications that can necessarily transform into an SOA-styled architecture.
SOA, on the other hand, can apply microservices principles for better statistics in maintenance and performance.
Conclusion? Both are effective depending on the working environments. It’s a tie.
