SOA vs microservices: going beyond the monolith

Current software development increasingly relies on distributed, service-based architectural patterns to achieve scalability, reliability, and rapid build, test, and release cycles. Two of the most popular service-based approaches are service-oriented architecture (SOA) and microservices. In this article, we will describe the ways these methods are alike and how they are different. We will also explore some use cases for each.

SOA is an older method and may not work well for some modern cloud-native applications. But it still offers a number of benefits that make it a great choice in many different scenarios. Understanding which features of SOA are valid and which parts are out-of-date will help you choose between SOA and microservices for your next service-based application.

Let’s start by getting a feel for what SOA really is.

What is SOA?

Global research and advisory firm Gartner originally coined the term “service-oriented architecture” in the mid-1990s. The Organization for the Advancement of Structured Information Standards (OASIS)—the IT industry standards committee—defines SOA as “A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”

SOA is a way to build a backend that can scale in development—in other words, one that can quickly ramp up new developers and additional features. Note that SOA is an architecture style, not a specific implementation. In this architecture style, everything centers around services (hence the name). Here, a service is a functional representation of a business domain.

Typically, services communicate via a service bus, and a service repository identifies them. Consequently, services integrate in a loosely coupled fashion, only available online. A contract must fix a communication API. This contract establishes a specified interface to trigger business logic or access data. So, it uses some standardized messaging protocols, which are usually much more complicated than simple REST.

Since the communication is via the service bus, it locates the recipient when demanded—or not. In theory, this allows request queuing and asynchronous workload execution. But most protocols are synchronous here, which means that even an asynchronous workload requires an immediate response.

Every service should be isolated enough so that a developer can work on it independently. However, since SOA is all about reuse, a service may share or reuse even elementary components, such as data stores. There is no framework or programming language requirement for a service. This way, platform access and development are universally possible.

What are microservices?

Microservices architecture is another approach to backend systems. The UNIX operating system paradigm—“Do one thing, and do it well”—guides this architecture.

In fact, microservices are all about modularizing and decoupling backend capabilities. Instead of creating one large service, small teams of developers create and publish smaller entities.

While Netflix popularized the microservices approach in the late 2000s, many others played with the pattern beforehand. Indeed, its origins trace back to 2004 and share strong similarities with SOA. That’s potentially why developers first described the microservices approach as “fine-grained SOA.”

Its heavy reliance on DevOps sets microservices apart. In an ideal microservice implementation, the whole source of truth lies in code–—from development to deployment to runtime orchestration. Therefore, any microservice should be as stand-alone as possible, providing its own data store and communication protocol. It should also be as lightweight as possible; DevOps tends to use simple HTTP with REST.

Although microservices aim to be lightweight, they are still complex and resource hungry. Giving each team their own service world leads to duplication and orchestration overhead. As a result, the complexity shifts from alignment for building one giant application to orchestration for these small-scale services.

While DevOps engineers still heavily discuss the right microservice size, we can always go back to the SOA definition of fundamentally representing a business domain or subdomain. Nevertheless, while SOA maximizes reuse, microservices try to be clean about the bounded context, which eventually results in (wanted) duplication.

What problems do service-based and microservice architectures solve?

Although quite similar on the outside, SOA and microservices differ in many ways. The fundamental difference lies in the shared code and responsibilities. While SOA tries to bring shared components to mutual services and reuse as much as possible, microservices share as little as possible.

A complete microservice may have its own logging system, authentication handling, and other purely technical functions. Meanwhile, SOA would certainly place these common aspects into a dedicated service to share as much as possible.

SOA tackles a common problem in large enterprise applications, where companies need to bring a set of existing applications (or services) under one umbrella. They quite often use words such as “enterprise service bus” or “service repository pattern.” It’s no surprise that SOA contains elements such as a service repository and a service bus.

On the other hand, the microservice approach was developed for the cloud-native era, where individual services are exposed both internally and externally. The setup often combines third-party services, an orchestration platform, and custom services all in the cloud.

Microservices provide less formal API guidance and specifications than SOA. As mentioned, DevOps teams usually implement microservices APIs using HTTP and RESTful principles, but that is by no means cut in stone. Also, microservices do not require components such as an API gateway–—ideally, API gateways are not used at all. The SOA paradigm requires a central service to access the individual services.

Looking beyond sharing, we find that both approaches also interpret the service entity differently. A service is critical to structure a single application in the microservice context, while SOA uses services to integrate multiple applications.

SOA vs microservices: which approach should you use?

These days, it’s relatively uncommon to see new SOA projects. The reason is simple: too many constraints and too little knowledge. Most developers are either more familiar with the microservice approach or favor some of the freedoms it offers.

So, the question is, when should you use SOA? SOA is an excellent alternative if you’re building a platform that should (and will always) work as one but requires strong feature scaling and adherence to predefined business domains. Under these considerations, SOA is an ideal candidate for large-scale enterprise platforms that include many different applications and services.

If you strive for individual service independence, then the microservice approach is the better alternative. This approach leaves pretty much all specific choices up to the service. This way, each team can be fully autonomous and have complete control from coding up to deployment and runtime behavior.

It should be no surprise that SOA was born out of established enterprise operations. Even today, SOA still provides many aspects that larger backend platform demands. The architecture handles data consistency and governance, giving the company complete central control over the platform. In contrast, a true microservice platform has many individual owners, and it cannot be controlled from a single place.

Conclusion

If you’ve ever built a microservice-based backend, you have potentially already encountered some challenges that SOA can address for you. On the other hand, SOA does have its own share of complexities and constraints. After all, there is a reason why people jumped onto the microservices bandwagon so quickly.

Knowing the differences between SOA and microservices is key to choosing the correct architecture for a given problem. While monoliths still have their place for many purposes, don’t neglect the distributed development aspects of SOA and derived architecture patterns like microservices.

The problem alone should determine which approach you pick, not current trends. Choose the architecture pattern that fits the given situation and available resources, and your project will be right on track. Rega