Announcing Gloo: The Function Gateway

Today we at Solo are thrilled to announce the release of Gloo, the Function Gateway. Gloo was designed on the principle that gateways should build APIs out of functions rather than services. By allowing users to build their APIs from functions, the smallest unit of compute, Gloo equips them with an unprecedented level of control over how they build their APIs.

Gloo is built on top of the Envoy Proxy. It provides a unified entry point for access to all services and serverless functions, translating from any client-facing API to any backend function. Gloo aggregates HTTP/REST APIs and events from clients, “glueing” together functions in-cluster, out of cluster, across clusters, along with any provider of serverless functions.

What truly makes Gloo special is its use of function-level routing, which is made possible by the fact that Gloo intimately knows the APIs of the upstreams it routes to. This means that the client and server do not have to speak the same protocol, the same version, or the same language. Users can configure Gloo (or enable automatic discovery services) to make Gloo aware of functional back-ends (such as AWS Lambda, Google Functions, and RESTful services) and enable function-level routing.

Gloo features an entirely pluggable architecture, with an extendable configuration language, pluggable upstream types, discovery services, and internal components.

The Key Properties of Gloo

• Function-level routing
• Entirely pluggable architecture
• First-Class support for Cloud Native Ecosystem
• Elegant, extendable configuration language
• Stateless, declarative API

Why did we build Gloo?

Many of the problems solo.io encounters is helping customers boil down to bridging the gap between the many service architectures that exist in the cloud today. Most companies are running somewhat “hybrid” deployments: a combination of microservices, monoliths, and sometimes serverless functions. This fact alone can explain the rise in popularity of the API gateway pattern. API gateways provide a layer of abstraction between clients and the distributed backend services with which they communicate.

Existing gateways provide useful API management features (retries, metrics, authentication) and route to backend hosts through a single entrypoint. However, in this model, clients are still responsible for understanding back-end APIs. This also means that route rules need to carefully match incoming requests with the expected APIs on back-ends.

In order to aggregate the APIs of back-end services, it’s necessary to present them to the client as a unified whole. A gateway should decouple clients from the back-end services they communicate with, not just for the purpose of TLS termination, but to actually abstract the upstream APIs. We realized this would not be possible to do with a traditional API gateway, which simply routes API calls to services. We would need a gateway that was aware of the API expected by the back-end, that could provide API-to-function routing. We designed Gloo to consider back-end functions as a first-class principle. Gloo aggregates the individual functions provided by any number of back-ends into a single API on the front-end. This allows us to provide advanced features for clients, such as function-level routing, function-level traffic splitting, function fanout, and function-level canaries.

Potential uses of Gloo

Some use cases that could benefit significantly from Gloo include:

• Compose “hybrid apps” by combining specific functions from various upstream services
• Change upstream APIs without breaking clients or forcing them to upgrade
• Automate routing and self-service with Gloo’s Discovery Services

These use cases and others will be discussed in detail in our next blog.

Design principles

We designed Gloo with 3 principles in mind: proxy enhancement, extensibility and community consumability.

Proxy enhancement

In building Gloo, we took full advantage of Envoy’s power and extensibility. Many of Gloo’s features were only made possible by writing custom filters for Envoy.

Proxy extension at the filter level: efficient manipulation of the request requires being on the request path. Instead of adding a mediation proxy, we put the code we needed directly into Envoy via its efficient async C++ filter interface.

We are releasing several filters to enhance envoy:

• Request and response transformation filter: Enables advanced request and response transformation using templates;
• AWS Lambda Filter: transforms requests into AWS Lambda invocations. Can be executed both synchronously and asynchronously;
• Google Functions Filter: transforms requests into Google Functions invocations.

Toggle filter based on the routes metadata: we enable toggling Envoy filters for specific routes for maximum flexibility and function-level features.

Filters at the Function level: we created a base filter to make functions a first-class object in Envoy.

The two latter features enable the suite of Envoy features to be applied at the function level, for example fault injection, and traffic shifting.

Extensibility

At Solo, we strive to design our software to be pluggable and extensible. New use cases and platforms emerge frequently in the constantly evolving cloud ecosystem. Every one of Gloo’s core components is pluggable. Gloo’s configuration language itself is extensible through translation plugins.

• Gloo’s API is accessed through a pluggable storage layer, allowing the maximum decoupling of clients from Gloo’s API, and easily supporting numerous concurrent clients.
  For example, Gloo’s discovery services are in fact clients which configure Gloo. They can all act independently by writing to the storage layer. Gloo does not need to know whether config changes are made by a single actor or many actors; it only cares about the desired state of the system.
• The Storage Layer is pluggable.
  Currently supported are Kubernetes (Custom Resources) and File storage.
  New storage types can easily be added by extending the gloo-storage client.
• The Secret Storage Layer is pluggable.
  Currently supported are Kubernetes Secrets, Vault, and File secret storage.
  New secret storage backends can be added by adding additional Gloo secret watchers.
• Endpoint Discovery services are pluggable.
  Gloo discovers ips and hostnames for upstream services automatically.
  Currently, only Kubernetes upstreams are supported. However support can be easily added via endpoint discovery services. We plan to add Cloud Foundry and Consul support soon.
• Gloo’s configuration language is extensible via plugins.
  Plugins can define new types of upstreams, functions, routes, and Envoy filters.
  Plugins are responsible for translating user config to Envoy config.
  This is where we especially encourage open-source contribution, to add custom features and new types of upstreams, functions, and route rules to the Gloo ecosystem.

Community consumability

With years of experience as members of open source communities, we at Solo appreciate the importance of making projects easy to consume and easy to extend. Open source communities inevitably bring about use cases and requirements beyond the original release of a project. We believe the success of projects such as Kubernetes is due in no small part to its ability to be extended and customized.

• TheTool — Automates custom builds and deployments of Gloo and Envoy, simplifying the development process and the addition of user-contributed plugins.
  TheTool also supports building a “lean” Gloo, that only contains desired features without bloat.
• glooctl — Gloo’s command line was designed with ease use as its key principle, while allowing flexible use of Gloo’s powerful config language.
• Kubernetes Ingress — out of the box support as a Kubernetes Ingress Controller.

Try Gloo now!

We encourage you to check out our GitHub repo, our docs, and join our slack channel. A great place to start is the getting started tutorial. Have fun Glooing!