The final presentation of the day was by solo.io, an industry leader in cloud-native application networking. One of the things that Brian Gracely, Head of Marketing, discussed which was helpful for me, as I am relatively new in this area of cloud-native applications, was an overview of the emerging trends in application networking. He began with a discussion of the maturation of Kubernetes, as more and more companies have implemented it successfully and are now identifying the next levels of challenges. The next step once companies have deployed kubernetes, is to look into the standardization and simplification of service mesh, in order to scale, apply security, and manage identity. Another trend is the merging of service mesh and API management. This is another area where solo.io is helping customers distinguish between the different levels of exposing APIs internally or externally and determine the best solution for their situation. The final area that was covered was the adoption and evolution of platform engineering as developers are increasingly looking for agility and speed to market. How do companies manage and secure their infrastructure without burdening the application developers with that task?
Companies approach solo.io for help when they’ve gotten to a certain point in their cloud-native application deployment and they are looking to expand into larger scale micro-service deployment perhaps involving multi-cloud strategy. They come to solo.io to leverage their deep expertise in areas like Envoy and Istio knowing that solo.io has been and continues to be integral contributors and innovators in both of those open-source communities.
In the cloud native application stack, Envoy is the de-facto proxy sidecar solution providing data plane functionality and Istio is the de-facto control plane for microservices architecture. What solo.io had done in the past was have two products, Gloo Edge, an Envoy-based API Gateway, and GlooMesh, an Istio-based service mesh. In the fall of 2022, solo.io released their new GlooPlatform which integrated GlooGateway, which is the evolution of GlueEdge, GlooMesh, and GlooNetwork, an Enterprise Cilium-based CNI for Kubernetes and Istio service mesh, all having under the unified API management of GlooPortal.
Another key passion for solo.io is education and empowerment which is embodied in their solo academy (https://www.solo.io/solo-academy/) which has hands-on labs, self-guided learning paths, and interactive workshops and has helped over 4,000 engineers attain various levels of certification.
In addition to the above challenges, many companies find that solutions based on sidecars can have a number of critical drawbacks. Sidecars have no ordering controls so it’s possible for a workload container to come up and not be able to make an outgoing connection because the sidecar is not ready or available. Sidecars also don’t have lifecycle controls so sometimes jobs do not run to completion and other times jobs may complete but the pod is not cleaned up because the sidecar runs indefinitely. Another drawback is the way sidecars interpret Layer 7 protocols sometimes resulting in parsing errors or mismatches between client-send-first and server-send-first protocols. A final drawback is that the sidecar solution is all-or-nothing. Users who need mTLS can inject a sidecar proxy but that introduces complex L7 handling as well which can result in unexpected behaviours. All of these drawbacks bring the data plane away from the goal of being invisible and transparent.
Christian Posta, VP and Global Field CTO, talked us through some of the innovations that solo.io is introducing with their Ambient Mesh introducing a sidecar-less data plane which divides the network into separate layers for L7 and L4 processing. The primary goal is to address the drawbacks mentioned above to make the service mesh solution more cost-effective, simpler, and better performing.
The Istio Ambient Mesh solution that solo.io is currently working on and hopes will be available for production by next quarter uses a secure transport layer utilizing ztunnel (zero-trust tunnel) for L4 traffic and waypoint proxies for L7 processing.
In the above diagram, we can see that the ztunnel runs as a shared proxy on each node but only for L3 and L4 traffic so it can be an entry point for customers who may only need that functionality for mTLS. If a customer needs L7 processing, the waypoint proxies can be deployed (in pairs for HA) per application. So extrapolating the above diagram, if App A was on 10 nodes, there would be two waypoint proxies deployed. In the sidecar model, there would have to be 10 sidecar proxies deployed. Both the deployment and management of the L4 secure transport shared proxies and the waypoint proxies are done at the Istio control plane.
As I mentioned before, I am still very early in my learning path for cloud-native applications and I found this session by solo.io to be challenging and interesting and I’m excited to see how they continue their exploration and innovation in the service mesh space.
HangTenTech 
Leave a comment