The microservices architecture that has become so popular lately offers a number of benefits, including agile development. If the individual parts of an application no longer have to be squeezed into the release cycle of a large monolithic product, development becomes far more dynamic.

However, if you suddenly have to deal with – from the developers' point of view – many small components, you have to define interfaces that talk to each other. All of a sudden topics such as load balancing, fault tolerance, and security start to play a significant role. Service mesh solutions such as Istio, which I reviewed in an earlier article [1], are currently enjoying great popularity, promising admins an automated approach to networking.

As a closer look at the Istio architecture (Figure 1) reveals, the Envoy open source component is the core of the solution and confers most of the functionality. Fundamentally, Istio is a dynamic configuration framework that feeds Envoy settings for a specific environment.

Figure 1: Envoy is the classic tool when it comes to Istio, but it is far more than an Istio add-on. © Mateo Burillo

Accordingly, the Istio developers refer to Envoy as a sidecar, but if you see Envoy only as a component of Istio, you are doing the tool an injustice. In this article, I look into Envoy itself, its features and the question of how Envoy can be rolled out and operated in a meaningful way, even removed from Istio.

Universal Proxy

The very first sentence on the Envoy website [2] reveals that the developers are seeking to provide a comprehensive solution. They refer to the tool as a proxy suitable both for use in applications and for use in user-facing operations.

Both developers and admins have to deal with several types of connections in clouds. On the one hand, customers connect with individual application services from the outside by relying on a microservices architecture. On the other hand, the individual components talk to each other. Envoy claims to serve both use cases adequately as a proxy server: It seeks to be the switching point in both directions.

Such challenges in the area of communication between services are not new. Classical setups usually combine several services; here, too, interprocess communication is an issue. Even a short excursion into the desktop world makes this clear, where various services written by different developers have to talk to each other.

In the past, libraries that offered standardized functions and thus facilitated the task of establishing connections often solved the problem. However, the concept is relatively rigid, and if you look at the situation on the desktop, you will quickly discover that communication buses, to which all the tools involved are connected, have been the dominant approach for years. Envoy ultimately sees itself in exactly this tradition: It seeks to act as a bus within setups. To make this work, Envoy comes with various practical features and characteristics.

C++ Performance

If your focus is on the world of contemporary programs and solutions, you will tend think of Go or Rust when it comes to new applications. Although Envoy is still comparatively new, the solution was not written in any of the modern programming languages. Instead, the developers deliberately went for C++ 11, which they believe has a far lower performance overhead than its modern counterparts.

For example, latency is significantly higher in the various current scripting and programming languages than is desirable for modern high-performance setups. C++ 11, on the other hand, is optimized out of the box both for efficient development and fast performance. Their argument against C was that, although fast, from the developer's point of view it does not provide the necessary tools desired for the development of a proxy.

Layers

Sooner or later every computer scientist is confronted with the various levels of the OSI model. The team describes Envoy as primarily a proxy for OSI Layers 3 and 4, which means Envoy can be configured to work exclusively on the basis of IP addresses or, if required by the application, potentially as an instance that speaks a certain protocol. A load distributor for HTTP can be implemented by resolutely forwarding port 80 to the back ends.

In practice, however, this approach proves to be lacking because features such as session persistence are now commonplace in the load balancer business. In specific terms, one requirement in today's setups is that a client must always reliably reach the same back end for several requests in succession. The session handling integrated in many web applications is an example of a function that requires this persistence.

If Envoy were based solely on Layer 3, it could offer this function without understanding the HTTP protocol. In this case, however, the program would not be able to analyze the traffic flowing through it (e.g., to identify the session ID of the application on the web server side and use it if necessary). This is only possible if Envoy actually understands the traffic – and that's exactly what the Envoy feature is for, as well as processing data from Layer 4.