Microservices have grown in the API space for several years and offer developers many benefits. These services do only one thing, so they are generally easy to manage and have little coverage. Hence the name!
But one of the biggest advantages of microservices also contributes to one of their biggest disadvantages; Managing a large number of these services can be complicated and time consuming. This is where the service network comes in.
When we enter the service network below, we will see that it has a lot in common with SOA. As Jeff Foster notes in a blog post on the subject, «SOA had similar ideas in the ’90s, but the technology around it was cumbersome … it seemed to involve a lot of XML, never a good start!»
Is the service network just another iteration of the ideas behind SOA or is it something more than that? Let’s find out.
Differences between Service Mesh (MSA) and SOA
Service networks are more closely associated with the management of microservices, in order to allow better management of the many different microservices that make up an application or service.
Using a service network involves sharing how services interact, with a data plan to manage communications between microservices and a control plan used to manage them (or rather their associated sidecar) and evaluate their performance.
At first glance, this configuration seems to have much in common with service-oriented architecture (SOA) and Enterprise Service Bus, which is often associated with them for inter-functional communication.
Before analyzing the use of a service network with SOA, let’s take a look at some of the principles of each type of architecture:
Service Oriented Architecture (SOA)
- «Share as much as possible» architecture
- The importance of reusing business functionality
- Governance and common standards
- Enterprise Service Bus (ESB) for communication
- Multiple message protocols
- The common platform for all implemented services
- Multi-threaded with more overhead to manage I / O
- Maximum reuse of the application service
- They are more likely to use traditional relational databases
- Not preferred in a DevOps model
Microservices Architecture (MSA)
- «Distribute as little as possible» architecture
- The importance given to the concept of limited context
- Relaxed governance, with more attention to the people
- Efficient collaboration and freedom in choosing platforms and technologies.
- Simple and less elaborate messaging system
- Lightweight protocols such as HTTP / REST and AMQP
- Single threaded, in general, with the use of event loop functions for non-blocking I / O manipulation
- The containers work very well in MSA and are considered perfect for a DevOps model
- More focused on decoupling
- Use modern, non-relational databases
These types of architecture have some similarities, such as the fact that reuse is as important for microservices as it is for SOA. However, we can also observe some significant differences between the principles of these two previous approaches. In this case, your application may be different.
Service Mesh (MSA) Vs. SOA
Looking at the above, you can begin to get an idea of the type of environments in which each approach might be appropriate.
For example, MSA could be used in cases where developers want to maintain a greater degree of control compared to the SOA history of providing a framework for larger applications and complicated business processes.
A post on the BMC blog on the subject suggests that “as the business grows, organizations may need capabilities such as complex demand transformation and the integration of heterogeneous systems. In such situations, organizations often use the SOA model to replace the MSA. «
In other words, SOA has (or has had) a certain share in business development. The use of the service network is facing an upward struggle to change this mentality, even if services such as Istio, Linkerd and Consul facilitate implementation.
And this implementation is one that is helped by developers who accept the agile mentality, with the desire to focus on building services and adding value to the business, rather than connecting services.
Even big names like Netflix that embrace the service network don’t hurt either …
Does Service Mesh emerge from the ashes of SOA?
It is essential to note that although we have combined the two in this article, a service network does not necessarily have to be part of the microservices architecture. Instead, you might consider using a service network as an approach to address some of the issues presented by MSA.
In SOA, using Enterprise Service Bus is essential. But, as the IBM blog puts it, “in many other organizations, BSE has come to be seen as a deadlock. Making changes or improvements to an integration could destabilize others who use the same integration. «
Despite good intentions, this means that SOA using a BSE has only one point of failure. This is not true for MSA, where microservices operate independently. This is a key point here, as it demonstrates the extent to which a service network raises some of the SOA concepts.
Using a service network provides improved visibility, making it easier to detect and diagnose problems. In addition, they can redirect requests for failed services without crashing.
There are certainly similarities between SOA and the use of a service network. However, it would be a disadvantage to suggest that the latter is somewhat smaller than a much more capable v2 of the former. In fact, in most cases, the service network is far beyond SOA.