Building Applications with the Typesafe Reactive Platform at Skills Matter, London, November 17, 2015

The Typesafe Reactive Platform recently gained some interesting new features, geared towards advanced usage scenarios. We are going to introduce them in some detail and discuss their strengths and limitations.

Split Brain Resolver - define a strategy to survive network partitioning in your Akka Cluster application

Reactive Monitoring - get valuable metrics for your Akka actors

Play User Quota - restrict quality of service for some, in order to provide availability for all

Transcript

1. Building Applications with the Typesafe Reactive Platform Lutz Huehnken - Solutions Architect @lutzhuehnken
2. What is the Reactive Platform (RP)? • RP is targeted towards enterprises that are launching and maintaining Reactive applications in production. • A curated, certified build for simplified development and deployment • Additional features not available in the open source projects.
3. Reactive Platform Versioning 15v01p05 year month patch = Scala 2.11.2 Akka 2.3.3 … 15v09p01 = Scala 2.11.7 Akka 2.3.12 … https://together.typesafe.com/products/reactivePlatform
4. Split Brain Resolver (Slides courtesy of Konrad Malawski)
5. Split Brain Resolver • Fundamental Problem in all distributed systems • SBR helps to make decisions, is not a magic wand • A set of pre-built strategies 
 for when to down nodes in a cluster. • Strategies: • Static Quorum (like zoo-keeper) • Keep Majority • Keep Oldest • Keep Referee http://doc.akka.io/docs/akka/rp-15v09p02/scala/split-brain-resolver.html
6. Heartbeats A heartbeats heartbeats
7. Heartbeats A heartbeats heartbeats everyone is down!
8. Heartbeats A `n-1` is down! I’ll take over `A`!
9. Heartbeats A `n-1` is down! I’ll take over `A`! A good if: n-1 really is down. bad: if n-1 is just very unresponsive Fundamentally, it is hard to distinguish the two states in distributed systems.
10. Static Quorum (3 (> (n/2 +1)) A
11. Static Quorum (3 (> (n/2 +1)) we need to down ourselves A
12. Keep Majority (aka. dynamic quorum) A
13. Keep Majority (aka. dynamic quorum) A we need to down ourselves
14. referee node Keep Referee A down-all-if-less-than-nodes
15. referee node Keep Referee A can’t see referee node! down-all-if-less-than-nodes
16. oldest node Keep Oldest A can’t see oldest node! down-if-alone oldest node can change, if “up until now oldest node” leaves the cluster. This is more dynamic than keep-referee.
17. Monitoring
18. Monitoring Async Apps—New Challenges • Context is lost • Stack traces less useful • Expensive to collect all steps
19. Monitoring Async Apps—Too Much Data • Which actors do we track? • What do we keep? • What do we filter out? • What do we aggregate?
20. Instrumentation • Instrumented Reactive Platform • Configurable actor metrics • Actor-specific events • Traces across actors
21. Instrumentation • Instrumented Reactive Platform • Configurable actor metrics • Actor-specific events • Traces across actors
23. Play User Quotas
24. Play User Quotas • Control the service level that you provide to your users. • Quotas lets you track each user’s usage and restrict access when usage exceeds limits that you set.
25. Play User Quotas Use Cases • On public websites, to stop users scraping your site. • When you’re providing a developer API for your website. APIs enforce rate limits - to get access to higher limits a developers need to validate their identity or pay a fee. • In your organization. You can provision and allocate resources fairly, you can ensure other internal users get clear feedback when they exceed agreed usage. • To limit how much data users upload in a period of time, to prevent your service being overloaded. • To slow down login attempts or other sensitive actions.
26. Play User Quotas • Per „account“ - can be IP, username, etc. • Works standalone and in a cluster!
27. ConductR
28. Reactive for DevOps What is ConductR? 28 ConductR is a solution for deploying and managing reactive applications across a cluster of machines.
29. Microservice Trade-offs 29 ..according to Mr. Martin Fowler
 - Distribution - Eventual Consistency - Operational Complexity Reactive for DevOps
30. Reactive for DevOps Microservice Trade-offs 30 - You need a mature operations team to manage lots of services, which are being redeployed regularly. And/or a tool that significantly simplifies that!
31. Reactive for DevOps Operational Complexity 31 So what do you really need in your operations environment to simplify things? - Convenient deployment format (e.g. in single-file format, ensuring consistency) - Convenient interface (to deploy, run, scale) - Service Lookup - Resiliency
32. Reactive for DevOps Deployment format 32 ConductR bundles - Contain all library dependencies of your app - And the configuration - SHA is generated and encoded in the file name - Unique identification, and consistency check - easy to create, with sbt or shazar ferry-boat-1.0-274dfbcb2946a41d4fa5d259578a9761aa0bf2a49d3b397f9cd2c6d772c78577.zip
33. Reactive for DevOps Deploy, run, scale 33 - ConductR control protocol is a REST api - Great for automation, building REST clients should be easy enough - In fact, we provide a simple one for the command line conduct load ferry-boat-1.0-274dfbcb2946a..c78577.zip conduct run 274dfbc conduct run —scale=3 274dfbc conduct stop 274dfbc conduct unload 274dfbc
34. Reactive for DevOps Service lookup 34 - Lookup service by assigned name - No need for additional infrastructure - „static“ (fail fast) or „dynamic“ BundleKeys.endpoints := Map(
 "ferry" -> Endpoint("http", services = Set(URI("http://:9666/ferry")))) === LocationService.getLookupUrl("/ferry", "http://127.0.0.1:9666")
35. Reactive for DevOps Resilience 35 - Any operations environment can only do so much. There’s no magic. - ConductR improves resiliency through: - Location transparency / proxying - handling node failure - the control protocol
36. HA Proxy integration (incl. re-configuration through cluster events) for resiliency
37. ©Typesafe 2015 – All Rights Reserved ©Typesafe 2015 – All Rights Reserved