What is Service-oriented architecture (SOA)?

Service-oriented architecture (SOA) debuted in the 1990s. Its goal was to address the problem of ever-growing codebases and complex systems. The idea was to break these up into components that would deal with specific business objectives. Focused on the enterprise level, SOA is based on the concept of reusing software and code to avoid waste.

What are microservices?

Microservices architecture can, at first glance, seem very similar to SOA. It also has the goal of breaking up monolithic applications into components. A core difference is that microservices do not need to fulfill enterprise-wide requirements. Each microservice does what it does and does it well, without worrying about how it fits into the bigger picture.

Read about how to convert a monolith to microservices in this article.

What are the advantages of microservices architecture over SOA?

Microservices architecture in some ways evolved from SOA, or at least was able to learn from the mistakes made, and benefit from new practices and technology, including agile approaches to software development.

Microservices are faster, more robust and reliable, easier to deploy and scale, and just plain leaner than any SOA. Teams are small and independent and there is a refreshing lack of interdependencies that lives up to the initial dream of SOA and takes it to a new level.

Read on for six reasons why the microservices of today are nothing like the SOA of yesterday.

6 big differences between SOA and microservices

1. Communication

How SOA and microservices architecture communicate is one of the starkest illustrations of the differences between them. Each service in SOA must use the enterprise service bus (ESB) to communicate with other services. This should standardize and simplify communications with a single, centrally managed system. But it also means that the ESB acts as a bottleneck to development, with updates and integrations for components ending up queued. Microservices instead use an API layer, an approach that relies on simpler, and quicker, exchanges of information between separate components.

2. Granularity

The services in SOAs can be big or they can be small. They can even be massive and shared across the entire enterprise. SOAs were never designed to be as small as possible, so the services used can be considered coarse-grained in terms of granularity. Both the scope and size of the service can be vast, with shared databases, and multiple interdependencies. On the contrary, microservices are designed to be highly focused and fine-grained. Small teams, faster onboarding for new hires, fewer potential points of failure.

3. Coupling and cohesion

When you have small, specialized services, you can afford to have low coupling and high cohesion. Each microservice is based on the idea of “bounded context”, in other words, it is self-contained, with as little sharing of components, data, or interdependencies as possible.  This results in high cohesion, which means that the origin of problems can be rapidly identified as arising from a specific microservice. This component can then be isolated and fixed. In SOAs, despite the stated goal of loose coupling, the sharing ethos proves to be a vulnerability. Not only can there be an impact on speed, but faults can be harder to trace and fix.

4. Reuse

Reuse of components is built into the philosophy behind SOA, with shared services prioritized in importance over highly specialized implementations. Because of the enterprise-level focus of SOA, sharing is evaluated as reducing waste, saving time and money. Unfortunately, this misses out on a big part of the whole picture, where sharing also creates vulnerable interdependencies and slows down development. Microservices take into account that it is usually better to work with smaller components and keep everything separate. If you reuse something designed for another purpose, not only will you be dependent on its development schedule, your component will fail when it fails. If microservices need to reuse code, the preference is to duplicate it and disconnect its development from the original.

5. Data duplication and storage

Building on the concept of reuse, SOA usually prefers to share data. This extends to the sharing of databases between components. All services must access and change data that is effectively stored in a central source. This reduces the need to duplicate data, but it can result in speed problems and inevitably leads to interdependencies between services, as there must be agreed-upon protocols for how the data is stored and accessed. In contrast, microservices use whatever data storage is best suited to the task and aren’t shy about duplicating data whenever necessary. While this can add complexity in terms of data management and keeping everything up to date, the speed boosts of having local or exclusive access to data mean that microservices again win out over SOA.

6. Deployment

The focus on keeping microservices separate and small means that the teams can be smaller. These independent teams can work at differing paces and deploy their modules without worrying about the deployment schedules of other teams. They can even progress to continuous deployment, with the feature and bugfix pipelines reaching the end-user much faster than ever before. SOAs, on the other hand, suffer from the kind of deployment issues that plague monolithic systems. If you add or change a service, the entire application needs to be redeployed.

Are microservices a subset of SOA?

Both service-oriented architecture and microservices deal with the concept of converting monoliths into discrete modules. SOA came first, so it might seem natural to think of microservices as a subset of its predecessor. But SOA was designed to enable different applications of varying sizes to communicate, whereas microservices come together to form a network of small modules that can be considered an application. SOA is in some ways still stuck in the mindset of the monolithic era, with coarse-grained, big services that are designed to share a lot of functionality. Microservices are leaner, more independent, and fine-grained. One way to think of the relationship between the two is that microservices architecture learned from the shortcomings of SOA and managed to deliver the promise of truly breaking apart monolithic applications.

How Blocshop can make microservices work for you

Blocshop has been breaking monoliths into microservices since the software architectural style got its name in 2012. We know our microservices and we can walk you through the process of deciding how to make them work for you. Contact us today for a project estimate or even if you just need something explained.

Free ebook: From monolith to microservices