 Well, let's get started then. So thanks for joining my session here. We'll be talking about an interesting topic, I think. Something that comes up frequently. Maybe in the context more of Twitter and social media, more so than it does what I see in the market. But this idea that Istio is complex or too complex and that maybe you shouldn't use it because of that or whatever. But so my name is Christian Posta. I'm a global field CTO here at solo.io, where we focus on Service Mesh. We won't focus on Istio. We focus on application networking in general using a number of the technologies, open source technologies that you see listed here. But I've been involved with the Service Mesh space since January 2017. And I've seen it evolve. I've seen it grow before my work here at solo. And I've been here for almost five years now. Before that I was at Red Hat. And I worked with early adopters of Istio back then as well as a number of early and mid and late adopters here at solo. So I've seen a lot of the happenings, I guess, in the market, the evolution of the market. And I've seen Service Mesh deliver real business value to organizations that adopt it. So I want to talk a little bit about what is the perception Istio might have, why we got there, what the reality is. And as a viewer of this webinar, what are the things that you should be thinking about as you look at Istio and get you started on the right track? So you've probably seen this, I'm guessing, if you're familiar and paying attention to Istio. But if not, I want to cover it because Istio is a top level graduated CNCF project now. And this is important for a number of reasons. The first being, so here at solo, we've been watching Service Mesh, like I said, for about six years. And it wasn't until about 2019-ish, 2020-ish in that time frame, where we really started to see the Istio actually start to break away from the pack. Because before that, AWS has a Service Mesh, Hashicorp at that time in 2018, when we were watching it closely, Hashicorp announced theirs, Nginx was about to announce theirs, Linkerd was rewriting theirs, and there was just a lot of buzz going on. But in around 2019-2020-ish or so, is when we observed just sort of as a neutral party, we were kind of sitting on the sidelines at that point and saying, oh, wow, Istio, we're starting to see people actually adopt it at scale. There are use cases that they're able to hit because of some of the maturity that's happening in the project. And so people were adopting it, but it wasn't in the CNCF. And so that kept a lot of the vendors kind of on the sideline. You know, Istio had joined the open usage comments or something like that, and IBM put a statement out that, no, that's not good, Red Hat and all these others. But when Istio went to the CNCF, it almost signaled to the rest of the market that, hey, this is it. This is the winning project, if you will. You see a lot more vendors now willing to dive in and participate. You see Microsoft jumping in, which I didn't think that would ever happen. But the CNCF and the fact that it's graduating all this stuff is really lowered the barrier for more people, not necessarily end users. I think Istio was accumulating a lot of end users, but more people jumping in and continuing to push the innovation and the future of the project. Is Istio complex? I think a lot of what we see in the, I guess, in social media about Istio being complex, there's a history to it. And a lot of it, there's valid criticisms for Istio, certainly in the early days. It was difficult to use. Features would break from release to release. The API was still settling out. There wasn't that much of a focus on initial first touch experience. And for people evaluating new technology that's not all that well understood, that first touch experience is extremely important. But a lot of work has gone into these areas. Istio is extremely stable now. Istio's first touch, how a world, how do you get started? I think if you come here, if we take a look here, if we just Google, Istio is complex, right? From the first results, you'll see it's downsides. Why? Because it's one more layer within your stack. That's true, networking. Istio's complexity demystified, written by Lin Sun, actually walks through a lot of the stuff that the community worked on to simplify some of that early first touch experience. One command to install it. Analyzing, you know, an out-of-the-box analyzer that'll help you if you have misconfigured something, we'll be able to figure it out. Simplifying certain elements of the security policies and others, right? A lot of work has gone into how do we address some of the feedback in the community. And at the end of the day, the success of a service mesh is going to be seen through the lens of how many people adopt it. And for any one of those organizations, how many workloads can they get into the service mesh? And if you're putting this into production, you kind of have to be looking at it through the lens of, well, what do people who are taking these technologies to production, what do they care about? And, you know, you could go to the Istio.io website and you can look at all the features and there's a lot, which that might play into some of the perception that Istio might be complex. But I'm not going to focus on the breadth of those features, but I'm going to focus on things that people actually care about when they get into production. When you take a service mesh into production, you need to have these capabilities. You need to be able to get traffic into the mesh and you need to be able to limit or understand or audit what traffic is leaving the mesh. You will likely have the need for supporting VM workloads. Things like load balancing is maybe at the, you know, deeply buried in the list of features, but when you take a service mesh into production just on the website saying you have load balancing isn't enough. Things like, you know, locality awareness and priority in terms of how you're doing your load balancing. These things in production can actually save you a lot of money. Things like noisy neighbor controls. You know, when we're taking to deploy Istio into a cluster, there might be workloads there that are not going to be running in the service mesh. They might be doing things that might affect the workloads that you have running in the service mesh. So a lot of these things that you wouldn't, an open source project building a service mesh wouldn't know unless you actually put this into production and you're running up against those, I don't want to call them edge cases, because they're not edge cases. These are real cases. And Istio has gone through a tremendous amount of maturing around these real cases that enable it to run in production. Because if you take, let's take the counter example. If we made Istio just so, so simple, let's make it the simplest possible service mesh so that we could avoid some of these these memes. And we just focus on just the basic stuff. Getting services to connect to each other and securing them with MTLS, ignore some of the other stuff. All right, so now you take this and you put it into production. You still need to solve the ingress problem. How is traffic going to get into your system? And what options do you have there? Well, you could go, I don't know, you could stand up on boy, stand up HAProxy, stand up Nginx or any, you know, traffic and some of these. So, okay, so you put ingress into your cluster. All right, that has a different API than what Istio does. And solving the problems at North-South are very similar to solving the problems that you're doing in the service mesh. You want that first hop from the ingress to be secure. So now you have to go figure out and configure that ingress so that, what, that there's mutual TLS or TLS or so. There's some configuration and I know some proxies handle headers a certain way and is this the host header? Do we need to map it and change it? There's a lot of, you know, additional things that you have to think about. A different, completely different API from now the mesh for essentially solving a very similar problem which is, hey, I want traffic coming from a system into my mesh. I need to control it. I need to secure it. All right, well, in a lot of enterprises, they care deeply about traffic that's leaving the mesh. How does it leave the mesh? Where, from where does it leave the mesh? What policies, you know, we're talking to these external services. We might need to enforce some amount of rate limiting or a certain way of securing those calls. We need to, we need to bring ingress into the, into the picture. So, all right, let's bring in another thing for egress, whether it is that another proxy, is that a different API and now we got to map this and marry it to, to the mesh and to ingress and now, you know, most enterprises, most organizations are not going to deploy one single cluster of Kubernetes or of anything and now we want to take this pattern that we've built of cobbling together ingress, cobbling together egress, trying to tie it together across multiple clusters now and now when we get into a multi-cluster scenario we kind of need, you know, multi-cluster traffic. So do we introduce another component to handle multi-cluster traffic? How do we get services in one cluster to know about services in the other cluster? All right, so maybe we introduce this this replicator thing that watches for endpoints in another cluster or replicates them locally. You can see as you start to go down the path of building a production worthy, you know, deployment of a mesh, there's a lot more pieces that go into it and if you start with the premise, well I'm just going to take this one simple service mesh and take it into production, you're going to very quickly find out that that's an incorrect premise, you're going to have to build all this stuff now and last but not least, you know, tying this into VMs, what does that look like? What API do you use for that? Do you build more replicators and more pieces to kind of cobble this together? So if your focus is on, well, you know, Istio's too complex because it does all the stuff that I need in production, so we're just going to take this simple service mesh and now we're on the hook to build all this stuff. Which one's going to be more complex? All right, at the end of the day, networking is complex. Networking certainly for application developers who want to use a platform to build and deploy their services and get the benefits of security, of, you know, traffic control and observability and all this stuff, they might not care about some of the lower-layer networking pieces. So the service mesh is a networking component but how you use it certainly can be simplified. Like I said, a lot of effort has gone into some of the initial hello world, you know, how do we, so we have this mature set of features in Istio and what we were missing for a long time was that initial getting started experience. A lot of that has been corrected, but also understanding if you're going to take an open source project and bring that into an organization that you're going to have to invest. You're going to have to invest your own time and educate yourself, be familiar with the project. You're going to need to get involved. Open source projects are not commercial products. You have to go get involved. I highly recommend getting into the Istio Slack, getting into the Istio GitHub repos and participate in opening issues, commenting on issues, asking questions, you know, these are all all good things to help you build up your familiarity with, but this takes time. You know, there's a number of books, you know, this is my my session, so I'm going to plug my book, but there's a number of books about Istio workshops, labs, certifications, you know, if you're going to adopt an open source project it might be looking worth looking into vendor partnerships and so on, but to really be successful you've got to be thinking about Istio in terms of an iterative or phased adoption, right? Nothing, there's nothing about networking that or it makes sense to just adopt and try to, you know, pack in as many different features as possible. I know the enterprise kind of sometimes thinks about it like this, because when they go get funding to be able to do a project, they want to show, hey, look at this massive ROI that I'm going to get and to do that you have to list out a massive list of features and so some of this might get, well, you know, you know, Kubernetes and Istio and all this stuff does, I can do a million different things, but start off small. Start off with what we recommend here at Solo is start off with just the Istio Ingress Gateway. That is going to, you're going to start using the API, so getting familiar with the API is important, you're going to get familiar with the data plane, Envoy proxy, which is extremely important, you'll set up some basic things that you expect like TLS termination and so on, and from there you can start, so the big reason why people will adopt the service mesh, the first big reason is for the security properties, for the zero trust security properties, MTL, if you're getting client, getting mutual authentication between services, getting encryption, getting fine-grained authorizations in terms of networking policy, move in, then move into that area and Istio has done a lot of things to be able to iteratively adopt that from just getting things installed and audited, and then switching to a mode that enables MTLS to finally getting to a mode that requires MTLS. So there's a phase even a phase approach for adopting that. So thinking about this through the lens of iteration and phase is extremely important. Abstraction matters, you know, with a lot of the focus on supporting real production use cases, the API that Istio has built is extremely powerful, but it is not something that, at least in my opinion, that at scale you just hand out to every developer and every person trying to use Istio. Ideally, what you do, what an organization is shooting for, is something like this, where you have an internal developer platform and platform teams and engineering around that, that these IDPs, they help you go understand what services exist out there, maybe there's a catalog. How do I get started creating a new service, a new API? For those existing services, where are their documentation? How can I, you know, kind of review their SPAC, their API, and all that and start consuming? How to, maybe there's a brokering mechanism for, hey, I want to consume your APIs. What's the workflow for getting approval to do that? And then, how does that automate setting up all of the back end infrastructure to support that? This, you know, this sort of platform engineering approach to adopting, well a platform in general, where Istio might be running, is the same approach that you take to using Istio scale. What we, what we want is to provide guardrails or golden paths, I think is the term people use in platform engineering, lingo, to enable users of this technology to be successful. So what that means is, you don't expose the entire, you know, feature set account, you know, API directly, like the virtual service and destination rule, for example, API directly to, to your end users who might be writing Java code or Node.js code. I've seen a number of organizations build template, basically templates, templating a simple thin templating engine that allows, hey, you can configure these pieces and that will also keep you from colliding with other users. So there's some, some amount of organizational tendency in there. And that simplifies what the actual developer sees and what they can configure. And then the rest of the platform workflows and automation and CICD and all of that stuff takes care of actually configuring and deploying things at runtime. Now this is, look, I'm not saying you shouldn't understand Istio, I'm not saying that, you know, the, that it's not like nobody, you can't, it's too complex to understand. I'm not saying that, I'm saying it's extremely powerful, that it belongs at the right layer and automation is your friend here. And of the organizations that we've seen adopt Istio at tremendous scale successfully, this is a, this is a very common observation. Now you may have seen a number of, of talks, I'm guessing at IstioCon here that talk about Istio Ambient, because that is the, that is the future of Istio. Istio Ambient is the side carless implementation of Istio and a big motivation for how or why really we built Ambient is, you know, further refining this simplification of day two operations of first touch experience of onboarding some of these areas that, you know, could still use work with the Istio deployment that we know and love that's running at massive scale and delivering tremendous value to a lot of organizations today, we need to deploy a side car. And side car deployments, you know, they are not just a networking concept, there's a number of different reasons why you might deploy helper containers to work alongside a, you know, a main application or main container, whether it's logging or telemetry or, you know, additional things. And networking is, is no, no different. However, there's some nuances that, you know, that, that you run into when you're deploying a networking side car next to your application that can be avoided. All right. And if we can make it a lot easier to onboard applications into a mesh, that's a big win. If we can, if we can make it so that we can upgrade and patch the mesh quickly, that's a, that's a big win. Now, those are all, you know, some of the original motivations for building Istio Ambient. But one of the biggest benefits I think that I see resonating with, at least with our customer base here at Sola, but in, in general, I think what we're going to see in the, in the community as well is that this approach uses fewer resources as well. And we get the same, if not better, security posture, you know, obviously better operational model performance is at, at worst, the same as side car. And so we see this as a, a big, another big step toward just eliminating some of the challenges, the nuances, the details that people had to understand to get this, to work correctly and, and run it in production at scale. So Istio Ambient is a, is a big step in, in that direction. A lot of, a lot of benefits that come with this. You know, I'll let you read this slide, but, but a focus on operational improvements, a focus on security and a focus on cost and, and resource usage. I think there's a big wins to continuing to simplify Istio. So wrapping up here, the point I wanted to make is that networking is hard. For those people that are not network engineers, right, that a service mesh once taken to production actually has a lot of things that it's got to, got to do and worry about. And this idea of a quote unquote simple service mesh is make believe that, you know, Istio has focused on a lot of these, these nagging, hello, you know, first touch experiences and getting started, hello world type experiences to kind of reduce some of those, those rough edges, because Istio's main focus is on stability and running in production, maturity, getting those, those real cases, not edge cases, those real cases sorted out and solved because people are actually running this in production. That the, the most common approach to success is to iteratively adopt the features in Istio. You can't just slam the whole feature set in there and start small, start with ingress, start with MTLS and build up from there. Things like side carless Istio ambient mesh are making it even easier now to do that. Starting with MTLS is, is not only easier, but comes with a lot less risk when doing it with, with Istio ambient because you're not adopting the entire side car and all the details that go along with it. And lastly, put things at the right layer, abstract them away, just like we do other things, and invest in your platform engineering efforts. Running Istio at scale is going to require you to build those golden paths for your end users, your developers, the rest of your organization, etc., to, to get into these features that Istio provides. And then all of the lower layer configurations, you know, that can be automated away by the, by the platform. So that's, that's my session for today. Hopefully that was useful. If you have any comments or questions, I'm available on, on, on Twitter here. You can see my handle here or on email at Christian at solo.io. And I appreciate your time. I think I might have a minute or so for questions. Not sure how I'm going to see those questions. But if not, I appreciate you. And thank you for, for joining