Microservice Observability

Microservice Observability

Transcript

1. Microservices Observability Cláudio E. de Oliveira Arquiteto & Software Engineer claudio.oliveira@sensedia.com
2. AGENDA Microservices Drawbacks Kubernetes Open Tracing Spring Cloud Sleuth Service Mesh ISTIO 1 2 3 4 5 6
3. Where we come from Campinas-SP São Paulo-SP Rio de Janeiro-RJ Sensedia no mundo 2007 2009 2012 Fundada como Especialista SOA CI&T spinoff GARTNER SOA Governance Magic Quadrant Lançamento Sensedia API Platform 2015 Primeira Edição APIX 2016 FORRESTER - Strong Performers | Forrester Wave API Mgmt Q4 2016 GARTNER - Visionaries | Oct, 2016 Magic Quadrant Full Lifecycle API Management
4. whoami! I am Claudio de Oliveira Book Author, Software Architect and Developer work @sensedia APIs, Spring and Docker enthusiast @claudioed on Twitter /claudioed on Github http://claudioed.tech
6. Glossary › Telemetry How to collect data that will provide observability (sensors) › Observability Monitoring, Alerting and Visualizations, Distributed Tracing and Log Aggregation.
7. MICROSERVICES DRAWBACKS
8. Fallacies of distributed computing › the network is reliable › latency is zero › bandwidth is infinite
9. Microservices Drawbacks › How microservices connect each other › Network Latencies can be a bottleneck › Network can be unreliable › Control the UP and Running instances › It increase the non-functional requirements
10. your system doesn't look like this: service1 service2 service4 service3 DB
11. ...it looks more like this: frontend ... Service1 10.0.0.11 service1 10.0.0.34 Service1 10.0.0.36 Service1 10.0.0.23 service1 10.0.0.4 service2 10.0.0.40 Service2 10.0.0.25 Service3 10.0.0.1 service3 10.0.0.17 Service3 10.0.0.7
12. Network Latency Problems › Which microservice was responsible? › How to find out where the defect is? › How know what is generally happening during a request?
14. Introducing Kubernetes Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.
15. Kubernetes Architecture Diagram
16. “ Kubernetes was designed to orchestrate containers and run container across multiple machines.
17. Now we are ready to talk about Observability...
18. The OpenTracing standard › Cloud Native Computing Foundation (CNCF) › it standardizes the instrumentation of applications for distributed tracing › its says a trace tells the story of a transaction › while a span represents a single call › distributed tracing systems collect and organize all this information in a nice interface and Zipkin is one of them
19. We need to emit some events or data to someone collect...
20. SPRING CLOUD SLEUTH Services interactions instrumented automatically
21. Features › Adds trace and span ids to the SLF4J Mapped Diagnostic Context (MDC) › Automatically instruments common ingress and egress points from Spring applications (servlet filter, rest template, feign client) › just add spring-cloud-sleuth-zipkin dependency and the service will generate and send traces to Zipkin via HTTP
22. Ways to emit data Popularized by Netflix OSS and Spring Cloud Spring Framework enable it in Spring Boot All these features works only in JVM languages
24. Let’s think a little bit differently...
25. What about the platform infrastructure for service communications ???
26. ISTIO
27. But before, we need to learn some new concepts...
28. Sidecar Pattern
29. Sidecar Pattern A service which can enrich the main service with utility tasks. Normally these tasks are cross-cutting and infrastructure related.
30. Sidecar Pattern
31. A service mesh is a configurable infrastructure layer for a microservices application. Service Mesh
32. Goal › Service Mesh was designed to be that would handle the service communications.
33. This approach can give us some advantages › We can take off some responsibilities from our microservices › Ribbon, Hystrix, Metrics and Tracer (OSS) › The platform can provide it for us. › Polyglot
34. Service Mesh Features › Sidecar Proxy › Service Discovery & Load Balancing › Circuit Breaking › Fault Injection › Can be used in legacy systems
35. Istio Deployment
37. PILOT Component that programs the Envoy proxies, responsible for service discovery, load balancing, and routing.
38. MIXER Component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from Envoy and other services
39. ISTIO ADD-ONs Open-Source components which will work together to provide some additional functionalities
40. Prometheus Grafana Jaeger Open Source
41. Demo Time
42. Use Case - Architecture Diagram