SOA vs Microservices: What's the Difference?

Those who work in IT are probably familiar with the debate between service-oriented architecture (SOA) and microservices. This has particularly become more prominent in recent times with the wide adoption of agile methodologies. 

To a large extent, these two approaches easily appear similar on the surface, and yes they are to some extent. But they are also dissimilar across important aspects. So it’s important to understand where they are similar and where they part ways. Let’s do this. 

What is SOA?

SOA is an abbreviation for service-oriented architecture. It's a software development approach that focuses on making the most of those components that can be reused and also ensuring that other items such as scalability and security are properly met.  So the basic idea behind SOA is to design software as a collection of independent services that can be reused in different applications across the enterprise. This approach to software development makes it easier to create complex systems and to reuse components in multiple applications.

SOA has its roots in the early days of distributed computing, when companies began to develop software that could be shared among different departments and applications. However, it was not until the late 1990s that SOA began to gain mainstream attention. In 1998, IBM released WebSphere, a product that included support for SOA. This was followed by Microsoft's .NET platform, which also included built-in support for SOA. Since then, many other companies have adopted SOA, and it has become one of the most popular architectures for enterprise software.

The service interfaces in SOA are created in such a way that they can be called with negligible or zero understanding of how the integrations are executed. This is known as loose coupling. This loose coupling allows developers to reuse components across many other different applications within the enterprise. It means that access to the enterprise-wide service resource, or what is commonly known as the enterprise service bus (ESB), is shared. services can work together without depending on each other. Service independence means that changes in one service should not affect other services. The goal is to use existing services rather than creating new ones.  XML data is a central tool in SOA-based development. 

What are microservices?

Microservices are a type of software architecture that allows developers to build individual components of a larger application as separate, independent services. 

Like SOA, the microservices approach also makes use of the loose coupling concept. The components of an application are created in such a way that they are independent and reusable. Microservices use APIs to communicate, meaning their adoption or access is not enterprise-wide. Microservices are popular for cloud-native applications that operate very well in containers.  Java is the central programming language for microservices. 

Dr. Peter Rodgers is credited as having pioneered the microservices concept. He first used the term «Micro-Web-Services” during a presentation at a cloud computing conference in 2005. But the present term, microservices, took off properly around the spring of 2011 during a conference of software developers. The rest as they say is history, and today companies of all sizes including the giant tech players like Amazon, Google and Facebook now use microservices.

The key difference between SOA and microservices

The major factor that differentiates SOA and microservices is the scope. Simply put, the adoption of SOA cuts enterprise-wide while the scope of microservices is best at the application level.

This might sound like a negligible difference, but it becomes visible when you are met with incompatibilities if you try to use either in a scope that it's not suited for. Understanding this difference and how to apply it gives you the opportunity to best use both SOA and microservices in a way that they can easily complement each other. So in assessing SOA and microservices, you want to view them from the angle of compatibility.

Let’s see how these differences between SOA and microservices play out across different spheres:

Reusable components

SOA is perfect for enterprise-wide reusability. The goal is to achieve scalability and efficiency by optimizing the reuse and sharing of components throughout the enterprise.  

In microservices, the reusability is achieved through copying and duplication — not by sharing of components at the primary source. If you try to create a microservice component that is reusable at runtime, you'll end up with dependencies that will eventually compromise agility.

Synchronization

The reusable components in SOA are accessible across the entire enterprise. This is achieved through a range of synchronous protocols such as REST APIs.

This kind of synchronization cannot be achieved seamlessly in microservices without interfering with resilience.

Messaging protocols

Microservices use messaging protocols that are light, such as Java Messaging Service. SOA on the other hand uses protocols such as Microsoft Messaging Queuing and Simple Object Access Protocol which are more heterogeneous.

Data changes

In SOA, all applications can access and change data at source. But in microservices, each application needs to have a local version of any data it requires. This leads to a lot of duplications that easily cause complexities.

Development speed

The concept of sharing a common architecture means that SOA is simple to use in development and easy to troubleshoot, but this also means that it can get slow. Microservices on the other hand tends to be faster since duplication is used instead of sharing from a single point (the primary source).

Service architecture design

The service architectures in microservices are highly specialized. This means that the architecture of each service is designed to do one task and do it very well (specialization). The SOA service architectures can be specialized, yes, but the difference is that they can also do more than one thing across the enterprise.

When to use SOA vs Microservices?

SOA is great for when you have a lot of legacy systems that need to be integrated with each other. It's also good for large-scale projects, where you need to orchestrate multiple services and make sure they're all working together.

Microservices, on the other hand, are perfect for smaller projects and when you need more flexibility. They're also good for when you need to move quickly and independently, since each microservice can be developed and deployed separately.

The bottom line? SOA is perfect for big projects with a lot of moving pieces, while microservices are ideal for small projects that need to be nimble and agile.

How to implement SOA and microservices?

With SOA, you start with a central ‘nervous system’—an enterprise service bus (ESB). This is a system that acts as the middleman between all of your services, and it's responsible for routing requests and messages.

Then you need to map out your services and create bindings between them. This process can be a little tricky, but fortunately, there are a lot of tools out there to help you do it. Once everything is mapped out, it's time to start building your services.

Microservices, on the other hand, don't require an ESB. Instead, each service has its own independent infrastructure. This makes them more scalable and easier to manage, but it also requires more planning and coordination.

Since microservices are self-contained, you don't need to worry about compatibility issues between different services. However, you do need to make sure that each service can handle the load on its own.

Conclusion

Think about it this way: SOA is like the engine of a car, while microservices are like the headlights, the brakes, and all the other little parts that make it run. SOA provides the large-scale structure and organization, while microservices give you the flexibility to adapt as needed. These are the core elements you need to look at when trying to figure out where to use SOA and where to use microservices.