These days there is a lot of discussion about microservices in workplace. Other architectural designs are Monoliths or Service Oriented Architecture. But as an architect when designing new system what would you do? Build microservices without giving a second thought since it’s hot in the market or sit with your tech/business team to evaluate what works best for them in the current time. For this lets first understand what these three are.
Monolithic literally means “formed of a large block/container”. A monolithic system is one big container wherein all the software components of an application are combined and packed tightly.
A Service Oriented Architecture (or SOA) is basically a group of services that communicate with each other to achieve a goal. A SOA system typically has an event bus (or messaging middleware) for components to interact. This event bus is critical as all systems communicate through it and can become a single point of failure.
Microservices (or MSA) are a collection of even small services modelled around a business domain. These are services with single purpose which is mainly business driven. Microservices typically have an API layer for communication whereas a service component in SOA communicates using messaging middleware.
On a higher level, Monolithic system are like huge mess of chunk, tightly coupled (like noodles). A small change in view might require a deployment in the whole system which could have unanticipated affects on the backend.
A SOA however is coarse grained like a pizza (looser coupling than noodles). In SOA each service component may still have multiple responsibilities. Components in SOA must still co-ordinate with each other to make the system work holistically.
A Microservices architecture however has very fine grained service components each with limited tenets or restricted responsibilities in a single domain. These are even more decoupled than SOA components, and making changes in one MSA component is typically independent of other components.
Should one build Monolith at all?
It’s probably a good idea to go with Monolith when starting out a system, if the domain requirements are simple and team size is small. But even doing so, try to modularize the code (use Modules if using Java9) so that when domain requirements become complex, the same system can be easily split up into smaller service components.
SOA vs Microservices
Below are some key differences between SOA and Microservices architecture.
|Service Oriented Architecture||Microservices|
|Service components can range in size from small to large enterprise services||Single purpose services|
|Maximizes component sharing||Minimizes sharing through bounded context|
|Has messaging middleware for communication between components||Has API layer for communication between services|
|Support multiple messaging protocols like AMQP, MSMQ and SOAP||Uses lightweight protocols such as HTTP/REST for communication|
|Heterogeneous protocols used across messaging middleware||Homogeneous protocol followed in MSA|
|Focuses on reusing services as much as possible||Focuses on decoupling service components|
Though it’s clearly visible that MSA provides more flexibility by having loose coupling, allowing CI/CD, and a homogeneous messaging protocol, it could happen that a SOA might be more suitable for a system with the requirements at hand. For example: if we know that we would have to communicate to different legacy systems with different protocols, we could chose SOA over MSA due to its common messaging middleware.
The point here is that MSA is not always the right choice, and one shouldn’t blindly go for MSA from Day1. It could cost a fortune to run those independent microservices when there is little or sparse traffic. One should rather evaluate the current domain requirements, team size and expertise before choosing one over other.