Hello and welcome back! Today, we’ll be talking about the difference between SOA and microservice architecture.

Both SOA and microservice architecture splits a system into smaller, cohesive, independent services. By service here we basically mean a process. These processes can live on the same machine, and sometimes some of them do, but a lot of them live in separate but networked machines.

So if they both split a system into small, cohesive, independent processes, what’s the freakin difference?

To be honest, there is a lot of disagreement on the definition of these two architectures as well as their differences.

Some people believe that microservice architecture is really just an implementation, a particular realization of SOA (wikipedia seems to think this).

Some people believe that there is a difference. That SOA splits components into bigger chunks, bigger services than microservice. Additionally, that SOA services typically communicate over a centralized bus, while microservices directly communicate with one another over network protocols such as HTTP/REST.

You can imagine, that if all services communicate over a centralized bus, you have a single point of failure. However, if all services communicate with each other, they all depend on one another, and we all know from software engineering 101 that “dependencies bad”.1

Another commonly stated difference is that SOA focuses on “enterprise” services, that are often reused by multiple apps of an organization, while microservices are more focused on the needs of a single app. In my humble opinion, this is kind of a wishy-washy difference, so I’d ignore it haha, but just know you’ll hear it in the wild.

In my humble opinion, the main, the most important, the difference that stands out the most is really the communication between services. SOA uses a centralized bus, while microservices directly communicate with one another. Each has its advantage.

Short and sweet, that’s all for today! See you next time!

  1. If you need a quick reminder of why dependencies bad, consider what happens when your boss/stakeholder asks you to change a particular aspect of the app, and the coded representation of that aspect has 20 things depending on it. You’re gonna have a bad time man. ↩