Let’s discuss fashionable word Microservices and clarify the differentiation point from the widely accepted SOA architecture. Nowadays, many people are talking about both approaches in tech forums. What is the difference? Which one is better? Let’s take a closer look at the details.
Service Oriented Architecture
In the Service Oriented Architecture (SOA), the system components work as the black boxes and provide services to each other via Enterprise Service Bus (ESB)– the key component of SOA. The components communicate by messages, a communication protocol of ESB. There are compromises sometimes, so one may find directly connected services, or cascade connections to the ESB. The ESB itself may also vary – there are many ESB products available on the market nowadays. Things like RESTful or Thrift API are mostly used for external access, for example, connecting presentation layer to the web GUI, mobile apps or external systems access – small functions, such as validating an order, activating an account etc.
SOA also presumes 2 component roles: a service provider and a consumer. So application developers would build the set of services, that consumes would call for data or function. A software component may also play both roles and there may be more levels. The following figure displays simplified SOA architecture:
Figure 1: SOA architecture
As discussed above,Enterprise Service Bus (ESB) is the commonly accepted style of the integration architecture for p2p connections between providers and consumers. The other key point in SOA is that the data storage is shared between the SOA services.
Microservices is a software architecture principle, that assumes the system composition of smaller independent black-box modules, communicating with each other, using language-agnostic APIs. Microservices are truly independent as they also feature independent databases and can be independently shut down without an impact on the other services, if not used by the rest of the system. The following figure shows a quick view of a Microservices architecture.
Figure 2: Microservices architecture
Each service is technically independent in development, deployment, runtime and maintenance. Of course, as the services of the system use each other, shutdown of a microservice may result in operational disruptions (like, for example, authentication service, used by most of the other modules of a system). Moreover, a “micro” is highly relative term, which points to the idea of breaking the system in pieces as small as possible. In practice, microservices may contain quite large amounts of code and be developed by significant groups of software engineers.
Microservices vs SOA
So what are the pros and cons of both architecture principles, and which one is better? Well, first of all, both are service-oriented, but terminology-wise, Microservices is a subset of SOA with a little bit strict separation of services.
As it is visible from the above discussion, both principles are based on the object-orientation and service-orientation ideas, which is good for scalability and investment protection. So unlike a monolith architecture, service-oriented systems feature independent parts and split in black boxes with certain functions. Both architecture patterns actually aroused as direct consequence of the recent decade’s progress in hardware, that is processing transactions faster, therefore opening doors for more structured approach in system design and programming.
One of the key benefits of service-oriented architecture types is investment protection through independence on technology stacks. The “black boxes” may work for years and the new black boxes may appear side by side, developed in totally different technology stack later on. Theoretically, both SOA and Microservices allow different technology stacks for different services, but in practice, Microservices are better equipped for that. As opposed to SOA, each microservice is supplied with separate API and communication between services is going through the web services. While SOA services are communicating via ESB with it’s messaging standard, thus dependent on it’s technology. In addition to that, enterprise normally needs pretty expensive integration specialist, that knows ESB and bus messaging, to support and maintain ESB in production.
Shared data in SOA naturally work faster and let the services re-use the same data, improving overall efficiency. On the other side, it is a limitation, that compromises SOA service independence. Separate databases is also a game changer from the software engineering standpoint – microservices can be developed and deployed by isolated groups of developers with clearly set constraints and conditions of engineering task, while it is better to work in more integrated group on a SOA project, taking care of the common language of communication via ESB.
Coming back to ESB, it is also a single point of failure in SOA – if one of the services slow down, ESB may get clogged up with requests and eventually crash. Microservices don’t have this weakness from the architecture PoV, but of course, if there is a globally demanded service in the system, like authentication for example, it must be also up and running to keep the things work in microservices world.
In both architectures, developers must deal with the complexity of architecture and a distributed system. Quality Assurance is more challenging, as developers have to mock the communication mechanism in tests. In large enough systems, deployment and operational complexity are valid concerns for both architecture types.