Service-to-service communication as a 1st class citizen

I'm the author of the upcoming O'Reilly book, "The Service Mesh: Resilient Service-to-Service Communication for Cloud Native Applications." There's a long-hidden layer of invisibility in our applications that occurs at the service communication layer. In the monolithic world, it doesn't matter. We understand where service requests are coming from or going to (e.g. from web, to app, to db). But in a microservice world, it's often not clear and the relationships between different services can quickly scale beyond the grasp of any single platform operator or developer. In the monolithic world, we use a combination of tools in the L3/L4 network layer along with event logs and external monitoring to triage service issues. In the cloud-native world, that approach simply doesn't scale and it exposes a blindspot that occurs in the L6/L7 layer: the heart of microservice transactions.

The service mesh is built to shine a light into this previously obscured layer. It aims to turn service communication into a 1st class citizen in your infrastructure so that it can be managed, monitored, and controlled. It can be used to help platform operators better support application developers. It has powerful built-ins that can be used to enable CI/CD patterns, canary deployments, and unparalleled levels of robust testing before rolling into production.

One problem: most people don't know what it is or why they'd need one.

Except for those that have felt this pain because they're running distributed microservices in production. Since parts of your audience are on the verge of making that shift, they may want to know what these patterns and tools are + how it can help them.

I intend to talk about Linkerd, Istio, Envoy, and Conduit to help explain concepts and show examples of features. This is not a feature-by-feature comparison of tools and my aim is to only bring them up to help participants understand how these different solutions approach the same problem so that they can best decide where to start their evaluation process.

My company (Buoyant) makes Linkerd and Conduit. But like the O'Reilly book, the goal here is to explain the problem space and why this breed of tools matters. They all have fundamental commonalities (where I spend most of the talk), but they also have slightly different use cases (where I end the talk, so participants can figure out how and where to start their eval process if it makes sense for them).

This is a brand new, never before delivered talk based on the work I've done to prep the publication.