[Music] Welcome to “Service Mesh and Istio.” After watching this video, you will be able to: List the benefits of microservices, Describe the challenges that come with microservices, Explain what a service mesh is, Describe why a service mesh is useful, Describe how a service mesh can alleviate common microservices challenges. Using a microservices architecture to build cloud-native applications provides numerous benefits. Updating code is more manageable with microservices—you only need to update the relevant services. With microservices, teams who develop different application components are free to use other technology stacks that meet their unique needs. In addition, when an application is running, components that experience more load can be scaled independently, preventing the entire application from needing to be scaled when only one component requires more resources. Using microservices also brings some challenges. Microservices require configuration to secure communications and set up encryption. Development teams might want to roll out new features to a subset of users or compare two versions of a new feature to see which version most engages users. In these situations, teams need canary deployments and A/B testing. Communication between microservices also leads to the possibility of cascading failures if one service is unreachable or particularly slow. To prevent communication failures from cascading to multiple microservices, developers must implement retries and circuit breaking. Now let’s talk about service meshes. A service mesh is a dedicated layer for making service-to-service communication secure and reliable. Among other capabilities, service meshes provide traffic management to control the flow of traffic between services, security to encrypt traffic between services, and observability of service behavior to troubleshoot and optimize applications. To learn more about service mesh capabilities, and specifically the Istio service mesh, here is Ram Vennam from the IBM Cloud team. Let's use this example application. I have a UI microservice talking to two versions of catalog, which talk to inventory. All of these are services deployed inside of a Kubernetes cluster. The number one reason why someone uses a service mesh is because they want to secure their workload. So they want mutual TLS when one service is talking to another. Next, they want to dynamically configure how the services are connected to one another. So, in this example, there's version one and version two. So, I might want to send 90 percent of the traffic to version 1 and then 10 percent of the traffic to version 2 while I do testing and incremental rollouts. I might also want to try adding retry policies and circuit breaking to harden my system. Three. I want to observe how my application is doing end to end, not just if a service is up or down but see where the bottlenecks are in the system and how traffic is flowing. And four, I want to control who has access to talk to what. In this example, UI is allowed to talk to catalog, and catalog is allowed to talk to inventory, but UI is not allowed to talk to inventory directly, and rogue containers cannot talk to inventory service. You can get more granular than that and say that UI is allowed to make an HTTP get request and catalog is allowed to make a post request to inventory. In the past, we used to have our developers program all of these features directly into their application code. That slowed down the dev cycle, it made these microservices bigger, and just generally made everything less flexible, but now there's a better way and that's the service mesh. You keep your application small and business-focused and, instead, you dynamically program the intelligence into the network and that's exactly what Istio does. So, when you have Istio installed, the first thing you'll do is... it'll automatically inject proxies next to each one of your containers, and these proxies are envoy proxies, and the proxy itself runs in a container next to your application container, but it runs inside the same Kubernetes pod. Now, when UI wants to talk to catalog, the proxy will actually intercept that request, apply any policies, and then route traffic to the proxy on the other side, and then the catalog proxy will receive that request and then forward it down to the catalog. Istio will configure each one of these proxies with your desired configuration. Istio extends Kubernetes using CRDs. So, to apply Istio configuration, you just write your YAML and then apply it to Kubernetes. The Istio galley component will receive that YAML, validate it, and then hand it over to Istio pilot. Pilot will convert that configuration to envoy configuration and distribute it to each one of the proxies. If you want the proxies to add additional policies and rules there's a policy component. And then these proxies constantly report telemetry information about what's going on into your system to the Istio telemetry component. And last but not least, there's citadel. Citadel is responsible for providing a strong identity to each one of the services in your system. It also generates certificates and rolls it out to each one of the proxies so that the proxies can do mutual TLS when they're talking to one another. To get started with Istio and to configure Istio, there's three main resources that you need to learn about. First, there's a gateway. Gateway is like a load balancer that sits at the edge of your mesh and accepts incoming and outgoing HTTP and TCP connections. Next, to direct traffic from gateway to your services you create a virtual service. And a virtual service can be bound to a gateway and direct traffic to UI or it could be bound to a service and then direct traffic to your other services, where you can apply policies like ninety percent and ten percent traffic split rules. Once traffic is routed, you can apply rules on top of that traffic such as TLS settings or circuit breaking, and those are done using destination rules. And those are the three main resources you need to know about Istio. I'm actually going to put policy and telemetry in asterisks because there's some refactoring that's going on with these components. The logic is being moved outside of this control plane and into the proxies themselves to avoid the additional network hop. This translates to improved performance. In this video, you learned that: Microservices architectures need security between services as well as ways to manage and test services, A service mesh is a dedicated layer that provides security and more by coordinating communication in the environment, Istio provides traffic shifting, mutual transport layer security, and telemetry when deployed with microservices.
