Istio in Action

Christian E. Posta, Rinor Maloku

• Publisher: Manning
• Year: 2022
• ISBN:
  9781638350354
• Topic: Informatica
• Subtopic: Sviluppo software

Solve difficult service-to-service communication challenges around security, observability, routing, and resilience with an Istio-based service mesh. Istio allows you to define these traffic policies as configuration and enforce them consistently without needing any service-code changes. In Istio in Action you will learn: Why and when to use a service mesh
Envoy's role in Istio's service mesh
Allowing "North-South" traffic into a mesh
Fine-grained traffic routing
Make your services robust to network failures
Gain observability over your system with telemetry "golden signals"
How Istio makes your services secure by default
Integrate cloud-native applications with legacy workloads such as in VMs Reduce the operational complexity of your microservices with an Istio-powered service mesh! Istio in Action shows you how to implement this powerful new architecture and move your application-networking concerns to a dedicated infrastructure layer. Non-functional concerns stay separate from your application, so your code is easier to understand, maintain, and adapt regardless of programming language. In this practical guide, you'll go hands-on with the full-featured Istio service mesh to manage microservices communication. Helpful diagrams, example configuration, and examples make it easy to understand how to control routing, secure container applications, and monitor network traffic. Foreword by Eric Brewer. About the technology
Offload complex microservice communication layer challenges to Istio! The industry-standard Istio service mesh radically simplifies security, routing, observability, and other service-to-service communication challenges. With Istio, you use a straightforward declarative configuration style to establish application-level network policies. By separating communication from business logic, your services are easier to write, maintain, and modify. About the book
Istio in Action teaches you how to implement an Istio-based service mesh that can handle complex routing scenarios, traffic encryption, authorization, and other common network-related tasks. You'll start by defining a basic service mesh and exploring the data plane with Istio's service proxy, Envoy. Then, you'll dive into core topics like traffic routing and visualization and service-to-service authentication, as you expand your service mesh to workloads on multiple clusters and legacy VMs. What's inside Comprehensive coverage of Istio resources
Practical examples to showcase service mesh capabilities
Implementation of multi-cluster service meshes
How to extend Istio with WebAssembly
Traffic routing and observability
VM integration into the mesh About the reader
For developers, architects, and operations engineers. About the author
Christian Posta is a well-known architect, speaker, and contributor. Rinor Maloku is an engineer at Solo.io working on application networking solutions. ToC
PART 1 UNDERSTANDING ISTIO
1 Introducing the Istio service mesh
2 First steps with Istio
3 Istio's data plane: The Envoy proxy
PART 2 SECURING, OBSERVING, AND CONTROLLING YOUR SERVICE'S NETWORK TRAFFIC
4 Istio gateways: Getting traffic into a cluster
5 Traffic control: Fine-grained traffic routing
6 Resilience: Solving application networking challenges
7 Observability: Understanding the behavior of your services
8 Observability: Visualizing network behavior with Grafana, Jaeger, and Kiali
9 Securing microservice communication
PART 3 ISTIO DAY-2 OPERATIONS
10 Troubleshooting the data plane
11 Performance-tuning the control plane
PART 4 ISTIO IN YOUR ORGANIZATION
12 Scaling Istio in your organization
13 Incorporating virtual machine workloads into the mesh
14 Extending Istio on the request path

Part 1 Understanding Istio

What programming language do you use to implement your microservices or applications? Java? NodeJS? Golang? Whichever language or framework you use will eventually have to communicate with services over the network. The network is a perilous place for applications. What do you do for service discovery? timeouts? retries? circuit-breaking? security?

Istio is an open source service mesh that helps solve service-to-service connectivity challenges in your cloud and microservices environment regardless of what language or framework you use. In chapters 1-3, we explain why a service mesh is critical infrastructure for a microservices and cloud-native application architecture, how Istio helps, and what you can expect from the rest of the book. Istio is built on an open source proxy named Envoy, which we cover in detail to set the foundations for the rest of the Istio functionality covered in future chapters.

1 Introducing the Istio service mesh

This chapter covers

• Addressing the challenges of service-oriented architectures with service meshes
• Introducing Istio and how it helps solve microservice issues
• Comparing service meshes to earlier technologies

Software is the lifeblood of today’s companies. As we move to a more digital world, consumers will expect convenience, service, and quality when interacting with businesses, and software will be used to deliver these experiences. Customers don’t conform nicely to structure, processes, or predefined boxes. Customers’ demands and needs are fluid, dynamic, and unpredictable, and our companies and software systems will need to have these same characteristics. For some companies (such as startups), building software systems that are agile and able to respond to unpredictability will be the difference between surviving or failing. For others (such as existing companies), the inability to use software as a differentiator will mean slower growth, decay, and eventual collapse.

As we explore how to go faster and take advantage of newer technology like cloud platforms and containers, we’ll encounter an amplification of some past problems. For example, the network is not reliable and when we start to build larger, more distributed systems, the network must become a central design consideration in our applications. Should applications implement network resilience like retries, timeouts, and circuit breakers? What about consistent network observability? Application-layer security?

Resilience, security, and metrics collection are cross-cutting concerns and not application-specific. Moreover, they are not processes that differentiate your business. Developers are critical resources in large IT systems, and their time is best spent writing capabilities that deliver business value in a differentiating way. Application networking, security, and metrics collection are necessary practices, but they aren’t differentiating. What we’d like is a way to implement these capabilities in a language- and framework-agnostic way and apply them as policy.

Service mesh is a relatively recent term used to describe a decentralized application-networking infrastructure that allows applications to be secure, resilient, observable, and controllable. It describes an architecture made up of a data plane that uses application-layer proxies to manage networking traffic on behalf of an application and a control plane to manage proxies. This architecture lets us build important application-networking capabilities outside of the application without relying on a particular programming language or framework.

Istio is an open source implementation of a service mesh. It was created initially by folks at Lyft, Google, and IBM, but now it has a vibrant, open, diverse community that includes individuals from Lyft, Red Hat, VMWare, Solo.io, Aspen Mesh, Salesforce, and many others. Istio allows us to build reliable, secure, cloud-native systems and solve difficult problems like security, policy management, and observability in most cases with no application code changes. Istio’s data plane is made up of service proxies, based on the Envoy proxy, that live alongside the applications. Those act as intermediaries between the applications and affect networking behavior according to the configuration sent by the control plane.

Istio is intended for microservices or service-oriented architecture (SOA)-style architectures, but it is not limited to those. The reality is, most organizations have a lot of investment in existing applications and platforms. They’ll most likely build services architectures around their existing applications, and this is where Istio really shines. With Istio, we can implement these application-networking concerns without forcing changes in existing systems. Since the service proxies live outside of the application, any application for any architecture is a welcome first-class citizen in the service mesh. We’ll explore more of this in a hybrid brownfield application landscape.

This book introduces you to Istio, helps you understand how all this is possible, and teaches you how to use Istio to build more resilient applications that you can monitor and operate in a cloud environment. Along the way, we explore Istio’s design principles, explain why it’s different from past attempts to solve these problems, and discuss when Istio is not the solution for your problem.

But we certainly don’t want to start using new technology just because it’s “new,” “hip,” or “cool.” As technologists, we find ourselves easily getting excited about technology; however, we’d be doing ourselves and our organizations a disservice by not fully understanding when and when not to use a technology. Let’s spend a few moments understanding why you would use Istio, what problems it solves, what problems to avoid, and why this technology is exciting going forward.

1.1 Challenges of going faster

The technology teams at ACME Inc. have bought into microservices, automated testing, containers, and continuous integration and delivery (CI/CD). They decided to split out module A and B from ACMEmono, their core revenue-generation system, into their own standalone services. They also needed some new capabilities that they decided to build as service C, resulting in the services shown in figure 1.1.

Figure 1.1 ACMEMono modernization with complementary services

They packaged their new services in containers and used a Kubernetes-based platform into which to deploy. As they began to implement these approaches, they quickly experienced some challenges.

The first thing ACME noticed was that sometimes services in the architecture were very inconsistent in how long they took to process requests. During peak customer usage, some services experienced intermittent issues and were unable to serve any traffic. Furthermore, ACME identified that if service B experienced trouble processing requests, service A also did, but only for certain requests.

The second thing ACME noticed was that when they practiced automated deployments, at times they introduced bugs into the system that weren’t caught by automated testing. They practiced a deployment approach called blue-green deployment, which means they brought up the new deployment (the green deployment) in its own cluster and then at some point cut over the traffic from the old cluster (the blue deployment) to the new cluster. They had hoped the blue-green approach would lower the risk of doing deployments, but instead they experienced more of a “big bang” release, which is what they wanted to avoid.

Finally, ACME found that the teams implementing services A and B were handling security completely differently. Team A favored secure connections with certificates and private keys, while team B created their own custom framework built on passing tokens and verifying signatures. The team operating service C decided they didn’t need any additional security since these were “internal” services behind the company firewall.

These challenges are not unique to ACME, nor is the extent of the challenges limited to what they encountered. The following things must be addressed wh...