In the next module, we will talk about Istio overview. Istio is an open framework for connecting, securing, managing, and monitoring services even across environments. Even across environments is the key here. Because what we have is we have islands of clusters around the world, across environments, and we want to make sure that the services that are running on these clusters are able to communicate with each other in a secure and reliable fashion, and the general idea behind Istio is that, it provides you with all these functionalities without your applications awareness. So it decouples all of these functions from your application. So your application can become really and truly portable. Because if you think about it, if my application all it does is it says "Hey I'm service A and I need to get to service B." That's all the applications need to think about and all the network functions, all the service mesh can take care of all of the authorization, authentication, resiliency, folding tolerance, all of those things for the application without it even knowing, I can then move it anywhere I want. It's really portable. So let's see how it works. So the sidecar model. So on the left, you can see a regular pod with the front-end. On the right, you will see a Kubernetes and Istio. So Istio basically is able to automatically inject a sidecar with all of its in the namespace or you can do it manually yourself. What you will see is you will see that the spec will add another Istio proxy. Istio proxy is based on the envoy, envoy proxies and it's based on C++ and it is highly optimized with low memory footprint and very very highly optimized proxy, open-source proxy mostly developed in Lyft and Google and IBM, collaboration between all these companies. But the idea here is that you have a transparent injection of all of these proxies in your environment and these proxies will intercept all of the communication. So from Kubernetes, you remember that there is a connection on local host between all of your pods as if they're all living in the same machine. So for instance, I'll give you one example which is a good one. When you use a SQL proxy, you basically intercept all of the connection in local host port whatever, and that connection goes from that proxy on your behalf somewhere else. That is the way that it works. What do we do with an envoy proxy is basically we're taking all of the communication, no matter which port you're using, and we're passing it through a layer of logic. We're basically making your network function a lot more smarter, and allows you to have a lot of functionalities on the level of the proxies, on the level of your network. So let's see how it actually works, what are the components of Istio real quick. So first of all, we have pilot. So pilot manages all these proxies. So imagine that you have hundreds of thousands of pods across all of your cluster. A component needs to manage them. Needs to make sure that all of these proxies are aware of all the rest of the services, knows what routes to take, knows which certificates to use, etc. So pilot is the component in Istio that is able to provide you with that functionality. It sends information into all of your proxies in terms of service discovery, traffic management, Intelligent routing, and resiliency. All of those things are managed by pilot. We also have mixer. Mixer is another component of Istio. Mixture is quite interesting because what it does, it collects telemetry. Telemetry is basically all of the network functionality, latency and the rest of this information. But it also does policy checking. So you will see that there is telemetry. So you can put all your information to Grafana and Apigee, maybe Stackdriver, etc. You can also use policies. So you can make sure that service A is allowed to actually talk to service B. So you have some an enforcement in-between. Lastly, we also have a Citadel which is my favorite name as well. I love that name. It is a certificate management. It's a CA in your service mesh. So if you remember, we said we have service A and service B. How do we give them authentication? How can they verify that I'm actually service A and I'm actually service B? I can now create a connection that both of them authenticate themselves to one another and encrypt one another, the connection with MTLS. By the way, mutual TLS, MTLS basically authenticates both parties. So if you go to a website today to your bank account, to your bank website, it is a one side TLS. The bank needs to show you a certificate that I can verify and I know that this is actually my bank. Then if I want to authenticate myself against the bank, I will use my username and password. MTLS works on a mutual basis. Service A and service B needs to now authenticate both of them and then they can communicate. That is a really cool technology especially when it comes to a service mesh. So if you now think about it from a hybrid connection, I have somebody over there across the sea in a connection and I want to make sure that they are actually service A from my on-premise when they talk to serve B in the Cloud. There has to be some way for me to verify the identities of my services, and that is something that I can do with that certificate and that function of the service mesh.
