 Welcome. Hello question. Is your infrastructure homogenous? Do you run multiple operating systems in your environment? Are all of your Applications written in the same language? Do you have different hypervisors? Do you work in a multi cloud environment? By suspect yes is the answer to any one of those Infrastructure diversity is a reality for most enterprises if not all enterprises So when you think about a technology like service mesh You would expect that there are multiple of them. That's why there's a category of of infrastructure called service mesh Now there are maybe more than any of you here can prattle off. I suspect some of you can prattle off a couple three four Maybe five six Not so much or I don't know Give it a shot in the chat and let's see how many you can list. We'll take a look at that number later My name is Lee Calcoat service measures have been a focus of mine for some time Written a couple of books on them have one coming out in a couple of weeks and then another one coming out Who knows when Boy books are hard I spent a lot of time in this ecosystem. So I chair the CNCS SIG network SIG network Along with the service mesh working group there Docker captain among various other things if I Covered too much in this talk. You want to look at the slides later the URL there Is where these slides and other talks that I've given are posted So you're welcome to them where I spend my full-time role and focus is at layer 5 layer 5 is a service mesh company It's also very much a service mesh community. It's a community full of maintainers of every service mesh mesh project all of the projects are represented and As such the open source projects that the community of contribute contributors creates Are well focused on all of the meshes You're more than welcome to join the slack and be a part of the the projects or the community We'll talk about a couple of those projects today as we look across a number of different service meshes So in an obligatory way, we take a quick look at what a service mesh is Many different ways to capture this Succinctly it's of services first network It's a sort of next gen SDN if you will It's a it's a network that is purpose built for empowering operators developers product owners and it is you know Sort of lays down proverbially at layer 5 offers a lot of Assistance to applications to layer 7 and of the OSI model There's a bunch more of introductory material to what a service mesh is inside of this free book This is the one that's coming out in a couple of weeks. You can articulate the value in hard terms of what a service mesh is You know popularly Described in these four buckets fine-grain traffic control The the ability to offer resiliency to your distributed systems whether they're containerized or or not a lot of observabilities for the three pillars of observability between metrics logs and traces and a fair bit of security with authorize it, you know, some fairly deep authorization application level authorization authentication Certificates and encryption There's a lot in there. There's a lot to a service mesh one of those buckets of functionality that isn't spoken of as often and Some are just kind of coming to understand this is that there's a fair bit of Business logic or application logic that can be facilitated by a service mesh We'll give some examples of that later in this talk But it's certainly an interesting area, there's a lot of power in a mesh lot of power in the network and I think you can begin to expect more from your infrastructure Particularly when a service mesh is present on the softer side of the value that a service mesh offers is that of Empowering different personas different teams I'm empowering them. Yes with smarter infrastructure more controllable a lot of things But but also to help these individual roles decouple from one another a bit So that they become somewhat more empowered and are able to iterate independently and move more quickly operators don't necessarily have to ask a developer to change the logic of for I don't know the number of retries that are Happening from one service to the next in the extent in the in the event of a failure Developers don't have to be concerned with implementing retries. I can choose a retries. I guess here is the example And so they the developers can move faster toward business logic turns out Product owners aren't able to manipulate business logic the mesh can Do deep packet inspection and not just inspection but packet manipulation. There's a lot that can be done inside of inside of a service mesh product owner can Change the pricing structure of a SAS offering using a service mesh A lot of things, but we'll again, we'll get to an example or two There are any number. Well, I guess we said that there's a Quite a few service meshes. It's a bit meshy out there. There are 20 or more depends on how you count depends on if you count all of the flavors and offerings of of Istio for example or not And and there's a landscape that is one of the projects of the service mesh community the service mesh landscape is rather detailed and captures, you know, the governance model and the language and and a variety of other facts about service meshes I've pulled out a few here really to just highlight some of their strengths This is not exhaustive of their strengths, nor is it exhaustive of all of the meshes, but Lanker D has been Known to Deliver value quickly. It's also been known to be performant in part by its choice of language rust as its language for implementing the data plane in Lanker D Istio's Larger or the largest of the projects in terms of scope of functionality. It's also been historically fairly extensible that has regressed some Recently some of that extensibility has been well Temporarily traded in and now being brought back And so Yeah, so this statement still stands The project has been yeah, anyway, so console one of its strengths is that it supports deployments on kubernetes or running workloads and services on the console service mesh both in kubernetes environments and off kubernetes, which is Really important nginx service mesh was just announced last week The data plane that's used for the nginx service mesh is nginx plus more nginx is Proxy And so the part of its strength is its tight interoperation with that very popular proxy Network service mesh is the network engineers service mesh if you will It's the only one that Focuses on lower level concerns So each of these has Different but similar architectures. So we'll talk about their similarities and then look at their differences similarly Every service mesh that's out there Breaks down into really three high-level components a data plane. This is where you will find the proxies that comprise the Mesh and comprise the data plane some service meshes have built-in Gateways both for ingress and egress egress is oftentimes used for security purposes while ingress is used often for a load balancing and traffic redirection A number of things The and that's where a lot of heavy lifting is done inside the data plane in the control plane. This this is The set of components that are service mesh specific They handle commonly they handle logic like I'm integrating with the underlying platform a lot of times that's kubernetes can be other systems It facilitates integration with service discovery systems Really, it's a set of components that perform configuration management for the proxies in the data plane And depending upon which service mesh you're talking about those control planes might bring a little more functionality than the other We're starting to see prometheus and grafana Jaeger some kind of commonly packaged open-source components for telemetry bundled into the control plane There's a third layer here, which is a management plane That does any number of things. There are a few of these out there And They will again Differ in their functionality, but oftentimes provide configuration management across meshes Or maybe facilitate the integration and manipulation of business logic that we were referring to earlier They'll oftentimes they might do performance management or help you there multi mesh federation Some large some work might have a workflow engine or offer up policies for when what to do during Um continuous integration and and sort of traffic splitting and just really Really any number of use cases here So that was sort of how Service meshes are similar. Here's how uh architecturally they're they can be somewhat different This is an older view of istio as of a couple of releases ago Conceptually not a lot different um in its latest release But uh But given the time and the number of meshes to talk about we won't necessarily explain all of these components all that i'll highlight here is that istio implements a popular data plane service proxy deployment style and that is of sidecarrying the proxy to each individual application container Some meshes implement this and while others don't Uh console is one that does implement um sidecar or does a proxy as a sorry sidecar Proxies to the application container actually both istio and envoy support i'm sorry istio and console support envoy as They're out of the box proxy Console doesn't support swapping out envoy while istio Well, how should i say this um like i said istio is one of its strengths is extensibility and there are uh three or four example four examples now of Uh envoy being displaced in an istio deployment with a different proxy Come see me if you're interested in learning more there Um, we'll call out one interesting thing here. That's not specific to console But is becoming another popular capability of a service mesh and that is the ability to run Custom network filters inside of the data plane There's a web assembly is a technology that helps facilitate The dynamically injecting and kind of reloading custom filters For performing some of that intelligence that we were referring to earlier A lot of use cases for these so we'll we'll look at that more linker d Again a control plane a data plane Same model in terms of proxy sidecarring proxies I'd noted before this one was written in rust this one doesn't use envoy But it was written This proxy was written the linker d proxy purposefully written for the purpose of being a In a service mesh data plane and so not Not designed to be general purpose, but but to be used here Octarin is a security centric service mesh actually octarin The company was recently acquired by VMware and I think some of these components are beginning to form part of what tansu service mesh is Is There are different deployment models for service meshes, so we just talked about There's a bunch of different deployment models. We're not going to talk about them all One of the ones that we had mentioned was the Sidecarring your proxy and that model of having a lot of proxies in your data plane There are other ways that people Run service meshes or Other journeys that they take on their path to Running a full-blown service mesh a lot of times in many environments The initial path the initial step that people will take is with a gateway an ingress gateway Or otherwise a a load balancer in a reverse proxy There's a lot that can be done there. There's um, you can begin to break down your monolith With a proxy out in front Over time as you want to have resiliency within your systems more Visibility more security you start to have more proxies eventually you you have a lot of proxies Eventually you need a control plane and you wind up with a service mesh And then when you're serious and you're running your service mesh well Or you want to know how to run it well You bring in a management plane One of the models is about proxy per node or a dame an agent per node a daemon set if you will Which is a model in which there's only one Reverse proxy per node There are pros and cons to this model Different meshes have implemented it There are other models This short book that I mentioned before will take you through them if you're interested. It's a free book. So But suffice to say because there are so many service meshes out there there are Are standards specifications abstractions that have come about One of those is the service mesh interface If you're familiar with cni or csi Then and not the tv show I guess That you would be familiar with or you would have a conceptual understanding for the mission and goal of smi Which is to provide You know more or less the lowest competent nominator set of apis That that provide Things like traffic splitting traffic metrics For you for your organization or you to integrate with as a layer of abstraction Across which any given service mesh may plug in behind And so that's what smi is Very in brief about smp service mesh performance is about helping you manage the overhead of your mesh Helping you squeeze as much value out of it helping you characterize that in a way in which is repeatable that you can Perform benchmarks compare your performance to like meshes to Different service mesh deployments in different organizations so that you can Gauge how efficiently and how well you're running your infrastructure how much value you're deriving from your infrastructure The third spec here is or abstraction here is i'm dubbed hamlet it's Stewarded by vmware it is for It's an abstraction for defining um mechanics by apis and mechanics by which You can exchange service catalogs from between different meshes so from one mesh to the other whether that's the same type of service mesh or not So a bit more about smp. I was describing this a moment ago. You can visit the url It'll give you a short demo Of the this spec and what it looks like in its canonical implementation Its canonical implementation is done in meshery. We'll talk about meshery more The spec itself is vendor neutral. It's proposed for adoption into the cncf It's being currently advanced inside of a cncf working group for service meshes And it facilitates a number of things My hope is that it will facilitate Mesh mark and that mesh mark will help people easily understand The value that they're deriving from their service mesh A lot of considerations around performance Questions and concerns and really like variables to track As you run a service mesh Particularly the more that you use it the more that you're going to want to understand It's it's mechanics. It's overhead in terms of memory and cpu latency and throughput and other things There's a lot of power in there and you know naturally the more that you ask of a mesh or the more that you ask of anything the more Resources that it might it might take and And there's no way that I can summarize all of how that All of those considerations quickly But against maybe suffice to say that an index like mesh mark would be an easy way for most of us to understand How to operate there your service mesh well and so Part of then what it facilitates is an understanding and of comparing Um the different network functions that you can employ in a mesh so things like context-based routing Different types of load balancing algorithms or path-based routing How much do these affect you? How powerful are these concepts? How much time do they save you? Then also the the mechanics by it's not just the network functions that you're you're running but um the Infrastructure that you're using the way in which you're running these And so if you're using You can implement it was using retries earlier as the example you can implement retries in your Application logic inside of a client library that'll cost you some cpu cycles will cost you some memory You can have those implemented outside of your application and Here in a service mesh in a sidecar or in a proxy side card or not And have that piece of infrastructure that was written specifically to do these things perform those tasks And measure it, you know, how much? How quick it does it and how many resources it takes The same thing as you look to implement custom network filters The use cases for doing that are vast But what Are the or the performance characteristics there? It's important to be able to understand those There's been some Well in the layer 5 community and in the cncf we've been engaged with a couple of academic institutions And i've been trying to study in various environments using the s and p specification What these How we've been trying to characterize these performance character, oh geez Try not to use the word characteristics again, but How you how you measure and characterize the overhead here So that you can make intelligent decisions as to how you run your architecture as to whether or not you want your developers to go write something That you otherwise could do with the mesh And how quickly they could get it done versus The cost of doing it in your infrastructure so So we I'd noted web assembly a couple of times if it's new to you know that it's a Well, it's a stack-based virtual machine Sort of like a to describe it quickly and And abuse it a little bit It's sort of like a new fangle a new fangled jvm if you will So the promise of you being able to compile to web assembly as a target is nice because they're You know 40-something languages supported and its execution environments can be in the web browser In our case it can be in the data plane in a proxy It has excellent performance and security characteristics And so is growing in popularity There's an example here that Just looking at the time we don't have time to really go through But this example is one that you can look up and it's intended to be a playground for people to get familiar with Web assembly filters and to see what they're capable of this particular example uses console and On that we should talk a little bit about meshery Uh Which is a service mesh management plane It was Interoperable with smi when smi was announced It is also the canonical implementation of smp And it participates it's being donated to the cncf it participates in a few other programs It as a management plane it does a few things It does performance management that we've been talking about some Yes, that you can use that to Compare the performance between different service meshes. That's one thing you could do you can do that you can use it to baseline your environment and look at how Changes over time affect the performance of your systems Of your service mesh Um, whether that's a new release of a mesh or you changing the configuration of the service mesh or Releasing a new version of your workloads on top of the mesh That it's an ongoing concern It meshery lets you compare overhead between different tests that you run It also has built-in best practices for how to configure each of the service meshes that it supports So meshery will Hopefully help you run your infrastructure with confidence It will tell you when you're you're doing things according to best practice or not This actually I guess I'll say this that part of the the other book that That I'm authoring on service mesh patterns It'll have the first book will have 30 patterns and meshery will be the tool that Provides example of each of those 30 patterns. So shortly the community behind meshery is working on Oh providing support to let you deploy In those patterns quickly those best practice patterns so Meshory is also the official tool That the smi project uses for verifying conformance As to whether or not a given service mesh is conformant with the smi specifications And so meshery does this by Well automating the provisioning of eight different types of service meshes And the deployment of a sample application the generation of load of requests against that sample app The measuring of it and then finally a number of assertions where it tests And confirms whether or not a given mesh is Continues or is or continues to be conformant with smi And so meshery's architecture looks like this So the management plane lays down as a layer on top and across any any type of service mesh Well, maybe I shouldn't say any type, but I'm currently eight of them So more than any other project or product available today And it also has begun to facilitate deployment of web assembly filters So good well I mentioned before there's just a lot of activities going on inside of this community Jump into the slack. You'll find it's it's a warm and welcoming community If not there then join us in the cncf and the service mesh working group There's a few initiatives going on that we didn't speak about today But I'm hoping that this talk served the purpose of enlightening you to the fact that There's a lot of that it's meshy out there and that There are a number of tools that have been created to help with help you navigate those waters So very good. I will be in chat Um, thanks a bunch for being here Bring your questions