Viktor Gamov – Service Mesh: Day Zero

Hello, and welcome to Cloud native day 2022 and welcome to the session Day Zero with servicematch. with When we we're talking about all this Cloud native Technologies, some of the people who've been there in the industry for a while. They like to remember good old days and they talking about things how everything was much easier at that time.

There was no distributed systems. There was no kubernetes when it is and but let me bring some of this memories with classical diagrams from the world of sun Java Tui blueprint where we have a three-tier application. We have our database.

We have our business logic implemented in Enterprise Java beans and we have a serverless or Java service a pages that will be displaying our information from from our from our application and those things were very simple as they say and but like if you look into the closer to this picture, you will understand. It's actually there's multiple things where the things can go wrong. For example, you still have a connectivity to your Education between your application in your database and you still need to have a connectivity between your business logic.

You need to figure out the ways how you can package this application in the war or ER Enterprise archive or web archive. So it's it's actually was not that simple. We always were dealing with the things around communication and secure communication and reliable communication between our system and our backends between databases message system so far.

So on and to discover all these things between our application and database will also need to use some sort of services to find this information. Now when we start the refactoring to microservices things get much interesting and today we're going to be talking about some of the things how we can improve this migration to microservices. My name is Victor gamoff.

I work as a principal developer Advocate company called konk and in the Kong we're building new tools for developers to improve all things connectivity including API connectivity, which today we're going to be talking about service mesh and the service to service communicability on all this type of things. So let's Jump Right In into the remembering how this microservices revolution started and but usually people talking about microservices a revolution in the context of containers how the containers start revolutionizing and we usually say oh microservices needs to be continuous. However containers helps a lot about the changing delivery how we start shipping our software in But it was not about the continues were not a driver.

It was one of the tools that helped to better ship the software. However, the the way how we can Implement our connectivity. It's also, you know change change a lot.

So sir softer defined networks start appearing and helping to configure communication within the services and Technologies like containers kubernetes that allow to Orchestrate all these things and run this in in a more like a straightforward way and not thinking about all this connectivity here. This helped a lot to migrate to microservices. So with this the previous diagram as I mentioned, there's lots of things that we kind of were using for as a given something that we were getting out of the box from infrastructure.

And the people keep forgetting about is when you're talking about the monolithical application. So big part of this diagram big part of this architecture was handled by infrastructure. If you're running this in application server, most likely you will be using because as things like Discovery service in a Java world, it was Java naming and directory service ji that allows us to configure connection to our database in our application need to just look up this database connection from GI service also from the application servers.

We were collecting some of the maybe if you're running this in like application Server Like A Jay boss or websphere. I will also will be collecting some of the logs and the looking what application is doing. So a lot of things were handled by infrastructure and more importantly like when you need to use things to optimize connection between your database you probably will be using something like some Connection Manager or Connection pool that will be you know, the handling communication to your database when you're requesting new connection.

Not necessarily you will get a new connection. Maybe you will have some cash connection that your connection pool will be managing in order you to optimize access to this database so Nothing that was in the past was simple. So there's no reason to be afraid on the changing this architecture and talking about how we can improve this in the microservices world.

Now with the equivalent communication, we still have a communication to database and one thing that changed for us in terms of communication. Is that our service communication? They changed from communicating through some sort of in process communication communicating between objects in your system into API based communication.

When you have this analytical application your component calls and other component through calling the method of the interface or method of the class. We've with migration to microservice this thing changes to invoking API and our Communications switch from like cpu-based computation into network-based computation. Maybe many of you remember that saying that your my computer is Network.

So distributed system makes compute rely on the network very heavily. So that's why the network part always becoming a very important very essential part of this communication. um apart from the communication itself.

Just having this bytes going there is some what we call cross-cutting concerns that we need to be solving and those concerns usually they were a part of application developers to solve and things around how to collect logs how to provide the versioning of the services how to capturing how different and components will interact with each other we and when we're running this in In the world of like cpu-based and like analytical application. We don't need to worry about this because this tracing can be handled by either like application monitoring tools or you just attach the debugger and can see the stack Trace how all these components will be calling. Those things need to be also figured out how it can do in microservices world not talking about and some components around providing security.

Usually, you know security is very important component. That's why we're talking about this as after All these things, we usually or tend to build entire application. So developer is developer.

You will be responsible because you're not providing support for infrastructure. Usually you throw this over defense to your application support team and there will be you know running this so that's why you also need to make sure that your applications self contains. You have all the things that that you can use for for collecting on the useful information to debug this information future with the with the different variety of the applications and the services that are running different components.

We need to provide this thing in each in every component of this application. Each application will include its own login Library. It's includes its own security.

It will include its own some cool custom code to implement retries, or maybe it was the connection pools and all this kind of things. So, Comes with the repetition of the code or if using library that would be different versions of the libraries. However here I'm still talking about one particular stack, you know, as I mentioned coming from job world, there's tons of different framework that can Implement all the things and I don't need to worry about this.

However in modern Cloud native days, we want to know okay, no pun intended in a more Cloud native days. We actually want to diversify and provide the ways how the different teams can be using tools whatever they want or maybe even languages they want. So one team wants to build things using Javelin.

Everything was used go in other team wants to use rust and remember what I said, the communication becomes not the call and interfaces but colon apis by calling apis. It can be rest API and jpcrp API graphql API. So those are standard and you cannot enforce what kind of tools they will be using in order to implement those API.

We what if we can take some of these pieces of of functionality that we will rely on a different point and kind of like Outsource take this out of the application code and make it as universal binary that will be can be run alongside with the with your application and provide all this functionality including the error handling retries capturing some of the security and traffic encryption capturing logs of the system and storing this in the centralized login facility and so far and so on. And communication between the services will move from direct communication between the services into communication between those two components. So your application will be talking to local proxy and thinking that it will be talking to the rest of the world and the proxy will be providing access to the rest of the world.

Probably routing. Your application was to hit service currency exchange service or want to call. I don't know like the cart service or or service or email service and this proxy will also provide the ways how it will navigate this into this particular service.

So provide Discovery capabilities communication between those projects can be encrypted. So your application doesn't Required to implement this and this proxy need to be small enough in order to provide zero to very minimum latency numbers. So the communication between application will still continue and be performant and this proxy will not involve in additional.

Any additional problems? now communication between our different components like remember when I mean service here, it can be actual like microservice or some of the piece of the Some subset of functionalities that the running is another service one and like a logical service model include multiple microservices. So the we usually say that the all this modern Cloud native technologies will provide a tremendous benefits for new Greenfield application.

However, the concept that I'm talking today also will be applicable to run even some of the Not the Legacy but some of the monological application in the past so you can integrate using the same approach that I'm talking about even the existing political application. And communication also needs to be handled. Equally if we're running this in containers remember I said the containers help to revolutionize a microservice migration.

However, there are steel workloads where you can run this in VMS. You can run this in the bare metal not everything runs in container and that the same approach needs to be applicable to to those as well. um and communication between different replicas like this particular case we can talk about like continuously kubernetes.

We can run multiple replicas of the service in order to provide resiliency. If like one of the one of the service will go down the proxy will represent the services one thing and when the connection will come in and proxy will be smartly balanced traffic between different a different replicas of same application. So all good so Communications and approxy.

It's all fantastic and very cool thing. Now, let's figure out how we're going to be configuring this thing. So one of the approaches would be just go to Every proxy and they have a configuration file and the changes configuration file.

Unfortunately this approach very quickly start a stop scaling because with the number of the services the number of microservices, we cannot physically go in to every service and update configuration each time. When we want to change some of the traffic rules between communication or maybe changing certificates for like mtls communication between the services. So statically define configuration would be good.

If for example or all this with new release web digital configuration, and you already have a configuration Management in the place, however, you cannot just run the new release every time when you need to update like small. Duration parameter, so this is something that needs to be changed in runtime. So in in the microservices world, we usually rely on some sort of configuration services.

So this configuration will be centralized facility where we're putting configuration in this centralized facility will be talking to our services to ship this configuration as you can see from this particular slide that this configuration. Configuration facility is not sitting on the request path. So it will be not a dependent if this configuration facility will go down.

Our application still will continue to work configuration may be not be you know up to date however application will still continue to perform and things will continue to work and when this configuration sale server will get back online. We will get fresh configuration. So configuration service is something that exist will be responsible for keeping configuration in check and will be responsible for shipping new updated configuration.

Now we go in closer to the world of service mesh. And in the world of service mesh, we call all these components. that runs next to your application this configure this process the small a small bits of of binary that will be running and handling some some of the communication.

We'll call it data plane and this configuration facility. We call a control plane. So and just like that.

That's what you that that's basically what you have when you're talking about service smash service mesh contains two components and it's usually kind of like a one to many one component is a control plane. There's something that sits in the shipping configuration provides you some configuration UI and things like that and data planes that will be deployed next year application. There could be many of data planes that running alongside of your application cool and can be one control plane that will be handling communication that handling configuration of those data planes.

This architecture options up open up a different architectural and configurations. So you can run multiple data planes in a different even different the data centers different regions different zones. If you're talking about or even different cloud cloud providers and when you have a one control plane that controls those those data planes can not only support configuration between and components of your system, but also provide this traffic to Virtually connect say two data centers one runs multi-cloud is the thing and many organizations.

They use either as a kind of like a online active active configuration when you have a different users that hitting different different environments based on their localities, or they can use this like as an active passive mode or like active standby mode where one did the center will be filled over and the service mesh can create this virtual connection between the systems and it will configuration in communication between the services will be transparent. So with the this presentation I will be focusing and in a few minutes. I'll show you a few demos.

I will be focusing on the come on the open source project called the kuma which is cncf sandbox project. We developed initial beats of this Kuma control plane and the service mesh and the nature we had Kong developed this and with the nature this into Cloud native compute Foundation. io.

It's also cncf project and we use Envoy as our data playing proxies. Our this small component that runs inside my application and I'll show you how it looks like I will be using kubernetes as example, but it works similarly if you're running this in VMS if you running this in Um in bare metal Kuma design decision behind the kuma was that Kuma will provide universal control by meaning that correctness is nice but it is not hard requirement. If you want to use service mesh with VMS, there's also capabilities how you can do that and configuration API would be unified and you even can span multiple and mashes across one mesh can be running in your bare metal in other match will be running in VMS in the third National brand kubernetes, and they can also be configured through one Global control plane.

So let me show you a quick demo what I'm talking about. So I do have this application. That's called online boutique.

So I chose to pick up some of the existing examples because I wanted to show how the service mesh can enable on any application even if you don't have maybe access to source code. So I'm using some of the demo that was created for Google cloud and this microservice just simply enables the service Mission runs this so it's a Microsoft application that I can go and buy some stuff place an order. I can do continue shopping.

I can do this add to cart. I can go and buy something else. And all this interactions all the screens that I'm clicking around actually underline underneath they calling different microservices.

So inside my inside my corporations cluster. I have all this things running here. So there is a front-end service that handles all this UI components front end service called calls card service.

It calls checkout service Currency Service payment service product catalog that this place information. So all this things are each individual screen represents a Individual service each service will communicate to each other. So I deployed this within a namespace.

That has this very interesting connotation. So it has sidecar injection enabled meaning that as application developer. You don't need to do anything to enable this in your application.

This will be handled by the currency API. And it will be handled by special controller that runs inside your kubernetes cluster and will be looking for this annotation. If this namespace will be having this annotation this Kuma control plane will be inject this sidecar.

So let's take a look how it how it looks like so if I would look into into my front end service, so that's the the server. That's actually handles all the traffic. So when I hitting this this will be this will be handled by front end service.

However, it also includes two more components one. Is it in it container that will be starting in before all this containers will be starting in just configured Network. So all the network inside this pod will go through this sidecar and this is data plane process.

So if I will go to my Now let me enable the service if I will go to my comment system and I will enable and the service so I will get access to the service through you through the internet and the the scuma UI will include dashboard that I can allowed me to see what is going on here and I will be able to see all this let's see. Where's the my front end service? Yeah, that's my front end service.

and I can see and that's my front end service is already automatically registered within control plane because a control plane injected this data plane all the traffic goes to this data plane and all this information will be reported back to back to to control playing database So when I go to my front end service. so this sidecar will be responsible for handling all communication all the traces and things for example available in my all the traffic logs will be handled through this control plane. Now I also have Gateway enable here.

So in this case you traditionally when you communicating between the services and you expose the services, if you want to expose the services to you know, outside the kubernetes cluster something where your users can go and access it. Those things are going through the authority gateway gateway will responsible for example provisioning some of the certificates maybe some of the rate limiting in order to limit traffic to to the system and so far and so on. So all these things are integrated together within one one big service, man.

the one of the things that I wanted to show you right now, so right now and there is no there's no encrypted communication between the services but service mesh and coma can provide ability to enable this you encrypted communication with just like simple. Simple command. So what I will do this is my mesh definition my configuration of my mesh and since I'm using kubernetes, I'm using this concept of customer Source definitions inside my current cluster.

I have this mesh object and for this message object. I want to enable built-in backend for mtls. So if I will go and just just run this updated mesh configuration And I will go and click refresh.

for fresh all After a few seconds, what happens is I send this configuration to control plane. So control plane enable built-in certificate Authority a generated certificates send all the certificates to all these data planes and enable secured communication across all service mesh components. So now my configuration my communication from my front end which is also protected through https goes inside my service mesh and each each call will be also protected using mtls and everything continued to work.

I did this in the real time. I did this immediately. So now all configuration between the services enabled with service manager and with the mtls.

It's it's it looks just like simple. I just did the few clicks. This is how all this automation should look like, you know, you don't need to go to each individual service in enable this thing this needs to be handled through one centralized facility.

io website where you can learn all sorts of documentation. Also me and my colleague and konk we usually Hold bi-weekly or like every week or every two weeks live streams at the conc YouTube channel where we're talking about all the things connectivity and Cloud. So I hope you learned something new today.

I'm looking forward to getting some of the feedback from you and what you want to learn in future and with this, my name is Victor gamoff, and as always have a nice day. Thank you so much for joining us at the cloud native day 2022