Istio: Up and Running

Chapter 3. Istio at a Glance

As organizations mature in their operations of container deployments, many will come to utilize a service mesh within their environment. This topic causes significant buzz within the cloud native ecosystem. Currently, many administrators, operators, architects, and developers are seeking an understanding and guidance with respect to how, when, and why to adopt a service mesh, so let’s look at Istio.

As you learned in Chapter 2, Istio, like other service meshes, introduces a new layer into modern infrastructure, creating the potential to implement robust and scalable applications with granular control over them. If you’re running microservices, these challenges are exacerbated as you deploy ever more microservices. You might not be running microservices, however. Even though the value of a service mesh shines most brightly in microservices deployments, Istio also readily accounts for services running directly on the OS running in your VM and bare-metal server.

Service Mesh Architecture

At a high level, service mesh architectures including Istio commonly comprise two planes: a control plane and data plane, while a third (management) plane might reside in incumbent/infrastructure systems. Istio’s architecture adheres to this paradigm. Figure 3-1 presents the divisions of concern by planes.

For a more thorough explanation of service mesh deployment models and approaches to evolutionary architectures, see The Enterprise Path to Service Mesh Architectures ...