Putting microservices on a diet with Istio #OReillySACon

In a microservice world, things become more complex. Platforms such as Kubernetes address a lot of the complexity; they handle resource isolation and utilization, networking, and deployments nicely. But a lot of the involved complexity such as load balancing, rollout scenarios, circuit breaking, retries, rate limiting, observability, tracing, and transport security is still left up to the development teams.

Of course, you can address all of these challenges in your microservices programmatically using popular open source components such as Hystrix, Ribbon, Eureka, the EFK Stack, Prometheus, or Jaeger. But unfortunately, this approach can quickly lead to excessive library bloat, and suddenly your microservices are not quite so micro anymore.

All this might seem acceptable if you’re on a single, consistent development stack like Java EE or Spring Boot. But tackling these complexities becomes even more challenging if you’re dealing with multiple stacks and multiple frameworks, to say nothing about dealing with legacy applications that you can’t modify to retrofit these requirements.

In comes Istio to the rescue. It is a so-called service mesh that addresses many of the cross-cutting communication concerns in a microservice architecture. Think of Istio as AOP (aspect-oriented programming) for microservice communication. Instead of implementing everything directly within your services, Istio transparently injects and decorates the desired concerns into the individual communication channels.

Transcript

1. Mario-Leander Reimer, QAware GmbH mario-leander.reimer@qaware.de Putting microservices on a diet with Istio London, 29th October 2018
2. Mario- Leander Reimer Principal Software Architect, QAware GmbH Mail: mario- leander.reimer@qaware.de Twitter: @LeanderReimer Github: https://github.com/lreimer/ Slides: https://speakerdeck.com/lreimer/ 28.10.18 2 Developer && Architect 20+ years of experience #CloudNativeNerd Open Source Enthusiast Speaker && Author
3. Fork me on Github. https://github.com/lreimer/microservice-diet-with-istio
4. 4 https://imgur.com/gallery/LGAZEqu The Early Code Monkey The Monolith
5. autonomous message driven loosely coupled stateless bounded contexts makeameme.org
6. Essential Cloud-native Design Principles. 6 Design for Distribution: Containers; microservices; API driven development. Design for Configuration: One image, multiple environments. Design for Resiliency: Fault-tolerant and self-healing. Design for Elasticity: Scales dynamically and reacts to stimuli. Design for Delivery: Short roundtrips and automated provisioning. Design for Performance: Responsive; concurrent; resource efficient. Design for Automation: Automated Dev & Ops tasks. Design for Diagnosability: Cluster-wide logs, metrics and traces. Design for Security: Secure Endpoints, API-Gateways, E2E-Encryption
7. 7 Atomic Architecture
8. Atomic Microservice Blueprint. 8
9. Concrete Blueprint Incarnation with Spring Cloud Netflix. 9 Some Facts: 58 MB Uberjar 192 Dependencies 3 KB Classes
10. A polyglot microservice architecture suffers from severe library bloat and bad maintainability in the long run. 10
11. Istio is like AOP, but for microservice communication.
12. Istio to the Rescue! 12
13. Conceptual View on a Kubernetes Cluster. 13
14. Demo
15. Pods are the smallest unit of compute in Kubernetes Labels are key/value pairs used to identify Kubernetes resources Replica Sets ensure that the desired number of pod replicas are running Deployments are an abstraction used to declare and update pods, RCs, … Services are an abstraction for a logical collection of pods providing DNS name Ingress routes traffic from outside the cluster to services and ports based on URL patterns and host Kubernetes Glossary. 15
16. GoF in the Cloud: Container Orchestration Patterns. 16 http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html 1. Sidecar Container: Extend container behaviour Log Extraction / Reformating (fluentd, logstash) Scheduling (cron, quartz) 2. Ambassador Container: Proxy communication TLS Tunnel (Stunnel, ghostunnel, Istio) Circuit Breaking (linkerd, Istio) Request Monitoring (linkerd, Istio) 3. Adapter Container: Provide a standardized interface Monitoring (Prometheus) Configuration (ConfigMaps, Secrets, …)
17. Conceptual Istio Architecture and Components. 17
18. 18 Envoy: Sidecar proxy per microservice that handles inbound/outbound traffic within each Pod. Extended version of Envoy project. Gateway: Inbound gateway / ingress. Nothing more than a managed Envoy. Mixer: Policy / precondition checks and telemetry. Highly scalable. Envoy caches policy checks within the sidecar (level 1) and within envoy instances (level 2), buffers telemetry data locally and centrally, and can be run in multiple instances. Mixer includes a flexible plugin model. https://istio.io/blog/2017/mixer-spof-myth.html Pilot: Pilot converts high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Watches services and transforms this information in a canonical platform-agnostic model (abstracting away from k8s, Nomad, Consul etc). The envoy configuration is then derived from this canonical model. Exposes the Rules API to add traffic management rules. Citadel: CA for service-to-service authx and encryption. Certs are delivered as a secret volume mount. Workload identity is provided in SPIFFE format. https://istio.io/docs/concepts/security/mutual-tls.html
19. Demo
20. Gateway configures a load balancer for HTTP/TCP traffic, enables ingress traffic into the service mesh Virtual Service defines the rules that control how requests for a service are routed within the service mesh Destination Rule configures the set of policies to be applied to a request after VirtualService routing has occurred Service Version aka Subset allows to select a subset of pods based on labels Service Entry enables requests to services outside of the service mesh Istio Glossary. 20
21. apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: hello-istio-gateway spec: selector: # use istio default controller istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "hello-istio.cloud" Example Istio Gateway and VirtualService Definitions. 21 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: hello-istio spec: hosts: - "hello-istio.cloud" gateways: - hello-istio-gateway http: - match: - uri: exact: /api/hello route: - destination: host: hello-istio port: number: 8080 Exact URI Routing
22. Hello Istio Demo
23. Different release patterns can easily be applied. 23
24. Different release patterns can easily be applied. 24
25. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: hello-istio spec: hosts: - "hello-istio.cloud" gateways: - hello-istio-gateway http: - route: - destination: host: hello-istio subset: v1 weight: 70 - destination: host: hello-istio subset: v2 weight: 30 Examples for different routing configurations. 25 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: hello-istio spec: hosts: - "hello-istio.cloud" gateways: - hello-istio-gateway http: - match: - headers: user-agent: regex: ".*Chrome.*" route: - destination: host: hello-istio subset: v2 - route: - destination: host: hello-istio subset: v1 Weighted Traffic Routing Header based Traffic Routing
26. Alphabet Demo
27. apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: alphabet-service spec: hosts: - alphabet-service http: - fault: delay: fixedDelay: 2s percent: 50 abort: httpStatus: 500 percent: 50 route: - destination: host: alphabet-service subset: v1 Examples for fault injection and circuit breaker policy. 27 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: alphabet-service spec: host: alphabet-service trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 tcp: maxConnections: 1 outlierDetection: baseEjectionTime: 5.000s consecutiveErrors: 1 interval: 1.000s maxEjectionPercent: 100 subsets: - name: v1 labels: version: v1 Circuit Breaker Policy Fault Injection
28. Istio has built-in support for service mesh diagnosability. 28 Diagnosability Triangle Metrics Logs Traces
29. Not all Istio features are marked Stable yet, but Beta can already be used in Production. 29 Istio v1.0.3 is deemed production ready. Core: 4 Stable, 3 Beta, 6 Alpha Traffic Management: 1 Stable, 5 Beta, 1 Alpha Security and Policy Enforcement: 5 Stable, 2 Beta, 4 Alpha Telemetry: 4 Stable, 2 Beta, 7 Alpha Other Service Mesh technologies are emerging. Linkerd and Conduit Consul Connect See https://istio.io/about/feature-stages/
30. Mario-Leander Reimer mario-leander.reimer@qaware.de @LeanderReimer xing.com/companies/qawaregmbh linkedin.com/company/qaware-gmbh slideshare.net/qaware twitter.com/qaware youtube.com/qawaregmbh github.com/qaware