All right. So let's talk about Introduction to service mesh with Istio So in this module, we will talk about a service mesh, an Istio overview, traffic across the mesh, and traffic shaping introduction. So let's walk through the case scenario of breaking down a monolith. So, over here in this slide deck, you will see that we have a monolith, we have function A and function B. Before, both of them lived in the same application, the same machine, same application, communicated internally between themselves on the same machine, no problem really. But as time grew along, we realized the potential of creating microservices, and we had containers and kubernetes and all this really cool technology, and we want to utilize the all of these advances in IT. So we created containers with function A and function B. Both of these will be referred from now on as services. So we have service A service B, and that will be the dialogue between us. So it's not a microservice, it's a service. Now, all of a sudden, service A and service B needs to communicate over a network. Before, they were all in the same machine, and there is no need for a network. But actually networks, are kind of an untrusted zone. People can intrude, people can tap into it, etc. Networks generally speaking, are not considered a very safe medium for two microservices to communicate with each other. So now that we have two separate applications, we have the container A and Container B, we want to expose an API because this is how we do microservices. We have a contract between the two services. We speak this language. This is our application interface, and you can interface with us in that way. So we abstract away how we do the computation, we front end an API, and we can iterate on our business logic behind that API in a consistent manner. That's beautiful because then what it means is that we can have the developers that are responsible for my container A can iterate and do whatever they want in their own release cadence, and completely decoupled from let's say service B because we have an API. So generally speaking, the way that we like to think about a network is that, if we go back to slides, networks, if you can see networks in big enterprises, is that we have a flat network, and a very, very thick perimeter. So, anybody wanting to penetrate into the network, they are going to have a lot of difficulties, but once they're in, there is a bit of a free movement inside. VPN is a good example. If you can VPN into your corporate network, you have access to a lot of resources that you do not have without that VPN. So networks generally speaking are almost like a flat environment, where if you go into them, you have access to a lot of things inside of that network, and that is not a good practice. So the aspiration is to use a zero trust network, where inside of the network, you have defense in depth, where you have checks and balances inside of the network, the communication between the microservices. So now, we need to also make sure that each and every service has an ID. So I cannot then go into your network and then pretend that I'm service A, or service B, and intercept that connection with the man-in-the-middle, for instance. So we need to find a way to authenticate who you are. We also need to make sure that we have security and policy, and that is basically authorization and authentication. So these are the two things that we need to consider now that we have to separate services communicating with each other. Before, we had a monolith, we didn't have to worry about that because they're both in the same machine. But now, they're all decoupled and they're on a network, so they need to communicate somehow. Next up is we have network resiliency. So we need to make sure that we have talked about latency, fault tolerance, circuit breaking. Generally speaking, when you see these terms, you think about application instrumentation. You put libraries into your application, into your business logic, to make sure that you have some fault tolerance, and circuit breaking, etc. Policy as well. So how do we make sure that we have quota and rate-limiting? So if we know that one microservice can have 1000 QPS, how do you make sure that you never exceed that? On top of that, lastly, is observability. How do you make sure that you have logging, metrics, distributed tracing, topology, end-to-end dependency between all of your microservices because now we have 100 of them and you don't know which one is dependent on one another. It becomes very very complex. So all of those things that you see here, when it comes to microservices, are not really a business-logic. All I want to do as a developer is I want to think about my business logic. How do I give value to my business? So all of those things that are around my application are basically network functions. If you think about it, all of those things could be network functions, and that is what a service mesh is trying to help you solve. So a service mesh basically separates these applications from the network functions. That can look suspiciously like a pod in kubernetes. So you have your business logic on the top, which is what the developers think about and care about, and you have all the rest of the stuff that are different from it. Now you have a pod, container 1, container 2. This is where the whole idea of a pod is quite genius because you can have two different containers running in the same environment, and they can communicate and collaborate as if they're running on the same machine. That is a good use case as a sidecar when it comes to a pod in kubernetes. So basically, what we have here is we have a pod, which is our container, and a sidecar that is responsible for the communication and the network features that we discussed before. That is basically a service mesh. That's the way that a service mesh works. So in general, what we've solved from all of these requirements, all of those things that we talked about, the network functions. They can be divided into three major benefits. One of them is traffic control. One of them is observability, the ability to see really what's going on in the communication between all of my microservices that I have hundreds of them now, and security. Kubernetes for instance, you have five services. All ports can communicate with all pods freely. There is no encryption between them, so someone can tap into that connection, if they can penetrate into the cluster. How do I make sure that we have encryption authorization, authentication, and policies generally around it. So these are basically functions of a service mesh. So basically, as you can see here, we have the container orchestration, which we discussed in the last module, but then you have a service mesh on top of it, and that basically allows us to expose and collaborate all of our containers in a secure, reliable fashion.
