Microservices Architectures: Microservices vs. SOA

Microservices architectures are very popular today. In this article, we take a look at how microservices architectures are different from Service Oriented Architectures (SOA).

Introduction to Cloud and Microservices: Challenges and Advantages

This is the last article in a series of five articles on cloud and microservices. The previous four can be found here:

1. Microservices and a Quick Introduction to Cloud: Why, What, and How

2. Microservices Architecture: Introduction to Spring Cloud

3. Microservices Architecture: Advantages of Microservices

4. Microservices Architecture: Challenges of Building Microservices

Deployability

Both microservices and Service Oriented Architectures primarily talk about creating small services.

Whenever we talk about microservices, we refer to small sized services that are also independently deployable.

For example, we should be able to release Microservice1 without affecting the behavior of any of the other microservices. We would be able to take such a microservice to production very quickly.

The focus of SOA might be on creating independent services, but not exactly independently deployable ones. In SOA, while we focused on an API, the deployable units were generally large.

Thin Pipes vs. Enterprise Service Bus

With the evolution of its architectures, SOA ended up having large Enterprise Service Buses (ESBs). ESBs were introduced to enable loose coupling between SOA components.

In order to implement a new feature in an application, changes are needed both on the application logic and in the enterprise bus.

The enterprise service bus become a central spoke where a lot of business logic also made its way. Over a period of time, these sucked in a lot of business logic, making the application difficult to maintain.

Microservices architectures keep a minimum amount of logic in their communication infrastructure — thin pipes.

Tied to XML

SOA was tied to the XML technologies, inheriting its formalities and complexities.

Governance

With SOA, there is always a centralized architecture team that decides what logic goes into an ESB, and what cannot, among other things.

On the other hand, microservices architectures focuses on having decentralized governance.

Let's Look at an Example

Consider a banking application. Along with a savings account, a customer gets a debit card for free. An Insurance Savings Account and a Debit Card are different banking products, managed by different product systems.

SOA

In the SOA architecture, the ESB takes the order from the selling application, and handles the communication with the systems that create the appropriate products.

The ESB ends up having a lot of business logic, making it top-heavy.

Microservices

Typical microservices architecture makes use of an event driven architecture. It makes extensive use of a message queue to ensure reliable communication between different microservices, each having their own responsibilities.

The sales app would create an order event, and put it in the queue. Each of the other services would look at the event, and process it if it was relevant to them.

Summary

In this article, we looked at the differences betwee a microservices architecture and SOA. We looked at independent deployability, de-centralized governance, and the event based nature of microservices architectures.