This document discusses linkerd, an open source service mesh for microservices. It summarizes that a service mesh handles communication between microservices by providing features like load balancing, failure recovery, and observability. Linkerd's approach uses lightweight proxies and integrates with service discovery and control plane tools, providing reliability, security and management of microservices. Potential downsides of a service mesh discussed are memory usage and latency overhead.

1. Cloud Native London
Skills Matter
03/10/2017
linkerd: The Cloud Native Service Mesh
Make your application and infrastructure more resilient, safer and faster
Dario Simonetti
askattest.com@AskAttest

2. ● What is a service mesh?
● Why do I need one?
● The linkerd approach
● Ain’t all sunshine and rainbows
Summary

3. Hello
● Head of Core Engineering at Attest
● Responsible for backend, architecture and infrastructure
● Mild obsession for clean code and product quality
● Previously at OVO Energy
● Sorry, me no speak k8s
https://dario.tech
Dario Simonetti

5. A real-time market and brand intelligence platform

6. ● There is no clear definition
● Handles service-to-service communication
● Control Plane (namerd, Istio, NGINX Controller, …)
○ “Centralised brain” with controller logic
● Data Plane (linkerd, envoy, Weave, NGINX Plus, ...)
○ Application-unaware set of lightweight network proxies
What is a service mesh?

7. Why do I need one?
“The way that microservices interact with each other at runtime needs to be
monitored, managed, and controlled”
https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one

8. Why do I need one?
● Client-side load balancing
● Circuit breaking
● Service discovery
● Retries and deadlines
● TLS
● Connection pooling
● Distributed tracing

9. 1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous
The Eight Fallacies of Distributed Computing
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

10. No, but really… Why?

11. The linkerd approach
● It’s a Data Plane, but integrates with Control Planes including namerd and Istio
● JVM based, built on battle-tested Netty and Finagle (Twitter)
● Open Source + great community
● Does one thing well and it's open to integrate with other tools that do their thing well

12. The linkerd approach
● Namers (service discovery): ZooKeeper, Consul, Kubernetes, Marathon, ...
● Telemeters: Prometheus, StatsD, TraceLog, Zipkin, …
● Control Planes: namerd, Istio
● Protocols: HTTP/1.1, HTTP/2, gRPC, Thrift, ThriftMux, Mux

13. The linkerd approach
Different deployment models:
Different deployment configurations:
● service-to-linker
● linker-to-service
● linker-to-linker
● Once per host
● Once per service (sidecar)

14. Ain’t all sunshine and rainbows
● Big memory footprint (~256 MB)
● Opening a new connection takes a lot of time (>100 ms)
● Some service mesh configuration should live in your application logic instead

15. T H A N K S F O R L I S T E N I N G !
Q U E S T I O N S ?
Website: https://linkerd.io
GitHub: https://github.com/linkerd/linkerd
Examples: https://github.com/linkerd/linkerd-examples
Slack: https://linkerd.slack.com
linkerd on AWS ECS: https://medium.com/attest-engineering/937f201f847a