Distributed Tracing Of Microservices Neil Stevenson, Solution Architect, Hazelcast

Talk Outline Microservices are generally perceived as a better application style than monolithic code, and certainly this is a style that sits nicely within Cloud Foundry. However, it’s not all good news. One of the drawbacks to such decomposition is it can be very difficult to identify bottlenecks. In this presentation, Neil will show how it’s easy this can solved for Spring Boot users. A few beans and dependencies can activate tracing, and with Hazelcast as a service, trace information can be centrally captured from to a fault-tolerant scalable in-memory repository. Trace analysis can then be distributed across multiple service instances, without the performance bottleneck of a unclustered disk based resource.

Talk Outline 1 – Microservices 2 – Zipkin 3 – Hazelcast Misbehaving microservices 2 – Zipkin 3 – Hazelcast 4 – Demo, a solution !

1 - Microservices Q: What is a microservice ? A: Not the entire application in one deployment unit (my definition) => does one or a few functions for an application => ideally some sort of logical grouping to functions performed => ideally data separation, isolated domain models => may call other microservices => may be clustered => in CF terms an “app” or a “service”

1 - Microservices – the demo app Credit Cards - https://github.com/neilstevenson/cfeurope2017 A simple domain 1 => users have credit limits, how much they can spend 2 => transactions are permanent, record of money spent 3 => authorisations are transient and expiring, money you might spend Available credit is derived => (1 – (2 + 3))

1 - Microservices – the demo app Credit Cards - https://github.com/neilstevenson/cfeurope2017 A web front end and REST/JSON microservices, all Spring Boot 1 => list users 2 => user first name and last name 3 => available credit for a user 4 => transactions list for a user 5 => authorisations list for a user Microservice 3 calls microservices 4 and 5

2 - Zipkin What is it ? An implementation of Open Tracing’s open standard for distributed tracing Part of the Open Tracing project Grew out from Google’s “Dapper” project Large scale distributed system tracing

2 - Zipkin Key concept : Spans & Traces A request to Application #1 might invoke calls to Application #2 and Application #3. Application #1 may appear slow if Application #2 takes a while Zipkin adds HTTP Headers so we can correlate the call to Application #2 as originating from a parent call to Application #1

2 - Zipkin Key concept : Spans & Traces A request to Application #1 might invoke calls to Application #2 and Application #3. Span is overall, Trace is the particular call

2 - Zipkin Architecture Separable… Zipkin User Interface Server App Storage traces

2 - Zipkin Architecture Storage => If only there was another…. zipkin.storage.type => Cassandra => MySql => In-Memory in JVM => not for Prod => If only there was another…. User Interface Server App Storage traces

2 - Zipkin How to configure it ? Set spring.application.name for Spring Boot Add <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId> </dependency>

3 - Hazelcast Hazelcast is a software company based in Palo Alto Silver member of the Cloud Foundry Foundation Two free open-source software products, with optional commercial enhancements

3 - - In-Memory Data Grid Java storage, but connectors for .NET, Node.js, etc Production grade, widely used Spring Boot supports for auto-configuration Many many features, but for today Provides java.util.concurrent.ConcurrentMap => sharded across multiple JVMs, scalable => backed up across multiple JVMs, robust => with querying and indexes => with optional (commercial) monitoring => with a @Repository wrapper for Spring

3 - - In-Memory Data Grid Java cluster Key-Value Map Split across JVMs Duplicated

3 - - In-Memory Data Grid Java cluster Java & non-Java clients Clojure community effort, perhaps GoLang next

4 - Demo Several moving parts Some in and some out of CF => Zipkin server => Hazelcast storage JVMs => 1 web application, 1 instance of this => 5 microservices, 1 instance of each => one is misbehaving Some in and some out of CF => The usual legacy jumble => HTTP to the rescue Not a greenfield, a brownfield!

4 - Demo Zipkin Server Traces MS 1 WEB APP MS 2 Hazelcast Server 3 MS 5 Trans Trans

4 - Demo

5 - Summary Add: Set: Track: A Zipkin server ”spring-cloud-starter-zipkin” to your dependencies “spring.application.name” to YML => and Spring Boot does the REST Set: “zipkin.storage.type=hazelcast” Track: “http://zipkin.io/ for updates, such as Zipkin2

The End Today neil@hazelcast.com https://github.com/neilstevenson/cfeurope2017 The basis http://opentracing.io/ http://zipkin.io/ https://hazelcast.org/ https://github.com/spring-cloud/spring-cloud-sleuth Current version of Zipkin 2.2.1 Demo using 1.28.2, still evolving