 All right. Mike works. Hello, everyone, and welcome. Thanks for joining in on this session on the STO Maintain a Track session, where we're going to discuss the future of STO, whether it's sidecar, sidecarless, or both. It's been an exciting week so far for us. Those who are in the STO community to see so much enthusiasm for everyone, talking about STO, discussing where it's heading, and more importantly, seeing the amazing adoption we have in the community. I know it's late. It's 4.30, and probably this is the last session of the day, so all of you will be going out for drinks. And Lynn just told me this is the most comfortable chair in the conference hall. So it's fine. If you want to fall asleep, at least you're falling asleep on the comfortable chairs, all right? So just two quick questions, if I can know by show of hands. How many of you are using STO in production? Oh my God, that's a lot of people. All right, we should have taken a picture. All right, sorry. I have to repeat the first question again. How many of you are using STO in production? Awesome, fantastic. Second question, which I won't repeat again, maybe. How many of you are STO contributors? Hold on, don't raise your hands. By contributions, I mean a Slack message, a GitHub comment, a Discuss comment, a GitHub PR. I know you are. All right, how many? Raise your hands. All right, awesome. For the rest, we'll try to get you into the community after today, okay? All right, so let's get started. First off, I am Neeraj Poddar. I'm head of engineering from Solo. I've been a long time leader in the STO community. I'm an STO technical oversight committee member. I'm a former STO steering member. You can find me on LinkedIn and you can find me on Twitter. So please reach out, happy to chat about anything and everything related to STO service meshes, cloud native community. So today what we are gonna do is look at the adoption of service meshes, focus in on STO. I was amazed to see so many STO production users here. Then we are gonna look at some of the roadmap that we have laid out for 2023. We had a session earlier which talked about it. Then we are gonna try to answer the question which is the title of this session, which is whether the future of STO is Sidecar, Sidecarless or both. And then we also gonna look at the growth of the STO community in general, how many contributions have happened over the last year, so on and so forth. I'm very excited to have you all here. So with that, let's get started. All right, so these are the only two slides you will see which are marketing slides taken from the CNCF survey, right? So this is the survey done last year in May, I think, 2022, which tells what are the growth areas in Kubernetes, what are the technologies which are constantly growing, people want to adopt, and people want to put in production. As you can see, service mesh has been growing year over year, 33%, right? And it's truly remarkable to see just from the people here that how many of you are using STO in production. Another graphics from the same survey is how much is the actual production usage? And this verbiage in the top is actually taken from that blog, which was surprising to me where it says technology adoption is much greater than previously thought. You hope so, right? That's why we're making a technology. So if you see in this graphics, it clearly says that in 2022, we have 47% of the users who are currently saying that they have service mesh in some form factor in their production environments, right? And this is critical. The service mesh technology was built to make sure we can give decoupling to developers and operators. It's an infrastructure layer to solve communication between microservices, allowing both developers and operators to be successful at their jobs. Developers can add business logic to the applications. Operations team can provide security, resiliency, visibility into the traffic that goes between microservices. So really great to see that the technology itself is getting so much adoption. And with that, if you look at STO, STO is by far the most adopted service mesh platform, right? The number of production users you have, the thriving community we have, and it's all thanks to the amazing maintainers, contributors who are day in and day out working with us to make sure that STO is the best product service mesh platform out there. So these are just some of the numbers. So if you look at the community right now, we have 412 active members and this number keeps on growing. We have 59 maintainers. And this list actually is a lot longer. We just sometimes have to prune the list and it sometimes shrinks, but there's a good core of maintainers who are making sure that STO community is healthy. The project has good standards for code, for security. We have 13 working group leads. These leads are functional experts in various domains, making sure we are technically going in the right direction. The TOC members, along with me, we have three other TOC members sitting over here, Mitch, Eric, Lynn. If I say something wrong, they're gonna come and correct me. But these are from four different organizations, right? So we have a lot of diversity in the TOC community. If you look at the steering committee, we have members from eight organizations, right? So when people look at what makes a thriving community, for me, it is not just how many contributions are there from lots of different people, but also a lot of contributions from different organizations. Because we want the diversity to keep the community growing and be as neutral as possible. And then this is the stat that I got from the CNCF site again. If you look at just last year, it says 410 contributing companies. And again, contributions here mean anything and everything with Istio, a PR comment or a GitHub issue open. So lots of participation, lots of adoption across the board. And this is just a quick, quick snapshot, again, taken from the Istio docs. If you go there, you can find a massive list of Istio users, right? This is not the entire list. This is just the smallest screenshot I could take. So if you are an Istio user in production, I will highly recommend submit a PR to Istio IO doc where you can add your company logo. You get some visibility. We get more information on how Istio is being used. It helps us improve the Istio project. All right. Oh, this also happened last year, right? I think I have had so many conversations over the year where people have asked me, why is Istio not in CNCF? One of the best thing this has done is nobody asks me anymore. Istio is now part of CNCF. Even though Istio project and the Istio community was always neutral, the Istio project was very well adopted, lots of diversity like we showed. Putting it in CNCF, just make sure in future it continues to remain so. We are all very excited as part of CNCF, right? So we are really glad this happened. We are gonna go through the maturity, graduation phases, whatever it is, even though we have lots of Istio production users already, and we'll make sure we become a graduation project whenever all the various qualifications are met. All right, let's see, right? 10 minutes then. All right, so this is taken from the roadmap session that Lynn and Louie did, I think it was two days ago. So when we set out for any planning in Istio, we can't come up with a concrete roadmap, right? We have contributions from various companies, some independent people working on Istio. We can't really tell them to specifically work on this or don't work on that. So what we try to do is come up with themes so that we can align the various efforts as organically as we can to make sure we're all heading in the same direction, right? And over the years, the themes for the Istio project have gone in only one direction, which is to make Istio boring and predictable, right? I think many of you must have used Istio in early days where it was unpredictable and exciting. I don't think we want our infrastructure to be that, right? How many of yous Istio before 1.0? Oh my God, you were hurting, aren't you? All right, so that's why we put some concerted effort towards making it boring, making it predictable, making it more stable so that all the burden of managing and maintaining Istio is as less as possible. So themes for this year were, can we accelerate the time to value the service mesh? Can we make the value that customers and users get out of service mesh and Istio, which is, can most of the users want MTLS? Can we make the transition from zero security to MTLS as easy as possible? Can we make that adoption seamless? The total cost of ownership. Typically, Istio has been tagged with having a lot of higher cost of ownership. We want to make sure it's significantly reduced and the value that organizations realize from Istio is very high. And again, some of these technologies are evolving as we are learning from your users, right? You're giving us feedback and we're improving the community. And the open community growth, this is fantastic to see so many users here and the community is just fantastic. It continues to grow with us being in CNC. If I don't think there's anything stopping us. And then the last being continue to be boring and predictable. So with these themes, what we do is we identify certain focus areas on which we try to concentrate most of the effort of the maintainers in the community. So a big drive for us in 2023 is to get ambient mesh to production. I'm gonna go over the basics of the ambient mesh architecture. I think you all have heard a lot about ambient mesh throughout the week and before, but it's good to understand again the fundamentals and then answer the question, what's the future of Istio? Whether it's Sidecar, Sidecarless or both, right? So the gateway API in Kubernetes is maturing. We want to make sure we continue to participate and be the leader in that API in those conversations. The gamma API is another initiative to make sure the gateway API conforms well to the mesh architecture in the mesh needs. Many of us from the community are involved in that effort. And again, we want to continue the stability in future promotions. There's a long laundry list of features and APIs that are currently in alpha or beta state and want to continue to promote it. And then the last thing is really important for a thriving open source community which is how can we integrate natively with other cloud native projects? How can we integrate with other standards? We want to be a good citizen in this community and play well with projects like Spire. We saw some native integration last year with Spire. We want to integrate open telemetry. We are already working with Prometheus, Yeager. So what I would recommend is, please go and look at the session recording that Lynn and Louie did if you didn't attend the roadmap session. It has details on each of these topics which I can't go over in a half an hour I have. But if you can't look at the recording, please look at the slides because it will tell you what we are planning to do in 2023. All right. So let me lay out the groundwork of why Istio went from sidecar proxies to the ambient architecture. And again, this is based on the learnings from our users and customers. Many of us, whether in the open source capacity or in our own organizations, have been working constantly with customers, getting feedback of what are the challenges of adopting Istio, right? So three areas that we often see customers struggle with the Istio sidecar proxy architecture. So one is operational complexity. So in Istio, the sidecar proxy is added as another container in the same pod in which your application is running. And we create IP table rules to make sure the traffic is intercepted and sent from the application to the sidecar container, right? So the operational complexity involved with this approach is to add the sidecar proxy, you have to restart your container. You have to restart your pod. So the application onboarding here itself sometimes presents a challenge for the operator who wants to make the Istio service mesh as transparent as possible, right? I mean, you have to go to your applications team and ask them, can I restart my application? You don't know, maybe they're saying they do stateless things, but how many of you are doing stateful things in the back, right? So none of the operations team want to do that. When you have to upgrade your proxy, you have to again go and restart. If you have 20,000 pods, you restart 20,000 pods. That's a lot of pods to restart an orchestrate. So that created an operational complexity for our adopters, right? And you want to make sure the proxy is as transparent and application should not be aware of it, right? The second thing is the overhead that adding proxies in the sidecar containers, a sidecar containers, how much is the overhead in terms of resource utilization? So the way Istio by default is configured. If you have a large cluster, we are going to discover everything and configure the sidecar proxy so that it can reach to each and every service in your cluster. Now you can add sidecar scoping resources to make sure the onboard proxies are as efficiently configured as possible, but many times many organizations are not doing it and it's difficult for them to do it. And what ends up happening is the memory consumption and the footprint of that proxy is pretty high. When you add it on every side, when you add it on every pod as a sidecar, that can grow exponentially. In fact, just today, I was chatting with a customer and he was like 40% of our resource utilization right now is onboard proxies, right? So we wanted to think about this problem. We want to give the same benefits that we are providing to our users. How can we do it in a much more resource-efficient way? And the third is as the packets are traversing through this multiple proxies here, all of them which are doing layer seven parsing by default, we have seen that the latency that is added by the proxy can build a little bit more. We also wanted to optimize that piece and see how can we reduce the latency by coming up with some better architectural additions and architectural patterns here. So these are the problems we're trying to solve. And if you look at the history of Istio, it's not very uncommon for us to change things, right? So we started off with telemetry architecture. How many of you have used Mixer? All right. We started, that was the telemetry V1 architecture where we are sending attributes to a centralized service called Mixer, which was used for decision-making, for policies, and also transforming it for metric generation, right? The architecture itself was pretty good, but many customers and users were giving us the feedback that the operational aspect of it was not as efficient as it could be. We also went from a microservices-based control chain where we had galley, I think there was a citadel. I can't even remember now, it has been so long. And all of these components, which all did very little things, scoped things from a security point of view, it made a lot of sense, but again added a lot of operational complexity to our users. So now we combine all of them and call IstioD. So the point I'm trying to make is a good thriving community is always looking for ways to improve our experience for the users, listen, and change things as it needed. So in my opinion, ambient architecture, the sidecarless architecture, is this next step in the journey of evolving Istio. So last year around, I think middle last year, we announced Ambient Mesh. So Istio Ambient Mesh is a new architectural pattern in Istio where you can get the same benefits that Istio provided, but in a sidecarless data plane. And the aims were basically to solve the three problems that are listed before. So you want to simplify operations, you want to make sure the cost and the TCO for running Istio service mesh is less. And then if we can get some performance benefits, we should be able to pass that all along to our customers also. So you can read this blog where it was announced, it goes into details of these motivations. But here what I'm gonna cover is what is this architectural shift, what does Ambient Mesh mean for you and how it is providing these benefits. So there are two key components of Ambient Mesh architecture. So first is called Zeternal. This is a per node proxy. This proxy is added on every node as a demon said, instead of a proxy added as the sidecar proxy container. This proxy is a very small proxy built to do only one thing. And it's job is to do layer four transport. It is not going to do layer seven parsing. So you have a reduced surface attack vector here. And then the next thing it does is encrypts the packets that comes from any port within the node when it is going out of the node. The Zeternal on the other node will decrypt it and send it along to the pods on that node, right? The same thing happens the other way. So in this architecture also, the pods that are leaving the node on which the traffic that is leaving the node on which your pods are running, it's never unencrypted. They're always encrypted. Another important distinction to think about is what is the certificate? What are the certificates used by Zeternal when it is encrypting the traffic, right? You don't want a generic certificate because you want to do policy enforcement on these identities that you have created. So for that, we are still using the pod spiffy identities. So when the traffic from app A talks, when app A talks to app B, the mutual TLS certificate that will be used by the Zeternals will have the spiffy ID of A and B. It won't be a generic Zeternal spiffy ID. So that's something that's very important for everyone of you to understand how encryption works. The second part of this is waypoint proxies. So if you're doing layer seven policy enforcement, you want to do layer seven traffic routing or you have to open the packets for whatever else you want from the service mesh, that is done in the waypoint proxies. These waypoint proxies can be created anywhere in your infrastructure. It can be on the same node in your application is running. It can be outside. It doesn't matter. These are tied to the service accounts for each application. And you can scale them depending on how your consumption pattern is for that application. And these can be on demand. You don't have to provision them if you are not using layer seven primitives. So this is a very, very flexible architecture. And now if you think about it, how did we get the three benefits that I wanted to say? So first is operational simplification. So Zeternals are running on your node. They are not running as sidecars. So you don't have to restart to inject. As part of the operations team, as part of the infrastructure team, I can just add the Zeternal in the node and the application is not even aware of it. We still use IP tables for traffic interception between the pods on that node and send the traffic to the Zeternal. But the CNI, which is responsible for configuring those IP tables, is no longer working in the pod networking namespace. It's actually working in the node namespace, node networking namespace. And that's very significant because that allows you to add these rules before the fact, right? When the sidecar and the application were coupled together, the CNI itself can only add rules to send the traffic and the sidecar proxy has to run. So it used to create coupling between those two things. That's no longer needed. So it's a big operational simplification to make sure these sidecar proxies are no longer needed. And you have Zeternals doing mutual TLS. Secondly, the Zeternal proxy itself is in Rust. It's very lightweight. So in the initial testing we have done, we are seeing a significant reduction in memory consumption compared to the sidecar proxies. Yeah, so that's gonna lead to your cost reduction in terms of performance. Another interesting thing what we are seeing is instead of having two layer seven parsing done in two on-way proxies, a sidecar, when you are doing L4 transports, which are very optimized, I'm gonna talk about how the L4 transports are gonna configure here and one layer seven proxy with a waypoint, you're still gonna get performance benefits. It might be counterintuitive because there are three proxies instead of two, but it depends on how much work each proxy is doing. So that's some testing we are still doing in the community and we'll publish results as we know more, but the initial results show promise. So very quickly again, if app A is talking to app B and you don't have any layer seven requirements, it will just go through Z-tunnel. H-bone is the HTTP based overlay network encapsulation. This is an H2 tunnel that we create to make sure we can encrypt and every packet that goes over two nodes is always encrypted using mutual TLS. It's not a new fancy protocol that we have created. It's still just using H2 tunneling, but we like to make name names, right? So we create a new name for it, H-bone. And then if you are going through the waypoint proxy, so for example here, app A talking to app B, you might have some layer seven authorization policies written here, then the Z-tunnel will talk to the waypoint still through the H-bone encapsulation. So the basic paradigm that you all have to remember is any time a traffic leaves the pod or if it has to reach to a pod, it has to go through Z-tunnel, right? So many times people are getting confused when is Z-tunnel used, when it's not. In Istio Ambient, for every traffic leg going in and out of the pod, it has to go through Z-tunnel, all right? So one important thing that I wanna cover is, a lot of you folks are asking is, is Istio Ambient Mesh Secure, right? So there was an excellent talk done by, I think John and Christian yesterday in which they covered various aspects of Ambient Mesh Security, right? And when we are doing security analysis for Ambient Mesh, we have to cover various aspects. When you're looking at threat modeling, what happens if the application is vulnerable? So if the application can bypass the sidecar proxy, it actually can bypass all your policies. But if you look at the Ambient because the enforcements are happening at the node level, if your application is compromised, it's still hard for it to break out and bypass the proxy. So you actually get a security benefit out of it. There are various other modeling that we have done and believe me, we won't be recommending the Istio Ambient architecture wasn't as secure. Again, it's very less time to go over all the aspects of it. I'll highly recommend to look at Christians and John's session here. It goes into the nuances of why Ambient is as secure as sidecar. And the last thing is what we all want to understand, right? Where is Istio heading? What's the future? Can sidecar and Ambient coexist? Well, the answer is yes. And actually there is a requirement for both to coexist. So waypoint proxies are currently added only on the server side. So if you have client side L7 requirements, so if you want to do some client side rate limiting, for example, or client side L7 persistence, you will currently need to have sidecars on them. So this is not a functional gap as per se. This is an architectural decision we made. In terms of requirements and use cases that users have from a service mesh and especially like Istio, mutual TLS is by far the most important thing that people get out of it, right? So that's why many of you will be running Z tunnels and get mutual TLS. And if you need, you can have L4 access policy enforcement, authorization policy enforcement through it. Then next comes, if you want layer seven authorization policies and some chart enforcement for your services, that can be achieved through waypoint proxies because these are enforced on the server side. But if you have more requirements for client side layer seven policy, that's where you still need sidecars. And the architecture was built to make sure both can coexist. It also provides you a migration path, right? You don't have to have everything moved over at once. And we have done fair amount of testing and migrated people off. So this is a very good architecture for you to have. You can have some on sidecar, some on sidecar less. You can decide depending on your use cases how you want to run. And the key here is you are still getting the operational flexibility. It depends on your use case. You get the performance benefit and you get the cost flexibility. All right, I think I'm on time, more or less. All right, so last thing I'm gonna say is how can you get involved with the community? How can you help us make it better? Please join Istio Slack. Lots of conversations are happening if you just need help with your production environment or you help stuck in your Istio configuration. You can always reach out for help. There are various conferences and webinars that we are doing on Istio. So please attend those events. You can report bugs, security vulnerabilities, and obviously, if you are a code contributor, you're welcome. We love people who file bugs, then fix them. And then please participate in the working groups and TOC meetings. I think the TOC cadence is now once a month. So there's a lot of technical decisions and the project directions being shared there. So please attend them. And lastly, what I would say is any good session nowadays should end with some chat GPT on it, right? Otherwise, it's not a good session. So any guesses what I did? It's not as exciting as you all think. So I went to chat GPT and said, create me a poem on service mesh. And it actually did a pretty damn good job. Remember, chat GPT is still serialed by data from 2021, I think. So it might not have all the new shiny nuggets, but it's pretty accurate. I can't wrap, so I won't try it. Thanks, everyone. And I'm happy to stay here. If you have any questions, please reach out. We have more TOC members, Lynn, Mitch, Eric, you wanna come up, we can answer questions together. Thank you. And amazing to see you all here. Please give feedback.