 Hello, and welcome to this special edition of the CNCF webinar series. We're going to talk about service meshes today, specifically how to manage them with confidence. We're going to talk about the service mesh management plane called Mechory. Mechory has just entered into the CNCF. It has actually been accompanied by a sibling project called service mesh performance. And so these two are, well, certainly part of the latest batch of projects to enter into the CNCF and probably, you know, arguably the hottest batch to enter in. So, so we're going to talk about some hot projects today. My name is Lee Calcote, and I'm joined by my esteemed colleague. Hey, I'm Navidu. I'm an engineer at Layer 5. I'm also one of the maintenance of the Mechory project. Nivendu and I spend a lot of time focused on service meshing. And Mechory is the sort of the largest open source project that we spend time on. So in the service mesh community at Layer 5, there's a lot of cloud native application networking that goes on. There are a few projects that satellite Mechory. And so we'll touch on a couple of these projects today that they are important to Mechory. Some of them are extensions to Mechory. Some of them stand alone. But we're going to get into this fairly heavily. There's a number of CNCF logos that you're seeing on the screen. Some of the projects are now are donated to the CNCF. And some of these are initiatives that are hosted within the CNCF service mesh working group. We'll talk a little bit more about that group and how you can get involved in not only that working group but also in Mechory here toward toward the end of the session. So with that, you know, we'll also say like the community that these projects are built within is alive and kicking. And Mechory itself has a little over 300 contributors, about 15 maintainers like Nvendi was saying. He is one of those. There's a, we're, you know, fortunate to have a diverse community and one that's, you know, includes some well some names that you might recognize a couple of others from Red Hat, Rackspace, Intel, or Hashi Corp and a variety of places so that there's Mechory's that the project itself has a, you know, a large vision. We'll talk all about that. Mechory also participates and has for a couple of years now in the LFX. Well, I guess before it was called LFX the Community Bridge, but the LFX mentorship program. It's actually ranked the number one mentorship project. So, so that's certainly a point of pride for some of the mesh mates in the layer five community. We're coming up on about 1000 users, 1000 folks. Doug their teeth into Mechory's that's helpful as well. You'll notice one of the things that I'm down here is this statistic about performance tests. Has a number of feature areas a number of aspects of a service mesh that are managed and one of those initial areas was focused on performance and the built out of the desire to analyze the performance of a mesh, some of the characteristics around running service mesh is efficiently. And so there's a number of anonymous performance tests results that are collected as, as users send those in, and they are to be they are to be presented for analysis as part of the CNCF service mesh working group that we were talking about before. And as we will unfold like what is a management plane probably would serve us well for a moment to just talk about network planes in this regard and so if you know to characterize a service mesh. I'm at a high level, architecturally there's generally two planes that a service mesh is comprised of one of those is the data plane the other one is the control plane. The network engineer, or a died in the wool network engineer at these terms are probably really familiar to you as well as like the term management plane. If you're not, but you spent some time around Kubernetes and other systems in the cloud native ecosystem. These terms probably aren't too far removed or you probably have some familiar airty with what they do. And so for in the land of service matches the data plane is really. It's really the collection of intelligent proxies that you know work in unison and work under the control of the. Well I just use the term to describe the term I want work under the control command and control of the control plane control plane. And to speak generically to what a control plane does for a service mesh is really like configuration management of these intelligent proxies. The proxies are something of the workhorse they're lifting the packets and inspecting them sending them sending the packets along their way. And then them denying them injecting chaos doing you know securing them doing lots of things to requests to packets that flow. So a lot of control that a service mesh brings to. Well, to you the user, a lot of insight telemetry security, you know observability within there, a lot of power in the network. The service matches it's sort of something of a next gen SDN. Which becomes really important when you're running distributed systems and the network is fallible. Unfortunately, it's mostly DNS but the network, the other aspects of the network are fallible as well. So a management plane. So what can do any number of things, but essentially help you integrate service meshes into your back end systems. Take full advantage of some of the power of the network, perhaps help federate various service meshes, maybe help you implement chaos, implement and perform chaos engineering well, or advanced traffic canary, the engineering of your applications. Deeper insights into the performance of your applications and to the performance of your infrastructure, maybe to bring about change management or workflow to to things that transpire in a match like there's a long list of things that are possible to do and part of those possibilities are brought about by. Well, intelligent filters that can be loaded into each proxy. That's running in a match we'll talk about what we'll talk about WebAssembly a little bit and, and we'll talk about some of the the proxies that support WebAssembly and some that don't, but are still extendable, still have a plugin model in which you can dynamically insert different traffic filters to want to do a number of things. So this is the wheelhouse of measuring these are the things that measuring as the service mesh management plane. It's area of focus to articulate that a little bit differently. Well, it performs a number of things around life cycle management of well of 10 different service measures actually. So there's been a lot of time invested in building out adapters service mesh adapters. So machinery supports the logos that you see below, and has one adapter for each of these service messages there's a couple more that are on the roadmap. And so we'll, we'll see how long it takes to get those out. But so suffice to say, machinery does life cycle management of those service measures, but also those workload management or application management so it helps you on board and off board your applications onto the mesh. So this is performance management, fairly deeply today, and actually just to give everyone a sense of where measuring is at in terms of its roadmap and its measuring current release is in the V zero dot five range. You know, if the proverbial you know if the one dot oh is sort of the proverbial mark by which it's architecture complete, then measures about halfway there. So it's not a not a small project. So it does configuration management of service measures themselves. And hopefully, and, well, encourages you or enables you to be operate your mesh with confidence. And it also has an emerging concept being built into it right now. And that's around service mesh patterns. So there are best some best practices that machinery has built into it to help analyze your runtime environment of your mesh, and inform you of whether or not you're doing it right or you're doing it wrong, but it also has the concept of a pattern, we'll get into those. So this is Web assembly filters as well. And so, well, I guess we should say briefly that just kind of to the note that's here that there are a couple of service mesh, well specifications. Perhaps, maybe one or two or three of which there's there's really three we'll talk about to maybe two of which that you're familiar with so SMI service mesh interface. Measury has been was an initial launch partner with SMI and continues to be very much involved in SMI will talk about some of its involvement. Measury also implements service mesh performance. That's a second specification. We'll talk about that as well. With that, that's might be a good time to end you took to let people poke around misery a bit. Yes. Thanks Lee. So what you can see is the misery dashboard. So, we have entered and deployed a couple of service measures already. So, as we mentioned, misery helps manage, helps manage the life cycle size measure so you can provision the provision service measures applications and all those other stuff on your cluster. Measury also connects to your Kubernetes cluster automatically and it also discovers services that are already running inside your cluster, even if you deploy it without measuring. We also have adapters specific to each service mesh. So each mesh has its own set of features, some service mesh may have less features and some even more advanced features. So, misery to leverage the maximum functionality from each service mesh misery has separate adapters for each of the service mesh. Measury also lets you integrate with your Prometheus and Grafana add ons. So you can import your existing Grafana dashboards to misery and use it here as well. So, so when you first start misery, we also have a configuration wizard which basically walks you through the entire setup to get misery up and running. So, by the end of this, you, it will make sure that you have a working misery running on your cluster. And if you want a more finer configuration, like you can configure your environment through settings and you can configure service measures, you can configure your metrics that Prometheus and Grafana and some users also use a measure is performance texting capital capability very extensively. So you can define your performance test to be used to be around repeatedly to be used. So, and we'll look at some of these stuff. In a couple of minutes, but as a machine he has all these functionalities. Back to you. Yeah. So speaking of measures functionalities, it's. So the project takes to heart this the concept of being extensible. So the misery is something of an extensible platform. So this is this slide is an exploded view of some of the internals of misery and how it works for some of the components inside of it. And it highlights the notion that there are any number of extension points areas where new adapters can be added additional load generators can be supported measuring supports three types of load generators today, or where out of the box patterns that we'll talk about in a little bit can be additional patterns can be added additional best practices can be ingested. Some of the simply filters can be added and so in this way. Yep. Actually, actually something of an extensible platform. There's a couple of deployment models that are that mastery supports. So to put it concisely measuring deploys as a set of containers, you can choose to deploy those containers in your Kubernetes cluster, or outside of your Kubernetes cluster on a Docker host. We find that some users. So the decision one way or the next in part based on what how intensely they're using measuring to analyze the performance of their clusters the performance of their meshes. Sometimes a desire for that load to be generated off cluster or in cluster, maybe in a separate cluster. So measuring affords that choice for users. Each Kubernetes cluster is the recipient then of the measuring operator inside the measuring operator is a custom controller called mesh sync. It helps keep measuring a prize of the various changes that are going on to the service measures of various changes that are happening within Kubernetes itself. In this way, measuring supports not only green field deployments like so deploying service meshes itself. It also supports connecting to existing service mesh deployment so Brownfield deployment so it will discover your existing deployments as well. There's an extensible concept and mesh recall the provider. And so providers can do typically offer a layer of persistence. So to the extent that the user that users are running performance tests intensely, or to the extent that users have a particular type of directory integration so they want to bring their own identity to measuring and have a multi user experience. That's an area of extensibility. Another area of extensibility is the notion that misery has a couple of API is both arrest API and a GraphQL API, actually comes with command line interface, as well as a user interface that what the venue was just showing you. Part of the those API has been used to build out two different GitHub actions. So to the extent that you that you want to pipeline performance management into your CI systems. To the extent that that's on GitHub, you can do that relatively easily with GitHub actions, both the two that are there one is for performance management. The other one is for SMI conformance service mesh interface conformance. We'll talk about we'll explain that in a minute. But, but before that what we'll talk about is configuration management that misery does I noted that misery will analyze your runtime environment for certain service messages and tell you. You know, if you're doing things right or or or not. And so if you see a lot of green, then you're doing things right. If you see some red, it might suggest what you should what you should potentially look at changing. So service mesh or SMI conformance that GitHub action that we were just talking about you can run SMI conformance as a GitHub action that will run misery in your in well as a in your GitHub workflow. You can just run SMI conformance separately and so what is SMI conformance that it's the notion that I was saying earlier that misery has been a partner to service mesh interface, since it's inception, and to help, you know and so I enjoyed some amount of adoption from, I think it is it seven or eight different service measures. A number of them. And so misery will verify will validate each implementation. Each SMI implementation done by those various service measures. It then publishes a public dashboard of the status of conformance. We mentioned also that misery in this in the current release that it has as an innate the nascent ability to manage WebAssembly filters, specifically for envoy based data planes. So most notably initially for Istio and in measures next release and it's the zero dot six release. That'll be a generic capability for any envoy based data plane that that's running an envoy that supports dynamically loading and unloading WebAssembly filters. So, there's a weekly meeting that happens in the misery project that focuses just on WebAssembly filters not only creating some filters, because the community has published some of those but also on additional management capabilities that misery should have in context of these filters. Good. And so, maybe we can take a look at what some of that looks like in misery. Yes. Yes. So, one of the things that we discussed is validating your running service mesh to see if it follows the best practices and so this is the Istio adapter. So Istio adapter offers a lot of capabilities, like provisioning service measures, provisioning sample applications. So, Masheria actually supports your own applications which you can bring in with you. So, other than the sample applications but the sample applications are here to help you test out your service mesh configuration. And it also offers other Istio specific configurations as well. One of the things we talked about was validating your configuration. So, if we try to analyze the running configuration, it actually vets your running service mesh configuration and helps you ensure that you are running things in the best possible way. And another thing that we talked about was SMI conformance. So, Masheria integrates with the SMI project to offer an analysis to check whether their service mesh is SMI conformance and validates it actually. So, here you can see Masheria being used to test the SMI conformance of open service mesh and it shows how much of the test that it actually passes. And three cents in the areas where this fails. And actually we also talked about a GitHub action so some of the service mesh projects are already starting to adopt the SMI conformance GitHub action and using that in their CICD pipelines to make sure that they the service mesh they release SMI conformant service measures every time they make a release. And we also talked about filters. So, Masheria also supports Wasam filters. So, this is in a really early stage in this process. And this will be released publicly in the next release of Masheria. And we also looked into, talked about bringing in your own applications. So, these are some sample applications. So, Masheria, what you can do is you can upload your applications directly into Masheria, edit them in the Masheria UI itself and actually apply these applications or on-board these applications on your service mesh as well. We also talked a bit of patterns, but I'll go back to Lee to explain a bit more about patterns before we dive in. Yeah, yeah, this is a little bit of, so this is one of the areas that the service mesh community has been discussing within the CNCF service mesh working group. It's been discussing around what really like best practices of behaviors of a mesh of how to take advantage of different features and functionality of a mesh in a way in which, yeah, this mouse is best practices. So, those are in the process of being codified. There's about 60 that have been identified thus far. And as they are codified, this is sort of a, well, a sample, it's not sort of, it literally is a sample, simple set of YAML that describes a pattern, I guess in this case for an Istio service mesh with a few configurations. But suffice to say that patterns, well, are hopefully somewhat concise. The same YAML, the same pattern is capable of describing deployment of any of the 10 meshes that mesh supports, as well as the configuration of the mesh, sure, but also things like ongoing behavior. So if you wanted to run a canary, you can describe that in a pattern as well. You can describe, so patterns are like a template, they're customizable and ingestible into a mesh itself. A mesh will take action based on what you've described in the pattern. So mentioned canaries, things like generating, running a performance test, generating load and then doing statistical analysis on that set of results. There's a few things that are coming, if you want to deploy a WebAssembly filter, you can describe that in a pattern as well, and have meshry apply it. The patterns are service mesh agnostic, and they're reusable, and they are, the initial set of them is being stored in a public-facing repository. So I mentioned that the initial set, there's been like 60 that have been identified, and so there's, there are folks that are working through what these look like. Meshry ultimately will allow you to ingest these, and not only have them, not only will meshry then orchestrate and apply them to your infrastructure, but you can also use meshry to visually represent them and to visually design them. Part of this, so I mentioned that there's the CNCF service mesh working group is sort of hosting and stewarding and advancing these patterns. They are also being written up into a book, service mesh patterns from O'Reilly, which is an early release. So there's a couple of patterns that are in that early release now. So if you go check it out, or actually I encourage you to join the service mesh working group and dig in to some of those patterns as they're being defined. On that, there is, well, early support for patterns in meshry. So patterns, you can basically define patterns in your YAML files. So this is an example of the book info application. If you are familiar with Istio, you might have heard about book info application. It's the sample application that Istio shapes with. So what you can do is define your configuration of your service mesh as well as, as Lee mentioned, the ongoing behavior of your service mesh as well. But like another capability of meshry that is going to be released in the upcoming version is visually configuring your service mesh. So, yeah, so this is a mesh map. So what you can see here actually is the same book info application represented visually so you can configure your service mesh configurations and behaviors visually through this mesh map. And you can also add filters applications as well as make other configurations visually here as well and you can export it as patterns to make it reusable quite easily. And it also automatically discovers. So what you're seeing is the that messing that we discussed earlier, it automatically figures out that we have deployed a sample application and it generates a visual representation of that. So back to you Lee. Nice. One thing that is probably is worth noting as well like the vendor it said it is. Well is the ability for for users for you to design your service mesh your service mesh configuration the applications that run on it, and to do that. So many of the measures that meshry supports. That's, that's nice. Hopefully, the effort that's being put into those patterns. People find helpful. There's a number of users, there's a beta going on a mesh map now and it's fairly excited people. All right, so I think we're to be there's two other projects to talk about so one of those is the service mesh performance project that also entered into the CNCF. Part of the goal of SMP service mesh performance is to well answer an age old question age old like from the dawn of service mesh. And that is, what's the overhead of these things. How do I know if I'm running them well. How do I compare against myself how do I baseline my environment and track that over time. Also, how do I compare against others how do I contrast. And so the specification directly. Well, you know, aims to answer those questions that I just articulated. The project is joined by maintainers from Intel hashi corp layer five and red hat. And so another place to come and get involved so I encourage all of you to. There's a number of outside of just being a specters a few other initiatives and research that's going on with the university partners that you saw listed. So some interesting, interesting research actually just yesterday, there was, you know, there's an IEEE on publication that that's coming out about some of that research so to keep your eyes peeled. And this, the venue this is probably good to show folks a bit about measuring implements measuring is the canonical implementation of SMP and how it does performance management. Yeah, yes. So, actually has this capability where you can define your performance test into profiles, as well as you can integrate with Grafana and Prometheus to see your dashboards and see all the metrics that are valuable to you. These metrics are customizable. And another cool feature is to is that you can actually schedule your performance test to run automatically. So, yeah. So to run a performance test. What we can do is I think our token expired. We've been looking at it, looking at this for. If you take a look at the, okay, sure. So, basically, we have multiple load generators. And recently we have been working on my talk so that is something that we will talk about soon. So these offers like we are looking into distributed performance testing distributed generation as well. And, oh, so this is, we can basically run performance test on your service measures, even outside of your service measures and you can provide URLs to test, and all the make configurations as well. So let me show you a performance test running. Yeah, if we, if I wonder if you refresh and grab a new session will probably So, basically, looking at it quite a long time that the token just expired so it should work fine. Yeah, so these are multiple performance profile so basically you can define your performance test in profiles. So if you take a look at it. This is the sample performance profile and you can also run a test on with this performance profile. And if you take a look at the results. So, what you can see is the some awesome metrics that talks about your performance of service, you can see your P 99 value and all the other way other things you can also a powerful feature here is that you can compare multiple performance test and see which one is performing and which one is most suitable for you so you can basically have multiple configurations of your mesh deployed and basically compare your deployments by running performance test across each other. You can also have a GitHub action that runs these tests on your pipeline so you can test your performance of this mesh directly from your pipelines, while, while you make releases, while you ship out your project new new release as well. Yep. Nice. Very good. So service mesh performance. The SMP as a project is. Well, there's a frequent question about what the differences between service mesh performance specification and the SMI service mesh interface specification. In the next slide, I'm articulates a bit of a Venn diagram about their areas of focus and how they complement they were measuring and SMI and measuring and SMP were designed in to intentionally overlap and interact. Hopefully, with all three in the CNCF now they will integrate even further than they already do. All right, lastly, if you're not familiar with Nighthawk there's a there's a project called get Nighthawk that it helps. Well, helps advance the existing integration of Nighthawk and meshery. Nighthawk is a load generator. That is of the envoy project so it's written in C++ and is has a couple of intriguing capabilities that are the ongoing study and ongoing effort within get Nighthawk, and that is to well take advantage of Nighthawk's adaptive load controllers, add a couple of those in expose them through through to let people recursively evaluate what are ultimately an optimal configuration in your environment. It's an optimal configuration of a service mesh. If you consider that you've got a certain SLO or certain, you know, minimum latency requirement that you need to stick to that. But you're but you also want to at the same time maximize your the resiliency characteristics of your deployment. Well, that's a can be a difficult thing to figure out a particularly if any of your infrastructure changes if you add another node to your environment your clusters. If you upgrade your service mesh if you change the configuration of your service mesh if you add another service to your set of workloads that you're running. Those things change and so the ability to run optimization routines and help you identify. Well optimal configuration of your mesh, but in accordance with your own constraints is again the study of get Nighthawk. Nighthawk itself also will also be well it's already orchestrated by a mastery but will be further more so as mastery goes to support distributed performance tests which is to say to orchestrate the distribution of a number of instances of generate load get a much higher fidelity perspective for multiple vectors about the performance of your workloads the performance of your infrastructure, and to be able to coalesce that those performance characteristics and present it back to you. That's, that's what this project is about get Nighthawk and so we have a mouthful in their misery again is is that a V zero dot five so there's a fair bit more to the roadmap, a number of things that we haven't spoken about today and that's be the agenda of another CNCF webinar. And then you and I will encourage you all to try a misery. Go, there's a warm and welcoming community of contributors a little over 300, as I was mentioning before that have contributed to misery that are hungry for feedback. They love hearing about their work so go try misery and jump into the service mesh community. Thank you for your time with us. See you all later. Thank you. See you. Bye bye.