Istio Graduates as Open Source Service Mesh in CNCF – Craig Box, ARMO

This is techstrong tv. Well, the great pleasure of being joined by Craig Box, and we're talking about some very cool news, great things that are happening in the Istio community. Welcome, Craig.

Good to be talking with you. Well, thank you, Mitch. Well, let's, let's, uh, before we get to the kind of great news and the cool things that are happening, if you're in the cloud native, you know, microservices service mesh world, you know what STO is.

If you're not, it may not be something familiar. So give folks maybe a little bit of what of what it is in the history of it and, and then we'll talk about kind of the news that's happening. Of course, Kubernetes was founded at Google in 2014, looking at the state of the internal systems at Google and how they operated, and then what was available in the market at the time.

And so the engineering team at Google, where I was working at the time, looked at Docker, which was popular out there in the world, and look how they could solve container scheduling problems. 0 afterwards. The SDO project is a very similar thing that that started at Google.

It was looking at how it could manage microservices and, and help with some of the networking concerns for them in the same way that Kubernetes could deal with the deployment concerns in a similar fashion to how Kubernetes built on top of Docker. We looked out to see what was available in the ecosystem and came across Envoy, which was a proxy server that had just been released, was in the process of being released by Lyft, very high performance modern proxy server. And we were looking to how we could solve some of the challenges we saw with operating applications, the things that we knew we faced internally at Google, and that people were going to have to face as they went forward building on top of meeting people where they were working also with partners in the communities.

So I B m very early on, we joined forces with them and put together a project that was very similar. We decided not to do that work in the Kubernetes project itself, to keep that very core and have it deal with containers, but we wanted to look at how we could build out an ecosystem of all of the tools that were required. And so STO was the tool that Google developed in order to deal with the net networking challenges that came up when running a distributed system.

Broadly speaking, we have pieces that need to speak to one another that are no longer guaranteed to be able to connect. They're not necessarily just processes on the same machine or threads in the same process, but now what happens if you call a service and it's not available? What happens if you need to retry connections to it a certain set of times?

What happens if someone else has taken over the endpoint for that service and there's no longer the endpoint that you expected it to be? So we looked to security observability and network functions and how we could adapt that and to do that in a way that was transparent to applications so that we didn't have to change the application, that we were just able to add a little something in front that handled all of those things for you. Using, of course, the Envoy proxy that I mentioned.

And then the SDO project was launched in in 2017 to solve those problems. Pretty amazing how far it's come in five, six years from where it is. I remember seeing the Estio book, well, let me check that out.

Let's, let's go look at that, the O'Reilly book. Well, tell us about the news. Um, what, what's, we have some kind of graduation or, or moving along in the maturity of, of the project at C N C.

Yes. Yeah. SIO today has announced the graduation within the Cloud Native Computing Foundation.

The project was donated or contributed to the C N C F last year and joined at the incubation phase, which basically was a reflection of the process that needed to go through at the time to move through those steps. It is a very mature project that joined after five years, and so we have obviously many production users and many different ecosystem and many different industries, sorry. And this graduation today is sort of a reflection that the project is recommended for use in, in all use cases in the same way that things like Envoy and Kubernetes that it builds on, it joins those projects now with the top level of recommendation from C ncf F And one, one of the, uh, aspects of this, and I know you had a lot of contributors and, and companies involved, but the, the companies that are contributing, supporting, engaged in the leadership at the working level, you know, it's a kind of a who's who of, of technology companies.

Not everybody in the world is there, but it's the IBM Red Hat, Intel, uh, VMware, la la la you know, the list goes on and on. People who are part of the, uh, team as well as contributing. Yes.

That's something that's perhaps a bit different with SDO than many other open source project. It is very corporate led unashamedly, so it was founded by Google and ibm, uh, many other vendors. You joined, uh, many Chinese vendors as well.

Huawei have a great deal of contribution and service mm-hmm. As to, uh, Tencent and Alibaba and other providers there. Then there's also networking vendors, people like Cisco, there are people like Salesforce who use it internally and have done a lot of contribution to it.

Mm-hmm. And then there are companies like TE Rate and Solo who were founded to offer STO services, and that's on top of all of the other people who run Kubernetes environments and have offered STO on top of that. We've gone back with them now many, many years, but since joining C N C F last year, we've also managed to broaden the horizon a little bit as a neutral project openly governed.

We've now welcomed Microsoft on board as well, who had been working on a, a different service mesh product, and they decided on balance that the right thing to do was to be part of, of this open ecosystem, and they archived that project and have now joined the S D O community as well. So now, now you've, uh, kinda moved up in status and maturity, um, from the C N CS perspective, what does, what does that let you do as a project and what does that mean to the people who are using Istio? Uh, open source software If you separate the software and the project for a little bit.

So it doesn't make a huge difference to the software itself. Like we have a very mature process for delivering the software. It does, of course, bring more people on board.

As I mentioned, Microsoft for example, they've brought their engineering team onto this. So we are able to drive that forward. And it also helps with contribution that we're all doing as a community to bring service mesh to the broader Kubernetes ecosystem.

We started a project last year with Microsoft and with some of the other service mesh vendors, and with the Kubernetes team to use the new gateway APIs in Kubernetes, which are designed to handle ingress use cases to replace the Kubernetes ingress and expand them to support ingress to services, to support service mesh use cases. Those APIs were largely built based on SDO implementations from the past. But now what we're doing is building out an api which is available to everybody, and you can say, here's how I want to define traffic within a cluster, and you can use the SDO implementation or you could use a different measure implementation that also uses that same api.

So that does help in terms of collaboration as well. When we come to the software and its use cases and so on, it is very mature and we have a good engineering team working on it from, from many different vendors. I don't think we expect to see a, a huge change in how the project is, is run or managed, but one thing that we see when people evaluate whether or not to choose software is they look for that seal of approval.

They sort of see it as a shortcut to say it is vetted by somebody else. It is guaranteed that the, the trademark and the processes and so on meet a minimum bar. And that is something people were obviously very happy to use stom production beforehand, but this just helps them stop needing to do that analysis themselves and say, Hey, it's in this category.

It's graduated in the C ncf, therefore I know that I can trust that it meets this bar, But it's not like, um, you attain this level and then you put it on the shelf. It's, it's, you attain this level because you have a, a certain level of engagement and activity mm-hmm. And support and commitment behind it.

Yes. And we will need to maintain that as well. So there's, there's no formal process by which project, uh, is of reevaluated over time, but we do encourage people to look at the, the number of contributors to a project and how active a project is when they choose to decide which software that they want to bring on board.

Mm-hmm. Uh, one of the great things I was excited to talk with you about is in a very simplistic way, one of the things I describe, um, cloud native architecture, particularly around service mesh to non-software developers. So it may be security people, network engineers, folks like that is, think about it this way, the network essentially has gone into the application and it's all kind of woven together.

It's not a, a hard exterior that's controlled through APIs or, or rigid protocols. Um, do, I mean, I'm curious the folks that are involved from network companies like F five and Cisco, et cetera, uh, are, are they contributing, uh, largely from a network perspective, or is it still thinking about it as a Kubernetes world and, and, uh, cloud native kind of architecture? Uh, or is this a bridge to the networking people?

That's kind of what I'm asking. Curious your perspective On that. It, it can be both.

So there are vendors, uh, TRICS comes to mind who are building modern networking stacks, and they're realizing that simply dealing at layer three and saying, this traffic is going to, this IP address on this port isn't enough to, to deal with security and, and application identity and so on. So they are using it to move further up the stack in terms of application networking. You get people like Intel who are saying, we want to be able to support acceleration of those kind of network use cases with Intel hardware and network cards.

And you get people who are dealing at how they can make that faster. And you also get people who are looking from the Kubernetes perspective and saying, here is something that I wasn't able to do without making changes to my application. So we do really see across the board in terms of contribution, at least people who are looking to say, this is how we want to define things.

And you mentioned there differences between security and platform teams and developers. This is something we can offload from developers that they don't need to worry about. They don't necessarily need to change their code to say, I'm going to deal with identity and validation.

This is something I can trust that my network does for me. And have a platform team provide that underneath and know that any connection you make will be bound by those things. And then of course you can apply that across your clusters, across one or many clusters.

And from the security team's perspective, you can say, well, I, I know that as long as this thing is running, then this isn't a policy that's enforced everywhere, and I don't need to worry about people forgetting to add that or audit the code in order to know that the traffic will be secure When we think about it in terms of distributed applications, even applications to the edge as well as cloud, multi-cloud, all that kind of thing. It's all, it's a networking fabric that it's obviously operating on. But now in a cloud native world, that's, uh, And the zero trust world as Well.

Environment, pardon? Go ahead. Sorry.

And the zero trust world as well. Zero trust. There's a lot of, uh, emphasis, especially from the US government on, on operating in a, is there a trust environment where effectively we say we, we don't want to have any guarantees provided to us by the network that we're communicating across, but we do need to do that ourselves.

And again, not to have to build that into the application and say, I, I know that I can speak to an end point and I'm going to validate that endpoint. I'm going to cryptographically verify that I'm speaking to someone who I trust rather than just simply saying it's at this air point end point and I've seen them before and therefore I, I'm willing to send my data to them. Very cool.

I'm curious your perspective on this too. Obviously software, supply chain security is a big topic, um, as it relates not only to open source, but all software in general. Uh, given obviously your experience coming, bringing this through Google and maturity of the other organizations contributing to it, what are the some of the best practices you may already be doing around software supply chain security that others could take away or benefit from by using sto?

I don't know that I associate the two things that there are many different aspects to security. In fact, I, I left Google, I now work at a security vendor called Armor. Mm-hmm.

So I, I'm very engaged in the space, but the software supply chain, I would say we factor all that in, in terms of the building of STO and how we take open source components and, and make our components available to other people as well and verify the pieces that we're running. We really think about that in terms of the build time and when an application is being built, when an application is being operated and run. It's not so much that any recompilation is happening at that point or anything.

So they are two different parts of the security ecosystem, but I don't really feel that there's a connection, a strong connection between the two when STO is operating. Okay. Very good.

Um, how about where, where, where's Istio going? Where, what's sort of the next, uh, you foresee the next six to 12 months of things that are at least on the horizon that you might work on? Yes.

We launched in 2017 with, uh, a, a new architecture. We've talked about sidecars before. So it was a, I think it was enabled easily by Kubernetes to say, when you deploy an application, deploy the proxy server alongside it and know that those two things will be tightly coupled throughout the lifecycle of your application.

In large part, that was the right choice at the time, but we've looked at how we can improve that and make it possible to deliver all the same functionality without needing to deploy that extra component with every workload without having to manage the overhead of that. And last year we released an architecture, which we call ambient mesh, which allows us to deploy a very lightweight component on each node, which handles just the layer three, layer four networking of sending things to the right place. And then per secure environment or per namespace within a cluster, we deploy the full layer seven proxy survey and we're able to do the higher level network functions through that for workloads that want to opt into that.

So the security can be provided at layer four, the network application stuff can be provided at layer seven. We decouple that in a way that allows it to be deployed by the platform team. So you don't have to think, I'm deploying my application, I'm, my sidecar comes along with it as a developer, but we, we call it ambient because we want it to be part of the environment.

It's just there. And that also means you can opt into those functions and, and opt into doing traffic routing and circuit braking and so on if you want to, but you don't have to say, right, I'm gonna have to redeploy my application and deploy a sidecar along with it to make it possible. We launched that Bit more efficient approach also.

Absolutely. So we see a huge amount of resource saving on that. We launched that in, in preview last year.

It's, uh, alpha in the last release of TIO one 18, and our goal is to get that to production readiness within the next 12 months. Yeah. Very exciting.

Well, congratulations on the accomplishments. Thank you. To date and of course more in the future.

io. What kinds of things will they find out by visiting the project site? Yeah, we have, uh, information there on why you might want to use a service mesh and why you might want, might want to choose STO as that we have the full documentation for the project.

We have our blogs where we talked about a lot of the newer stuff. A lot of the ambient content as that's being built out has been through blog posts. And then of course we have a link to today's announcement and the supporting vendors behind that, the people who have contributed to STO in the past and, uh, moved on to other things.

One thing we think is, is great about our community is people come and go and move to different vendors. Some stay involved with the project, some move on to some other things. Some go away and work on something else for a while and, and come back to the project.

So one thing we wanted to highlight with this was the people in the past who worked on it and, and their congratulations and their best wishes to us for finally making to graduation. Very good. Congratulations to you and all the supporting companies, and thank you individual contributors.

Well to speak to you again soon. Good luck on the next, uh, set of releases. We look forward to ambient ash.

Talk to you again soon, Craig. Thank you.