What is a service network

Good morning everybody!

Today we are pleased to offer you a translation of an article that briefly talks about a new technological trend called “Service mesh”. The most interesting solution in this area (in our opinion) is Istio , but the proposed article is interesting, first of all, by express comparison of existing technologies of this kind and a high-level overview of the entire paradigm. The author, Tobias Kunze, also wrote a second, more practically oriented article on the service mesh - a request to express whether it is worth publishing its translation.



This post is the first of two that discusses the advantages of service networks. This article describes what a service network is, how it works, and what is the use of it. In the second partit was investigated why, where and when to use such networks, and what lies ahead.

When decomposing an application into microservices, it quickly becomes clear that calling a service over the network is a much more complex and less reliable process than was first thought. What was supposed to “just work” by design now has to be clearly articulated for each client and each service. Clients have to discover service terminals, ensure that they are consistent across API versions, and package and unpack messages. Customers also need to track the execution of calls and manage such operations, catching errors, repeating failed calls and keeping a timeout if necessary. Clients may also need to verify the authenticity of services, log calls and instrument transactions. Finally, it happens that the entire application must comply with IAM rules, encryption or access control requirements.

Of course, most of these problems are not new, and for a long time we have at our disposal technologies that help organize messaging mechanisms, for example, SOAP, Apache Thrift and gRPC. But what has been observed recently: the rapid distribution of containers and the accompanying explosive growth of service calls, the degree of horizontal scaling and the short duration of service terminals associated with it. When complexity and fragility reach a new level, there is a desire to encapsulate network communication and take it to a new infrastructure level. The most popular approach to providing this level, applied today, is called the “service network”.

What exactly is a “service network”?

A service network is not a “service grid”. This is a network of API intermediaries (proxies) to which (micro) services can connect to completely abstract the network. As William Morgan put it , this is “a dedicated infrastructure layer that provides secure, fast and reliable communication between services.” Service networks help to cope with the many challenges that developers face when they have to exchange information with remote terminals. However, it should be noted that major operational problems with the help of service networks are not resolved.

How do service networks work?

Typical service network architecture. Proxies in the data plane are deployed as companions (sidecar), and the control plane is located separately.

In a typical service network, deployed services are modified so that each of them is accompanied by its own proxy “companion” . Services do not directly call other services over the network, but instead turn to their local proxy companions, who, in turn, encapsulate the complexity of exchanging information between services. Such an interconnected set of proxies implements the so-called data plane.

On the contrary, the set of APIs and tools used to control proxy behavior throughout the entire service network is called its “control plane”. It is in the control plane that users set policies and configure the data plane as a whole.
To implement a service network, both a data plane and a control plane are needed.

Major players: Envoy, Linkerd, Istio and Consul

Envoy is an open source proxy server developed by Lyft. Today it forms a data plane in many service networks, including Istio. Envoy quickly superseded other proxies thanks to its convenient configuration API, which allows control planes to adjust its behavior in real time.



Linkerd is an open source project supported by Buoyant and, at the same time, the very first service network. It was originally written in Scala, like Finagle , from Twitter, from which it came from, and then merged with the lightweight Conduit project and was restarted as Linkerd 2.0 .



Isstio- Perhaps the most popular service network of our time. It was jointly launched by Google, IBM and Lyft; she is expected to eventually enter the Cloud-Native Computing Foundation (CNCF) project. Strictly speaking, Istio is a control plane and, in order to form a service network, it must be combined with the data plane. Istio is typically used with Envoy and works best on Kubernetes.



Consul is a relatively new phenomenon in the ecosystem of control planes. It works best with topologies spanning many data centers and specializes in service discovery. Consul works with many data planes, and can be used without involving other control planes, for example, without Istio. His support is HashiCorp.

Main advantages and differences in priorities

Although the space of service networks continues to evolve, most of the projects, apparently, have already come to the idea of ​​the main set of features that should be supported in such a network:

• Service Discovery : discovering services and maintaining their registry
• Routing : smart load balancing and network routing, better performance testing, automatic deployment patterns, such as blue-green and canary configurations
• Stability : retries, timeouts, and circuit breakers
• Security : TLS-based encryption, including key management
• Telemetry : collecting metrics and tracking identifiers

In addition to these capabilities (and sometimes based on them), there is a richer level of functions at which serious differences begin between different service networks about what may be valuable for architects, developers and administrators of microservice systems. For example, Envoy supports WebSockets, but Linkerd 2.0 (not yet). While Istio and Consul support different data planes, Linkerd only works with its own. Consul has its own built-in data plane, which can be replaced with a more powerful one when the issue of performance becomes a priority. Istio is designed as a separate centralized control plane, while Consul and Linkerd are fully distributed. Finally, Of all the service networks discussed above, only Istio supports fault injection. These are just some of the key differences to consider if you are considering introducing such a network.

Service Network Criticism

Despite the obvious popularity and promising attractive features, service networks are not so widely used as might be expected. Undoubtedly, this is partly due to their novelty and the fact that this entire industry continues to take shape. But, talking about service networks, you can not do without some criticism.

The skepticism associated with service networks primarily relates to the additional complexity that they bring, their relatively poor performance and certain gaps that appear when working with topologies from multiple clusters.

Service networks are ambiguous platforms, at the initial stage of implementation of which serious investments are required in the assembly of the system itself and its instrumental equipment. It may seem that adding a companion to the container is quite easy, however, competent failure handling and retrying requires serious engineering efforts. It can be difficult to justify such investments when working with existing applications with a short life cycle, or with rapidly developing applications.

In addition, service networks can seriously degrade application performance compared to using direct network calls. The problems that arise in this case are sometimes difficult to diagnose, and even more so to eliminate. Since most service networks are aimed at working with self-contained microservice applications, and not at whole landscapes of related applications, such networks usually have poorly implemented support for solutions for many clusters and different regions.

In short, service networks are not a panacea for architects and operators seeking to adapt flexibly to operating a growing fleet of digital services. Such a network is a tactical solution; it represents a “fundamental” technical improvement designed to solve problems that are relevant, primarily for developers. At the business level, they will not reverse the situation.

Related technology

Service networks intersect with other architectural components, but, of course, are not reducible to them. These elements include APIs, application gateways, load balancers, inbound and outbound traffic controllers (ingress and egress), or application delivery gateways. The main purpose of the API gateway is to provide services with access to the outside world, while acting as a single API to provide load balancing, security and basic management functions. Inbound and outbound traffic controllers transmit information between non-routable addresses in the container orchestra and routed addresses outside it. Finally, application delivery controllers are similar to API gateways, but their specialization is in accelerating the delivery of web applications, not just the API.