#serviceextensionsplugins

An overview

Service Extensions plugins are a new functionality that Google Cloud has added to its Application Load Balancers. With the help of these plugins, users can run custom code directly within the load balancer’s request and response paths, increasing the programmability of web application delivery. Because the plugins are based on WebAssembly (Wasm), they offer features like secure sandboxing, compatibility for several programming languages, and quick execution speeds. Use cases for this new functionality are varied and include HTML rewriting, custom logging, security policy implementation, and header manipulation. Scalability and low latency are provided by the completely managed environment in which users can operate the plugins.

Now use the Application Load Balancers to execute your own code at the edge.

For dependable online application delivery on Google Cloud, application load balancers are necessary. Although Google Cloud’s load balancers allow for a great deal of customization, there are some circumstances that call for even more programmability.

Google Cloud just revealed the Application Load Balancer Service Extensions plugins in Preview. To adapt load balancers to your business needs, you can now run your custom code right in the request/response path in a fully controlled Google environment with optimal latency. Just supply the code, and Google Cloud takes care of the rest. You can look to Service Extensions callouts, which are presently GA for Application Load Balancers if you want to handle the computation yourself for heavier workloads.

Service Extensions plugins use cases

The following use cases are supported by Service Extensions plugins:

Header addition: Include additional headers for requests and responses, or make new headers pertinent to your apps or particular clients.

Header manipulation: Rewriting request and response headers or overriding client headers while they are being sent to the backend or while replying to a client are examples of header manipulation.

Security: Create sophisticated security rules, such as custom token authentication, depending on response headers or client requests, and decide how to apply them within your plugin.

Custom logging: Enter custom data or user-defined headers into Cloud Logging.

Exception handling: For specific response types, send customers to a personalized error page.

HTML Rewriting: To enable Google Analytics tagging or Google reCAPTCHA integration, rewrite HTML from its original source.

Where your code can be executed

Service Extensions operate at the edge of Google’s widely dispersed network, in the request and response channel. The current traffic extension for the global external Application Load Balancer now includes Service Extensions plugins. The traffic extension executes prior to traffic reaching the backend, but after Cloud CDN and Cloud Armor. Service Extensions will be supported by cloud CDNs in a later edition. Additionally, as part of the route and traffic extensions, the cross-region internal load balancer supports Service Extensions plugins.

Architecture of Service Extension Plugins

Lightweight computation tasks that are part of the Application Load Balancer request/response flow are the focus of Service Extensions plugins. WebAssembly (Wasm), on which plugins are built, has the following advantages:

Startup time in milliseconds and near-native execution speed

Numerous programming languages, including C++ and Rust, are supported.

Cross-platform portability allows you to test the plugin locally or run it across many installations.

Protections for security, including running plugin logic in a sandbox

Service Extensions Plugins make use of Proxy-Wasm, an open source project backed by Google that offers Wasm modules a common API for interacting with network proxies.

Google developed a computing platform that is both scalable and massively multi-tenant (similar to load balancers) to execute Service Extensions plugins. Fully managed plugins offer auto-scaling and dynamic sharding to accommodate traffic demands. This design makes it possible for:

Scalability: As traffic patterns change, we can expand to a large number of Wasm hosts as needed.

Low latency: This proxyless serverless architecture enables even more latency-optimal pathways because there are no extra proxies between the load balancer and Wasm hosts.