Last week, I was able to hear an update from Solo.io during Cloud Field Day 16 in Santa Clara. The 5 year old tech company shared a slate of success stories as they kicked off their presentation, including successes fueled by pandemic pivots and innovations by its customers.
One customer, acquired by a large big-box store, used the Solo.io Gloo platform to accelerate same-day delivery, competing with Amazon’s Prime to drive new revenue and opportunity during the pandemic. Another, pivoted their largely in-restaurant sales to digital sales successfully, gaining additional insights into customers and habits by moving to digital sales. Their success was so great that the customer decided to redesign, expand and rebuild their stores and drive-through designs during the pandemic and beyond to drive great insights through the utilization of digital commerce. Both are excellent examples of successful digital transformation using cloud-native techniques.
In both examples, cloud-native infrastructure and all of the talking points around business agility and decreased time to deliver innovation permeated the stories. But as with many new innovations, as you begin to scale new concepts, new problems arise.
Challenges scaling cloud-native
Solo.io’s Founder, Idit Levine, anticipated the new issues that customers encountered while adopting cloud-native methods to solve pandemic problems. Solo.io bills itself as a cloud-native networking vendor, helping customers to achieve scale of their solutions across geographies, offload security functions to standardized processes, and drive better telemetry and metrics from the deployed workloads.
Akin to RedHat, Solo.io takes open source projects like Istio, Envoy, Cilium and others, making them enterprise-ready and building a support model for customers looking to adopt these technologies and cloud-native concepts.
Solo.io uses the Gloo brand for its product – currently three – GlooMesh, GlooGateway, and GlooNetwork. GlooMesh is the service mesh product, which allows orchestration of applications running in many Kubernetes deployments to be unified and scaled, along with all networking orchestrated and balanced. GlooGateway is an Envoy-based solution for API Gateway and Kubernetes ingress controller. GlooNetwork is a commercial Cilium network implementation with eBPF, another open-source project.
What is Istio?
Istio is an open source project that creates a programable, application-aware network of services. At a high level, Istio is used to route users to services hosted in Kubernetes. Its real power is the ability to provide network encryption, traffic control, security and telemetry
Istio deployments are made up of two parts – Istio itself, which stitches together individual Kubernetes clusters and services into a Service Mesh, and Envoy, the proxy function, that runs inside of a Kubernetes cluster. Think of Istio as the controller and Envoy as the worker.
Envoy installs into Kubernetes pods and services as a sidecar. Sidecars are a construct where a complimentary container runs beside another service container. In this use case, the Envoy sidecar runs beside the workload sidecar to provide networking and security functions to the primary workload. This may include TLS encryption of HTTP or API traffic for the application, or it may be a network policy or security policy. In addition, Envoy can inspect the traffic and container stats and report those out to external monitoring. These functions are all assistive and necessary, but as an organization, we do not want our developers to have to develop and inject this into every workload. Instead, we can consume these from Envoy and Istio for every workload while our developers write code for the primary workload and infrastructure or operations teams handle these functions using the standard Envoy and Istio implementation as a sidecar.
In the image above, you also see 3 different Kubernetes clusters and types for workloads. Istio and Envoy provide a common method across cloud providers and technologies to allow for the management and deployment of applications, no matter where a service needs to live or in which implementation of Kubernetes.
Why do customers adopt Istio?
The first use case, confirmed by solo.io during Cloud Field Day 16, is generally to secure traffic between services in Kubernetes clusters. Instead of packaging certificates and handling encryption of traffic, this function can be offloaded to the Istio/Envoy combination and orchestrated for your services and applications.
The traditional way this works is to add an Envoy sidecar into each service, where the ingress/egress of traffic for the service is handled by Envoy instead of being exposed by Kubernetes through a load balancer or some other function.
In the illustration above, you can see Envoy (the pink hexagon icons) attached to each service and at the edge of each Kubernetes cluster.
New Innovation: Istio without the Sidecar, Istio Ambinet Mesh
The sidecar approach is very useful with many benefits, but it also adds a level of bloat with many Envoy containers in the environment. Solo.io and Google have been working diligently to bring their functionality without the sidecar and without too many trade-offs or missing features.
With Ambinet Mesh, customers gain the ability to focus only on transport, layer 4, security where that is all that is required, without the overhead of a full application, layer 7, overhead. Users benefit from easier maintenance and operation, due to reduced deployment points – which also turns into less compute and memory overhead for running Istio in the environment.
Ambinet Mesh moves the functionality currently in a sidecar from the pod level to the node level, which improves performance, decreases resource utilization and enables the benefits above. The management layer and feature set stays the same, however, keeping a consistent management play for sidecar or sidecarless deployments.
For more detail, see solo.io’s announcement of Ambinet Mesh on their website.
Disclaimer: Tech Field Day, an independent organization, paid for my travel and accommodations to attend Cloud Field Day 16 where these cloud-native vendors presented. The views and opinions represented in this blog are my own and were not dictated or reviewed by the vendors.
