Now that you have a better understanding of Red Hat OpenShift and how it fits into the Kubernetes ecosystem, let’s turn to another project in the ecosystem: Istio. A microservices architecture is a cornerstone of cloud-native development. We’ve touched on microservices briefly in this course: they are a cloud-native architectural approach in which a single application is composed of many loosely coupled and independently deployable smaller components, or services. Microservices have well-defined APIs for communicating with each other. There are many benefits to microservices. They make it easier to update code because only the relevant service needs to be updated, not the entire application. They allow teams that develop different components of an application to use different technology stacks as needed for each component. When the 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. For all their benefits, microservices also come with challenges. When microservices communicate with each other, they need that communication to be secure, so the traffic should be encrypted. Development teams might want to roll out new features to a subset of users or compare two versions of a feature in their application to see which engages users the most. In these cases, teams need canary deployments and A/B testing, which expose different versions of a service to different users. The communication between microservices also leads to the possibility of cascading failures if one service is unreachable or particularly slow. Developers need retries and circuit breaking to prevent a failure in one microservice from cascading to others. A service mesh is a dedicated layer for making service-to-service communication secure and reliable. It provides traffic management to control the flow of traffic between services, security to encrypt traffic between services, and observability of service behavior so you can troubleshoot and optimize applications. Istio is a commonly used service mesh. It's platform-independent but is often used on Kubernetes. Istio meets all the criteria of our service mesh definition. Connect, or traffic management, enables Istio to intelligently control the flow of traffic between services, which in turn enables canary deployments, A/B tests, and other deployment models. Istio secures services through authentication, authorization, and encryption. Istio provides control by defining policies that can be enforced across an entire fleet. Finally, with Istio you can observe traffic flow in your mesh so you can trace call flows and dependencies, and you can view metrics such as latency and errors. Consider this application architecture. The UI talks to an ordering microservice, which itself communicates with the inventory microservice, which talks to a database. Service-to-service communication enables any microservices architecture, but as that communication gets more complex, a service mesh can help improve it. Let’s use this example to demonstrate some of Istio’s capabilities. Istio can perform traffic shifting to gradually migrate traffic from one version of a microservice to another. So if the team that works on the ordering microservice has a new update to that microservice … … they can begin by sending 5% of traffic to that second version. Over time, they can increase this to 50% and eventually to 100%. Similarly, Istio request routing enables you to perform A/B tests and send a subset of users to a certain version of a microservice while sending the remaining users to the original version. This can help ensure that a new version increases user engagement or performance, for example. Istio also provides a variety of security measures for your microservices. One example is encryption. In order to defend against man-in-the-middle attacks, it’s important for the traffic between your microservices to be encrypted. With Istio, traffic between services can be encrypted to ensure that it’s safe in transit. In addition, it’s easy to implement policies for service access control, so that a service is only able to talk to the other services with which it is required to talk. In this example, the UI service would be unable to communicate with the Inventory service, even if it tried. Istio provides a number of metrics, including service communication. These metrics cover the four basic service monitoring needs: latency, traffic, errors, and saturation. For example, Istio provides metrics on request count, so that you can see how much traffic your requests are getting, and request duration, so that you can find bottlenecks and ensure that responses are given in a timely manner. You've completed the last video in this module. You should now understand some microservices pain points, and how Istio helps solve them. You should know what a service mesh is, and how Istio provides traffic management, security, and observability to facilitate communication between services in an application. Congratulations on completing this module! You should now be familiar with the Kubernetes ecosystem, why it exists, and a couple of examples of tools within it. You've learned about Red Hat OpenShift and how it builds on the success of Kubernetes to aid in cloud-native development. You've also learned about Istio and how a service mesh can secure and assist in service-to-service communication. In the lab for this module, you will have the opportunity to use the oc CLI to create resources on an actual OpenShift cluster.