Daniel Ciruli, Senior Product Manager at Google
Why Service Mesh?
Google trends shows a massive increase in people searching for ‘Service Mesh’, driven by the increased use in micro services.
A quick poll showed, to me, a surprising amount of people in the room are using micro services
Traditional applications are monolithic which leads to big, Quarterly releases and are hard to scale.
Micro services helps application agility by breaking monoliths into smaller chunks. Smaller chunks allow for different elements to scale separately and to be deployed at different rates.
This agility has brought problems, such as increased complexity, difficulty in troubleshooting performance, coordinating deployments, understanding security.
Service meshes help with these problems. Istio is one such Service Mesh, which Google are working on with many others.
Istio uses sidecars. In Istio this is the Envoy proxy, originally developed by Lyft.
Istio’s Pilot component is the control plane which pushes config down to the sidecar container in each pod. This allows for things such as client side load balancing across pods.
Routing can be configured for A/B and canary deployments.
Istio Mixer allows for extensibility and also has an open API.
Istio Citadel runs as a certificate authority and manages certificates across the cluster. Istio can therefore guarantee encryption in transit. This also allows for strong authentication.
Google internally try to focus on services, rather than the underlying hardware or things like pods and clusters.
You want native observability and it to be easy to monitor your ‘Golden Signals’.
You also want better traffic control, such as doing it at layer 7 rather than layer 3.
You need to improve security to work based on services rather than IP addresses, amongst other things.
Ultimately you need to separate applications from infrastructure, and to decouple operations from development.
Daniel demoed using routing in Istio, so he could deploy a new version of his app but block any traffic until he was ready, and then only send 20% of traffic. Neither of those can be done natively in Kubernetes.
Secure services, not just on the edge. On the edge is not good enough.
Observe services, monitoring what matters to the services and your users not CPU and RAM.
Control Services. Provide advanced control of services without having to change code.