We recently presented on a topic with the Linux Foundation that’s important to us: our role in making the world a better place.
At Solo, we are dedicated to advancing open source and the adoption of service mesh, particularly Istio. We also carefully consider the resources we consume with our software while solving application networking problems. We are all responsible for making choices that positively impact the future.
Join us as we delve into understanding sustainability in software, and how service mesh and Gateway API can help contribute to sustainability goals.
Sustainability in Software
Software carbon intensity measures carbon emissions per unit of computation. It’s critical that we optimize these emissions while still maintaining the computational power necessary to enable modern life and solve other pressing problems.
Software carbon intensity is a rate of carbon emissions. The equation is a simple and elegant solution to the complex problem of carbon emissions.
Service mesh and Gateway API offer the ability to do both.
Service Mesh and Sustainability
Sidecar Mode vs. Sidecarless
Traditionally, a service mesh architecture injects sidecar proxies very close to the application so you can control the traffic coming in and out of your application pods.
Istio Ambient Mesh presents an innovative approach that achieves the same degree of control, security, and observability of your application without wasting compute cycles in sidecars. Ambient Mesh simplifies operations by introducing a sidecar-per-node architecture, departing from the traditional sidecar proxy per application pod model.
Learn how Gloo Mesh delivers a more powerful service mesh solution using Istio.
How Ambient Mesh Works
In Ambient Mesh, the proxy is deployed at the node level, handling layer four connections, while layer seven functions, such as HTTP connection handling, are managed by the Envoy proxy. The use of Rust as the programming language for the proxy enhances efficiency. The traditional proxy-per-pod model is replaced by what Istio calls z-tunnel, forming a mesh between nodes without the need for numerous proxy sidecars.
A significant aspect of Ambient Mesh is the waypoint proxy, a dedicated layer seven proxy designed for applications requiring sophisticated layer seven policy and traffic routing. The deployment of waypoint proxies is more targeted, with one proxy per application workload identity, streamlining the process and facilitating adoption without the need for application restarts. This results in fewer moving parts, improved performance, and a substantial reduction in resource consumption.
Crucially, Ambient Mesh doesn’t force an abrupt shift from existing service mesh architectures. Users can adopt it progressively, making it compatible with sidecars. This flexibility ensures a smooth transition and accommodates diverse application environments.
How Ambient Mesh Contributes to Sustainability
One of the most compelling aspects of Ambient Mesh is its positive impact on both organizational budgets and environmental sustainability. The reduction in resource usage, even with the presence of waypoint proxies, results in tangible cost savings and contributes to a lower software carbon intensity, aligning with the global imperative to reduce energy consumption and emissions.
Gateway API is another example of sustainability and innovation.
Gateway API and Sustainability
Gateway API vs. Ingress
To understand the importance of the Gateway API, let’s first revisit how service exposure was traditionally handled using ingress. Challenges with this approach included multiple load balancers, IP exhaustion, and the complexities introduced by annotations in ingress configurations.
The transition from traditional ingress to the Istio Ingress Gateway marked a significant improvement. It introduced the concept of overloading a single load balancer with multiple ports, addressing some of the challenges associated with traditional ingress methods. However, this improvement came with its own set of complexities, particularly in terms of annotations and provider-specific configurations.
How Gateway API Works
To overcome annotation challenges, the Gateway API was introduced as a common standard for exposing apps and HTTP routes. Gateway classes enable consistent configuration regardless of the chosen provider, and allow flexibility in choosing Ingress providers like Nginx or Istio and swapping them as needed.
The structure involves defining a gateway class tied to a specific role within an organization, determining infrastructure and service mesh choices. Cluster operators define gateways that expose services, while app developers specify the services and HTTP routes.
Gateway API is still in development but reached general availability in early November. Current capabilities include HTTP route functionality, with experimental resources like TCP route, UDP route, TLS, and gRPC routes.
Watch our full presentation to see how to deploy Gateway API resources using Istio’s Ingress gateway.
How Gateway API Contributes to Sustainability
The key to Gateway API sustainability lies in the ability to use gateway classes, providing a common standard across various Ingress providers. Its ability to provide a common standard for service exposure, coupled with its flexibility, makes it a promising solution for enterprises looking to future-proof their Kubernetes deployments.
As the Gateway API continues to mature, its role in simplifying and standardizing service exposure will likely solidify, further contributing to the resilience and sustainability of Kubernetes architectures.
Get Involved
We hope this blog post and our presentation will inspire you to consider environmental sustainability in technology choices. We welcome you to join CNCF Technical Advisory Group for Environmental Sustainability meetings or participate in the CNCF Slack #tag-env-sustainability channel to get more involved in this important work.
