At KubeCon 2023, we sat down with Keith Mattix to talk about his work on the Open Service Mesh team at Microsoft Azure. While service mesh technology is paving the way to a brighter future of Kubernetes networking, Mattix shares why service mesh is an evolution of principles that have been around for decades.
Mattix also shares what becoming a Cloud Native Computing Foundation (CNCF) project has meant for the Istio project, what’s next for the Gateway API and GAMMA initiative, and how open source collaboration delivers value to end users. If you’re like us, his infectious passion for open source will inspire you.
Listen to the full episode of the Open at Intel podcast here. This conversation has been edited and condensed for brevity and clarity.
Service mesh 101
Katherine Druckman: Will you introduce yourself and tell us what you do?
Keith Mattix: I’m an engineering lead at Microsoft, leading the upstream service mesh investments in engineering. We work a lot with the Istio project and many related technologies in the Kubernetes networking space. I’ve been at Microsoft for about two years and have been working in the greater open source community for about four years.
Katherine Druckman: Could you provide a service mesh 101 for those who are not so deeply embedded in the cloud-native world?
Keith Mattix: I like to think of service mesh as an evolution of patterns that we’ve had in our industry for a long time. If you think back to when we were writing these large monolithic applications—maybe you were running ASP.NET, a Node.js service, or my personal favorite, Ruby on Rails—you’ve got these large Ruby on Rails applications you’re deploying somewhere, and the frameworks were really thick. In the Ruby on Rails framework, you could get a gem for just about anything. In ASP.NET, you’ve got these client libraries that can do anything under the sun. Even if you look in areas like Java, where the standard library wasn’t as huge, you still had lots of organizations like Netflix open sourcing Hystrix that provided some of the capabilities that are necessary for distributed architectures, such as client retries and timeouts. As people moved from the rails monoliths to microservices, they kept the libraries, iterated on them, and used them directly in the code to, let’s say, provide mutual TLS (mTLS) and encryption across multiple services and set up retries, timeouts, and logging infrastructure across their fleet.
Service mesh is just an evolution of that idea. When you’re running in a distributed system, you need observability to see what’s happening in each hop. You need to have fine-grain control over where traffic goes from service A to service B. You need the ability to write security policies to define which services can talk to each other. The earliest service meshes, like Linkerty and Istio, looked at these client libraries and said, “These are really complicated.” As polyglot environments became more prolific, replicating all that logic, rewriting those client libraries got too expensive and required too much developer time. Service meshes abstract all of that functionality into a proxy. At a certain point, your Java framework, Hystrix framework, or ASP.net framework can only do so much until the cost gets really high. Service meshes put all that logic back where it has been for decades—into a proxy, such as an NGINX proxy or Envoy proxy. It’s an evolution of the same piece of functionality that has been in your client libraries and language ecosystem for a long time, just put it into a proxy and made Kubernetes-ified.
The Magic of Collaboration
Katherine Druckman: Istio is a CNCF project. Will you tell us about the process of becoming a graduated project?
Keith Mattix: Istio’s journey was a little unconventional. It was open sourced by IBM and Google. But early last year, Istio began the process of joining the CNCF after four or five years living outside of the foundation. It was accepted at the incubating level, and the move to the CNCF did a lot for the Istio project. We saw lots of new faces that hadn’t contributed before—Microsoft is one of those companies. Now that Istio has hit graduated status, we’re moving faster than ever. We’ve got several maintainers from Intel who have provided some amazing innovations, especially around cryptography and increasing the performance of certain encryption operations. The beauty of open source is that, whether it’s Intel, Microsoft, or any number of startups, we all bring our collective experience and knowledge out in the open and make amazing projects and products that ultimately help improve the lives of users.
Katherine Druckman: When I first joined Intel almost a year and a half ago, I was impressed by the vast number of projects Intel is involved in. It’s incredible to see the industry collaborate to solve increasingly complex problems.
Keith Mattix: When you write software in open source, you get the benefit of not being tied to the structure of any particular organization. We benefit from the combined knowledge and context of multiple companies. That trickles down to users because Microsoft’s organization might not look like the organization of our users, and we don’t want to necessarily bake those assumptions into our software. Sometimes when you have software that is completely written or dominated by a single company, you get some of those assumptions leaking through. Open source is a way for us to hedge against that and write software that is representative of the diverse and wide-ranging set of use cases that our users have.
The Future of Kubernetes Networking
Katherine Druckman: Will you talk about Gateway API version 1.0 and its mesh support? It’s also known as the GAMMA initiative, right?
Keith Mattix: The GAMMA initiative is a subproject within Gateway API, which is a subproject of the Kubernetes SIG Network. For those who may be unfamiliar, Gateway API is kind of an evolution of service and ingress networking in Kubernetes. The Ingress API was one of the first APIs released in Kubernetes for getting traffic into your cluster. When Kubernetes started, developers were assumed to be the main users. But over time, we’ve seen discrete personas and use cases for Kubernetes emerge. You’ve got your infrastructure provider—this could be your cloud provider or a bare metal provider like Equinix Metal. Whoever is providing that load balancer—those virtual machines (VMs), the compute, the disk—that’s your infra provider, and they’re concerned about being able to allocate things according to user specifications in a dependable way. Then you’ve got your cluster operators, who are concerned with platform engineering. Platform engineering is the idea that instead of having developers touch these very complex technologies and have to understand all of Kubernetes, they should be able to deal with an abstracted platform that sits on top of Kubernetes to solve common tasks. Finally, you’ve got your developers, who are heads down writing business logic, creating value for your organization. They just want to ship code and expose it on a certain API endpoint.
Gateway API ingrains these personas directly into its API design, so instead of just one ingress resource, we’ve got Gateway, GatewayClass, and a set of routing APIs. As we were looking at this in the service mesh world, we noticed that Gateway APIs looked very similar to what we were doing. In the spirit of open source, we joined hands and said, “Hey, what if we took these Gateway APIs and utilized them for the East/West use case—the service-to-service use case of service mesh.” It turns out it was a match made in heaven. Early this year in version 0.0 of Gateway API mesh support was included through an initiative called the GAMMA, a weird backronym that stands for Gateway API for mesh management or administration. We collaborated with the Gateway API community. I’m fortunate to serve as one of the Gateway API mesh leads, shepherding the evolution of those APIs. Now with Gateway API hitting the 1.0 milestone, it’s emerged as the de facto future for Kubernetes networking and application routing, and I’m super excited to see where it’s going to go as we add more features and even more integrations moving forward.
Katherine Druckman: Where would you like the project to go? If I talk to you again at KubeCon next year, what are you hoping to be able to tell me?
Keith Mattix: Mesh support and Gateway API is currently experimental. I’d love to see us make the progress necessary to get stable, so our users can feel more comfortable and supported that this is something they can put into production. The other thing I’d like to see from the mesh perspective would be some level of authorization policy—the ability to say, “Hey, I want to disallow this application from talking to my application,” or, “I only want to allow traffic to this port.” Most if not all mesh implementations can do something like that, but there’s no defined standard or specification for what those resources look like. We’ve shown the spirit of open source and collaboration that we can find a standard we can all agree on for routing, and right now, Istio, Linkerty, and Kuma all implement Gateway API for mesh with full conformance. So if we can do that, I’m fully confident we can get it done for authorization policy. Other things I’d like to see within Gateway API include backend TLS policy for allowing your ingress gateway to do MTLS for your applications, which allows users to have end-to-end encryption for a particular request. That merged recently, and I’d love to get that from that earlier stage over to something more mature like a beta API and get that in the hands of our users. Lastly, I’d love to see even more adoption. There are already 26 implementations of Gateway API, which is just staggering to me. With all the options available to users, I want to see them pick it up and try it. Hopefully, with that 1.0 status that was reached just a couple of weeks ago, we’ll see users be ready to take that next step with Gateway API.
Making a Difference at the Infrastructure Level
Katherine Druckman: What else are you excited about in the open source ecosystem?
Keith Mattix: The number one thing that excites me is the ability to provide value for users. When there are thousands of people roaming the halls of KubeCon, it’s easy for us to forget that the vast majority of people are in their first or second year of their cloud-native journey. We can’t forget those people. I’m excited for taking the solutions we’ve built, like Istio, Open Service Mesh, Linkerty, and Gateway API, and bringing them to users in a digestible way that guides them in their adoption journey so that they can provide more value to their customers.
Because we work in infrastructure, we’re one of the lowest layers in the stack. According to Amdahl’s law or just general performance programming principles, the lower in the stack you make an improvement, the greater the impact of that change. If you think about something as simple as TLS encryption, when my grandmother orders something online, she’s using TLS. Anything that we do to make TLS faster has crazy implications on latency. If you make TLS five times faster, my grandmother feels that on Amazon. The same applies to anything you can do at the infrastructure level to reduce friction, improve performance, improve docs—any of these day-two types of things that you expect from mature projects. In the Kubernetes of Azure, we’ve been pushing for long-term support so that users and customers don’t have to constantly upgrade their current clusters every half year—that’s too much for a lot of organizations. We want to give them security that they can run their applications and do what they do best—such as providing value to their users and shipping their business logic. That’s what I’m excited about—seeing the cloud-native landscape become more accessible, more performant, and more stable for thousands and thousands of other users who might be earlier in the cognitive adoption.
Standing on the Shoulders of Giants
Katherine Druckman: Is there anything else you want to answer that I didn’t ask?
Keith Mattix: What you didn’t ask me is: Why is Kubernetes important? Because it gives us a standard way to ship applications. What Kubernetes has turned into has shown the power and the impact of being able to declaratively ship applications. With the ability to extend the Kubernetes platform via CustomResourceDefinitions (CRDs), operators, and controllers, we’ve seen the ability to build massive ecosystems based on that core technology. It’s allowed us to shift our thinking into building platforms. In 10 or 15 years there may be something new, but the lessons Kubernetes taught us—being on the journey, being here at KubeCon, continuing to innovate and create value for the next generation of cloud-native adopters—will still be with us. It will allow us to create even better software in the future, standing on the shoulders of giants who are here at this conference with us and build something new that ultimately changes lives. That’s why I’m excited to be a part of the open source ecosystem.
To hear more of this conversation and others, subscribe to the Open at Intel podcast:
- openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Your favorite podcast player (RSS)
About the Author
Katherine Druckman, Open Source Evangelist, Intel
Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she’s a longtime champion of open source and open standards.
Keith Mattix, Senior Software Engineer Lead, Microsoft
Keith Mattix is a senior engineer on the Open Service Mesh team at Microsoft Azure. As a maintainer of the Service Mesh Interface CNCF project, Keith is a founding lead of the GAMMA initiative under Kubernetes SIG Network. Keith has written a lot of code that’s led to some interesting side quests, and he’s passionate about sharing those lessons and experiences with others. His love of distributed systems is eventually consistent.