« Previous 1 2 3 4 Next »
A versatile proxy for microservice architectures
Traffic Control
Plugins for Variety
The Envoy developers clearly cannot build support into their product for every web application on the planet, especially when the specifications for many apps are not even open to scrutiny. To offer users as wide a feature set as possible, the developers decided to implement a plugin interface.
Because Envoy is based on an open architecture and free standards, every application developer has the opportunity to write an Envoy plugin for their specific application and deliver it with their pod. When the developer loads an Envoy extension, the software automatically routes traffic through this plugin. Several plugins can be connected in series.
By the way, Envoy comes with a few basic filters out of the box. One handles HTTP proxy functionality, and another is designed as an endpoint for TLS connections. A simple TCP proxy is included in the scope of delivery, as well.
Special Case: HTTP
In the context of load balancing, the HTTP protocol has special significance. The HTTP use case has been around long before any microservices architectures. Web server setups have been based on the simple principle of load balancing for decades. Even in times of REST APIs and modern web architectures, HTTP traffic still accounts for an enormous portion of the traffic generated. It's hardly surprising that the Envoy developers have paid special attention to the HTTP protocol – particularly in two places.
Envoy allows interposing additional Layer 7 filters over a separate interface in the HTTP filter. This interface is also freely accessible and documented, so developers can produce their own filters. More specifically, these filters have access to the entire HTTP flow and can monitor or modify it according to the tools provided by the HTTP filter.
The developers cite HTTP packet routing, limits for incoming HTTP connections using various parameters (number of incoming HTTP connections, volume of data transferred, etc.), and sniffing transferred content as examples. Conceivably during the analysis of incoming HTTP packets, Envoy could detect that a defined limit for individual back ends has been exceeded, which would cause Envoy to route them dynamically elsewhere. As an example of sniffing, the Envoy developers cite Amazon's DynamoDB, which can be monitored by Envoy.
Between Worlds
Envoy supports HTTP/2, which has been on the market since 2015, although its predecessor is still common in the wild. Anyone building a new application today will tend to choose HTTP/2 over the old HTTP. Nevertheless, Envoy offers a practical function to act as a mediator between the two worlds, handling both HTTP/1.1 and HTTP/2. When Envoy translates between the two protocol versions, it does so completely transparently to the client so that older clients that do not yet support HTTP/2 can talk to HTTP/2 services through Envoy. For communication between several Envoy instances in a setup, however, the developers recommend exclusively using HTTP/2.
Remote procedure calls (RPCs) are usually understood to be a framework for calling commands in a controlled manner on remote systems. The processes generate results and send them back to the requesting party. The most common way to develop RPC systems is legacy client-server systems.
In the context of microservice architectures and containers, RPC is experiencing a new dawn thanks to Google's gRPC protocol. Google developed gRPC with the explicit aim of standardizing and automating various processes within an application. If a developer wants to define an interface between two applications, they do not have to re-invent the wheel; rather, they can use the modular gRPC instead.
Little wonder that Envoy supports gRPC and can analyze gRPC traffic flows. In practice, Envoy becomes a dynamic gRPC transport layer in environments that uses gRPC: It intercepts and interprets the messages and routes the traffic accordingly in such a way that it reaches the desired destination efficiently and the desired RPC action is triggered.
In practice, gRPC and HTTP in Envoy complement each other, which is useful from a developer's point of view. Not only does it eliminate the need to design one's own API, Envoy also automatically manages the connection to the API service in the best possible way.
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)