Microservices have been on the rise in the API space for several years and offer developers plenty of advantages. These services do just one thing, so they’re generally easy to manage and are small in scope. Hence the name!

But one of the biggest advantages of microservices also contributes to one of their biggest disadvantages; managing large numbers of these services can be fiddly and time-consuming at scale. That’s where the service mesh comes in.

When we dig into service mesh below, we’ll see that it has a lot in common with SOA. As Jeff Foster points out in a blog post on the topic, “SOA had similar ideas in the 90s but the technology around it was clunky…it seemed to involve an awful lot of XML — never a good start!”

Is service mesh merely another iteration of the ideas behind SOA, or does it represent something more than that? Let’s find out.

Differences Between Service Mesh (MSA) and SOA

Service meshes are most associated with the management of microservices, with their aim being to better enable the management of many different microservices that make up an app or service.

Using a service mesh involves splitting up how services interact, with a data plane to manage communications between microservices and a control plane that’s used to manage them (or rather the sidecar associated with them) and assess their performance.

At first glance, that setup seems to have a lot in common with service-oriented architecture (SOA) and the Enterprise Service Bus often associated with them for inter-functionality communication.

Before we get any deeper into comparing the use of a service mesh with SOA, let’s take a look at some of the tenets of each type of architecture:

Service-Oriented Architecture (SOA)

• “Share as much as possible” architecture
• Importance on business functionality reuse
• Common governance and standards
• Enterprise Service Bus (ESB) for communication
• Multiple message protocols
• Common platform for all services deployed to it
• Multi-threaded with more overheads to handle I/O
• Maximum application service reusability
• More likely to use traditional relational databases
• Not preferred in a DevOps model

Microservices Architecture (MSA)

• “Share as little as possible” architecture
• Importance placed on the concept of bounded context
• Relaxed governance, with more focus on people
• Efficient collaboration and freedom in choosing platform and technologies
• Simple, less elaborate messaging system
• Lightweight protocols such as HTTP/REST and AMQP
• Single-threaded usually with the use of Event Loop features for non-locking I/O handling
• Containers work very well in MSA and are considered perfect for a DevOps model
• More focused on decoupling
• Uses modern, non-relational databases

These types of architecture do have some similarities, like the fact that reusability is just as important for microservices as it is for SOA. However, we can also see some significant differences between the tenets of these two approaches above. With that being the case, their application is likely to be different as well.

Applications of Service Mesh (MSA) vs. SOA

Looking at the above, you can start to get a feel for the type of environments in which each approach might be suitable.

For example, MSA might be used in cases where developers want to retain a greater degree of control vs. SOA’s history of providing a framework for larger applications and complicated business processes.

A BMC blog post on the subject suggests that “as the business grows, organizations may require capabilities such as complex request transformation and heterogeneous systems integration. In such situations, organizations often turn to the SOA pattern to replace MSA.”

In other words, SOA carries (or carried) a certain weight in enterprise development. The use of service mesh faces an uphill battle to change that mindset, even if services like Istio, Linkerd, and Consul are facilitating its implementation.

And that implementation is one that’s being helped along by developers who embrace the agile mindset, with a desire to focus on building services and adding value to the business rather than connecting services.

Big names like Netflix adopting service mesh doesn’t hurt either…

From the Ashes of SOA, Rises Service Mesh?

It’s key to note that, although we’ve conflated the two in this article, a service mesh doesn’t necessarily have to be part of microservices architecture. Instead, you can think of using a service mesh as one approach to dealing with some of the issues presented by MSA.

In SOA, the use of an Enterprise Service Bus is essential. But, as the IBM blog states, “in many other organizations the ESB came to be seen as the bottleneck. Making changes or enhancements to one integration could destabilize others who used that same integration.”

Despite the good intentions, that means SOA using an ESB has a single point of failure. That’s not true of MSA, in which microservices operate independently. That’s a key point here because it demonstrates the extent to which a service mesh elevates some of the concepts of SOA.

Using a service mesh offers enhanced visibility, making it easier to spot and diagnose problems. Plus, they can reroute requests away from failed services without bringing the whole thing down.

There are certainly similarities between SOA and using a service mesh. However, it would be a disservice to suggest that the latter is anything less than a much more capable v2 of the former. In fact, in most cases, service mesh stands head and shoulders above SOA.