Service mesh abstracts the network from developers to solve three main pain points:
Service mesh implementations usually follow a similar architecture: traffic flows through control points between services (usually service proxies deployed as sidecar processes) while an out-of-band set of nodes is responsible for defining the behavior and management of the control points. This loosely breaks out into an architecture of a "data plane" through which requests flow and a "control plane" for managing a service mesh.
Different service mesh implementations use different data planes depending on their use cases and familiarity with particular technology. The control plane implementations vary between service-mesh implementations as well. In this talk, we'll take a look at three different control plane implementations with Istio, Linkerd and Consul, their strengths, and their specific tradeoffs to see how they chose to solve each of the three pain points from above. We can use this information to make choices about a service mesh or to inform our journey if we choose to build a control plane ourselves.
Container deployment platforms are a boring part of our infrastructure. The exciting parts, unfortunately, happen when services actually try communicating and working together to accomplish some business function. The service mesh approach helps make service communication boring, with capabilities that include retries, load balancing, timeouts, deadlines, circuit breaking, mutual TLS, service discovery, and distributed tracing. Istio—an open source project initially sponsored by Google, Lyft, and IBM—has become a popular way of implementing a service mesh, and the project has a growing community of users and contributors.
Christian Posta leads a deep dive into Istio. You’ll learn how Istio works and how to debug issues as you take a step-by-step walk-though of Istio’s components. Christian starts by introducing Envoy, Istio’s default service proxy, teaching you how to configure it and how it implements resilience functionality. You’ll then deploy each component of the Istio control plane—Istio Pilot, Istio Ingress, Istio Gateway, and Istio Mixer—giving you a firm understanding of what they do and how to use them. You’ll also discover how to debug Envoy configurations and how best to replace resilience features handled by library-specific frameworks (Netflix OSS, Finagle, etc.).
Christian Posta (@christianposta) is Field CTO at solo.io and well known in the community for being an author (Istio in Action, Manning, Microservices for Java Developers, O’Reilly 2016), frequent blogger, speaker, open-source enthusiast and committer on various open-source projects including Istio and Kubernetes. Christian has spent time at web-scale companies and now helps companies create and deploy large-scale, resilient, distributed architectures - many of what we now call Serverless and Microservices. He enjoys mentoring, training and leading teams to be successful with distributed systems concepts, microservices, devops, and cloud-native application design.