 Our next topic is going to be on what the heck is service mesh. I always ask this question as at last year, I always ask this question in the same phrase, what the heck is service mesh? Because there's so much mesh in going around, and I don't know what it's all about. This session is going to be taken by Jibril Oyetungi and Jibril is a self-taught developer and DevOps engineer interested in all things Cloud, containers, and the Go programming language. It's good to have you here, Jibril. Hi. Am I audible? Yes, you are. Okay. Cool. Hello, everyone. My name is Jibril, and I'm really excited to be presenting this session called what the heck is a service mesh. Hopefully, we can explore this together and get some insights, but then I'll just talk. A little about me. I'm currently a self-engineer working at RQ Nox. I really love to go from the programming language, hence, I sometimes call myself a gopher. In my second year of university, pursuing a degree in cybersecurity, and you can also find me on Twitter, at Syntax Era. So yeah, service mesh, what's that? So when you Google this, you probably land on Wikipedia, and Wikipedia will tell you a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between microservice, microservice is using epoxy. But what does that really mean? When I first started out, that didn't tell me much, and I was still as confused. So a simpler definition would be a service mesh is a tool for adding a layer of observability and security between applications without the need to modify your existing services. And I would explain a bit more about this later in the slides. So some popular service meshes you might have heard of are Istio, LinkerD, and Console. So yeah, now that we have a good idea of what a service mesh is, how does this work? And it turns out that the answer is pretty simple. The answer is a sidecar. Well, not this kind of sidecar, but service meshes use something called the sidecar button. So the sidecar essentially sits alongside the application and intercepts requests to and from your application. And this allows the service mesh to provide the extra features of security, observability, and whatever other features the service mesh might choose to provide. And this is also how you are able to modify your service mesh without actually having to modify any application code. So this is a typical example of how it would look in a Kubernetes cluster where there is a sidecar sitting alongside service A, B, and C. So any rules or updates I make to the service mesh would be made to the sidecar proxy running alongside your service and not the application itself. Okay, yeah, that's pretty cool, but why? The first one is security. Most modern service meshes would allow you to find what services are allowed to communicate with each other. Off the top of my head, one that I really like is Conzo. And Conzo has something called Intentions. So Intentions basically allow you to define what services can communicate to each other. So going back to the previous slide where there was service A, B, and C, let's, I could define a rule that says only service A is allowed to talk to service B and only service C, only service B is allowed to talk to service C. So you can start to see how you can fine-tune how what services are allowed to talk to each other and thereby giving you an added layer of security. And also another big one is Neutral TLS, which basically encrypts the communication between services and helps you gain yet another layer of security on top of your applications. And cool dashboards. Most service meshes would provide this and I find it really attractive, but not really. By dashboards, I mean observability. So most service meshes or all service meshes would give you observability features. This would allow you to drill into each service running in your cluster or however you choose to deploy. And then it would allow you to see things like latency, field requests. The screenshot I have here is from Istio and this is the Keali dashboard, whereby they have some services deployed here and then you can see what services are talking to each other and how they're communicating. And then they also have some stuff about request per second and then some other metrics you can really drill into. One of the cool features aside the dashboards of course, is traffic management. This allows you to do things like A.B. testing, blue-green deployments and canary deployments. Well, I can tell you that we're doing any of these three on their own can be a bit of a pain and then a service mesh can help you make it just a little bit more easier. So that's another big reason I see some people using a service mesh. So the other question, should you be using a service mesh? Well, yes, but actually no. And the answer is it actually depends. In a world of microservices and cloud-mated buzzwords, it's easy to think that a service mesh might be the next logical step for your applications, whether you're microservice or not. But beware, as Uncle Ben said, the great power comes great responsibility. And you should really watch out. When thinking of using a service mesh, responsibility comes in form of operational costs and this goes back to your team, like are they actually ready to bear the burden of running a service mesh? I mean, depending on how experienced they are, this might not be a problem, but adding any new technology or tech, and even if it's not that new, adding a technology in general could come with unforeseen circumstances. So you should really ask yourself, would your current application benefit from a service mesh? If the answer is no, I don't think you should be trying to use a service mesh. And again, is your team ready to handle all that comes with a service mesh? Above all, remember a service mesh is not a silver bullet and half one. So thank you very much. That's all for my presentation. That was a great session. Thank you so much, Jibril, for that very introductory topic on what the heck is service mesh. So if you have any questions for our speaker, you can drop that in the chat and we'll interact with it while we still have a speaker right here with us. Actually, I think one thing I like about Jibril's thought is the title. I mean, like what the heck is service mesh? And that kind of like resonates with everyone that is curious about like the topic. It was super, super catchy. And I think you really did justice to introducing what is service mesh. But I understand that a lot of folks must have some questions. So I'm currently on Twitter to know if there are any questions for Jibril. From what I can see, there is none. Okay, so yeah, I guess that's it. Okay, cool. Yeah, thank you so much, Jibril. Yeah, thanks for having me. Yeah, for this awesome presentation. And yeah, I hope you join us next year because definitely this will be happening next year as well. And yeah, I'm looking forward to having you join as a speaker or as an organizer next year. All right, thank you so much. Bye. Bye.