What is a service network
Good morning everybody!
Today we are pleased to offer you a translation of the article, briefly telling about the new technological trend called “Service mesh” (service network). The most interesting solution in this area (in our opinion) is Istio , but the proposed article is interesting, first of all, by an express comparison of the available technologies of this kind and a high-level overview of the entire paradigm. Author Tobias Kunze also wrote a second, more practical-oriented article on the service mesh - please ask if it is worth publishing its translation
This post is the first of two telling about the merits of service networks. This article describes what a service network is, how it works, and what is the use of it. The second part examines why, where and when such networks should be used, and what lies ahead for us.
')
When the application is decomposed into microservices, it quickly becomes clear that calling the service over the network is a much more complicated and less reliable process than it was initially thought. The fact that the plan was supposed to “just work” 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, package and unpack messages. Clients also need to track calls and manage such operations, catching errors, repeating failed calls and maintaining a timeout if necessary. More clients may need to authenticate services, log calls and instrument transactions. Finally, it happens that the entire application must comply with IAM rules, encryption requirements or access control.
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, such as SOAP, Apache Thrift, and gRPC. But what is observed recently: the rapid spread of containers and the accompanying explosive growth of service calls, the degree of horizontal scaling and the related short-term existence of service terminals. When complexity and fragility go to a new level, there is a desire to encapsulate network communication and bring it to a new infrastructure level. The most popular approach to providing this level used today is called the “service network”.
The service network is not a “grid of services”. This network is an API intermediary (proxy) 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 a multitude of calls that confront developers when they have to exchange information with remote terminals. However, it should be noted that major operational problems are not solved with the help of service networks.
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, the deployed services are modified so that each of them has its own proxy companion . Services do not call other services over the network directly, but instead refer to their local proxy companions, which in turn encapsulate the complexity of information exchange between services. Such an interconnected proxy collection implements a so-called data plane.
On the contrary, the set of APIs and tools used to control the proxy behavior within the entire service network is called its “control plane”. It is in the management plane that users define policies and configure the data plane as a whole.
To implement the service network, both a data plane and a control plane are needed.
Envoy is an open source proxy server developed by Lyft. Today it forms the data plane in many service networks, including Istio. Envoy quickly supplanted other proxy servers 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. Initially, it was written in Scala, like Finagle , from Twitter, from which it originated, and then merged with the lightweight project Conduit and was restarted as Linkerd 2.0 .
Istio is perhaps the most popular service network of our time. It was jointly launched by Google, IBM and Lyft; it 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 a data plane. Istio is usually 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 that span multiple data centers, and specializes in service discovery. Consul works with multiple data planes, and can be used without involving other control planes, for example, without Istio. His support is engaged in HashiCorp.
Although the service network space continues to evolve, most of the projects seem to have already come to the concept of a basic set of features that should be supported in such a network:
In addition to these opportunities (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 does not (yet). While both Istio and Consul support different data planes, Linkerd works only with its own. The Consul has its own built-in data plane, which can be replaced with a more powerful one when the performance issue becomes a priority. Istio is designed as a separate centralized control plane, and Consul and Linkerd are fully distributed. Finally, of all the service networks considered above, only Istio supports fault injection. These are just some of the key differences that need to be taken into account if you are considering introducing such a network.
Despite the apparent popularity and promising attractive features, service networks are not as widely used as one would expect. 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 concerns the added complexity that they bring, their relatively poor performance and certain gaps that manifest themselves when working with topologies from a multitude of clusters.
Service networks are ambiguous platforms, at the initial stage of implementation of which serious investments are required in assembling the system itself and its instrumental equipment. It may seem that adding a companion to a container is quite easy, however, competent handling of failures and retries 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 process are sometimes difficult to diagnose, and even more so to eliminate. Since the majority of service networks are aimed at working with self-sufficient microservice applications, and not at the entire landscape of related applications, solutions for many clusters and different regions are usually poorly implemented in such networks.
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, first of all, for developers. At the business level, they do not turn the situation around.
Service networks intersect with other architectural components, but, of course, are not reducible to them. Such elements include API, 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 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 broadcast information between non-routable addresses in a container orchestrator and routed addresses outside of it. Finally, application delivery controllers are similar to API gateways, but their specialization is in speeding up web application delivery, not just the API.
Today we are pleased to offer you a translation of the article, briefly telling about the new technological trend called “Service mesh” (service network). The most interesting solution in this area (in our opinion) is Istio , but the proposed article is interesting, first of all, by an express comparison of the available technologies of this kind and a high-level overview of the entire paradigm. Author Tobias Kunze also wrote a second, more practical-oriented article on the service mesh - please ask if it is worth publishing its translation
This post is the first of two telling about the merits of service networks. This article describes what a service network is, how it works, and what is the use of it. The second part examines why, where and when such networks should be used, and what lies ahead for us.
')
When the application is decomposed into microservices, it quickly becomes clear that calling the service over the network is a much more complicated and less reliable process than it was initially thought. The fact that the plan was supposed to “just work” 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, package and unpack messages. Clients also need to track calls and manage such operations, catching errors, repeating failed calls and maintaining a timeout if necessary. More clients may need to authenticate services, log calls and instrument transactions. Finally, it happens that the entire application must comply with IAM rules, encryption requirements or access control.
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, such as SOAP, Apache Thrift, and gRPC. But what is observed recently: the rapid spread of containers and the accompanying explosive growth of service calls, the degree of horizontal scaling and the related short-term existence of service terminals. When complexity and fragility go to a new level, there is a desire to encapsulate network communication and bring it to a new infrastructure level. The most popular approach to providing this level used today is called the “service network”.
What is a “service network” really?
The service network is not a “grid of services”. This network is an API intermediary (proxy) 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 a multitude of calls that confront developers when they have to exchange information with remote terminals. However, it should be noted that major operational problems are not solved with the help of service networks.
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, the deployed services are modified so that each of them has its own proxy companion . Services do not call other services over the network directly, but instead refer to their local proxy companions, which in turn encapsulate the complexity of information exchange between services. Such an interconnected proxy collection implements a so-called data plane.
On the contrary, the set of APIs and tools used to control the proxy behavior within the entire service network is called its “control plane”. It is in the management plane that users define policies and configure the data plane as a whole.
To implement the service network, both a data plane and a control plane are needed.
Primary players: Envoy, Linkerd, Istio and Consul
Envoy is an open source proxy server developed by Lyft. Today it forms the data plane in many service networks, including Istio. Envoy quickly supplanted other proxy servers 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. Initially, it was written in Scala, like Finagle , from Twitter, from which it originated, and then merged with the lightweight project Conduit and was restarted as Linkerd 2.0 .
Istio is perhaps the most popular service network of our time. It was jointly launched by Google, IBM and Lyft; it 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 a data plane. Istio is usually 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 that span multiple data centers, and specializes in service discovery. Consul works with multiple data planes, and can be used without involving other control planes, for example, without Istio. His support is engaged in HashiCorp.
The main advantages and differences in priorities
Although the service network space continues to evolve, most of the projects seem to have already come to the concept of a basic set of features that should be supported in such a network:
- Service Discovery : Service Discovery and Registry Maintenance
- Routing : Smart Load Balancing and Network Routing, Better Health Check, Automatic Deployment Patterns, such as Blue Green and Canary Configurations
- Resilience : retries, timeouts and circuit breakers
- Security : TLS based encryption, including key management
- Telemetry : collecting metrics and tracking IDs
In addition to these opportunities (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 does not (yet). While both Istio and Consul support different data planes, Linkerd works only with its own. The Consul has its own built-in data plane, which can be replaced with a more powerful one when the performance issue becomes a priority. Istio is designed as a separate centralized control plane, and Consul and Linkerd are fully distributed. Finally, of all the service networks considered above, only Istio supports fault injection. These are just some of the key differences that need to be taken into account if you are considering introducing such a network.
Criticism of service networks
Despite the apparent popularity and promising attractive features, service networks are not as widely used as one would expect. 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 concerns the added complexity that they bring, their relatively poor performance and certain gaps that manifest themselves when working with topologies from a multitude of clusters.
Service networks are ambiguous platforms, at the initial stage of implementation of which serious investments are required in assembling the system itself and its instrumental equipment. It may seem that adding a companion to a container is quite easy, however, competent handling of failures and retries 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 process are sometimes difficult to diagnose, and even more so to eliminate. Since the majority of service networks are aimed at working with self-sufficient microservice applications, and not at the entire landscape of related applications, solutions for many clusters and different regions are usually poorly implemented in such networks.
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, first of all, for developers. At the business level, they do not turn the situation around.
Related technologies
Service networks intersect with other architectural components, but, of course, are not reducible to them. Such elements include API, 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 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 broadcast information between non-routable addresses in a container orchestrator and routed addresses outside of it. Finally, application delivery controllers are similar to API gateways, but their specialization is in speeding up web application delivery, not just the API.
Source: https://habr.com/ru/post/455314/
All Articles