Using Event Streams in Serverless Applications
- 1. Serverless Application Using Event Streams to orchestrate a Jonathan Dee ( jon ) [email protected] November 20, 2018 Serverless Toronto Meetup Group
- 2. Where are we ?? Minecraft content and materials are trademarks and copyrights of Mojang and its licensors. All rights reserved.
- 3. Serverless means... ● No servers to provision or manage ● Scales with usage ● Never pay for idle ● Built-in high-availability and durability
- 4. Serverless means... ● No servers to provision or manage ● Scales with usage ● Never pay for idle ● Built-in high-availability and durability But what does Serverless mean to developers and architects ?
- 5. ● Abstracts away the idea of a server node Serverless means... ● No servers to provision or manage ● Scales with usage ● Never pay for idle ● Built-in high-availability and durability But what does Serverless mean to developers and architects ? virtual machine, instance, container ● Presents compute resources as high-level, reliable APIs
- 6. Leverage what cloud providers and serverless development kits give you ● compute ● storage, state ● streams ● queues ● network ● observability ● analytics ● build, deploy ● security ● backup, audit
- 7. ● compute ● storage, state ● streams ● queues ● network ● observability ● analytics ● build, deploy ● security ● backup, audit Leverage what cloud providers and serverless development kits give you
- 8. ● compute ● storage, state ● streams ● queues ● network ● observability ● analytics ● build, deploy ● security ● backup, audit Leverage what cloud providers and serverless development kits give you
- 9. ● compute ● storage, state ● streams ● queues ● network ● observability ● analytics ● build, deploy ● security ● backup, audit Leverage what cloud providers and serverless development kits give you
- 10. ©Copyright 2017, Hasbro. All Rights Reserved. HASBRO and its logo, and TINKERTOY are trademarks of Hasbro Powered By: a big bag of TinkerToy...
- 11. Common use cases (faas) ● Endpoint API-Gateway faas ● Trigger Object Store faas ● Stream Processing Event Source faas store faas store faas store faas store
- 12. Common use cases (faas) ● Endpoint API-Gateway faas ● Trigger Object Store faas ● Stream Processing Event Source faas store faas store faas store faas store all singleton faas implementations
- 13. What about a whole system?
- 25. ❏Event Streams ❏Message Bus ● Simplify integration ● Create an Extensible architecture ● Promote Event Driven Design
- 26. Event Driven Design Not so much about the Things ● Domain Objects ○ Customer ○ Order ● Entities ○ Customer ○ CustomerType ○ OrderHeader ○ OrderDetail More about the Verbs ● What's Happened ○ new customer was created ○ order was updated ● The Events ○ customerAdded ○ orderUpdated
- 27. ● A Notification ● State, or State Transfer ● Causality ● History Event Driven Design ● Facts of Information ○ Immutable (can't change, or be retracted) ● Events might invalidate, or supercede past Facts ● Events can be ignored by certain observers ● Knowledge is the accumulation of Facts ! What is an Event ? What are its characteristics ? Common use cases:
- 28. Event Driven Design Commands Events ● METHOD / ACTION on a Object ● Imperative: eg: CreateOrder, ShipProduct ● Represents something that HAS HAPPENED ● Past-Tense: eg: OrderCreated, ProductShipped 1. About Intent 2. Directed 3. Targeted destination 4. Control Focused 1. Intentless 2. Anonymous 3. Others Observe, some Ignore 4. Autonomy (compare / contrast)
- 29. Event Driven Design Commands Events ● METHOD / ACTION on a Object ● Imperative: eg: CreateOrder, ShipProduct ● Represents something that HAS HAPPENED ● Past-Tense: eg: OrderCreated, ProductShipped 1. About Intent 2. Directed 3. Targeted destination 4. Control Focused 1. Intentless 2. Anonymous 3. Others Observe, some Ignore 4. Autonomy (compare / contrast)
- 30. API Handler Program Logic Database Lookup Processing Database Write ↵ Processing ↵ Database Lookup ↵ Program Logic Synchronous call stack R U N T I M E
- 33. Asynchronous message bus Request gateway Data Decorator updateRequested updateReqPrepared
- 34. Asynchronous message bus Request gateway Data Decorator Update Handler updateRequested updateReqPrepared updateConfirmed
- 35. Asynchronous message bus Request gateway Data Decorator Update Handler Confirmation Broker updateRequested updateReqPrepared updateConfirmed
- 36. Asynchronous message bus Request gateway Data Decorator Update Handler Confirmation Broker updateRequested updateReqPrepared updateConfirmed confirmationDelivered Response gateway
- 38. Sink Drain Why the Queues ?
- 39. Sink Drain Why the Queues ? control parallelism concurrency knob
- 40. In a synchronous systems flow What about doing it the other way ? c.f. Little's Law Can you provide a sustained Request Rate by adjusting concurrency ? feedback loop ** Inspired by: "When Serverless Gets In the Way of Scalability" by Lily Li and Christian Zommerfelds, D2L, @ function18, Toronto, 2018 - Fixing one bottleneck, can result in just moving the bottleneck elsewhere - Not always easy to apply back-pressure where needed
- 41. Asynchronous message bus Request gateway Data Decorator Update Handler Confirmation Broker updateRequested updateReqPrepared updateConfirmed confirmationDelivered Response gateway extensible
- 42. Multiple Queue design You can add a "triage" worker upstream to prioritize different types of traffic into different queues
- 43. The mantra of a Queue Worker ● Listen for Events ● Publish Fact(s) ● Do one thing really well
- 44. The mantra of a Queue Worker ● Listen for Events ● Publish Fact(s) ● Do one thing really well Something else ? Not my problem!
- 45. Queue Workers Data Decorator Update Handler Confirmation Broker ● Independently : ○ scalable, deployable, versionable ● Ideally idempotent ● Avoid (synchronous) dependencies
- 46. Jonas Bonér , QConNewYork2018, DesigningEventsFirstMicroservices Concept analogous to what we've seen in Microservices Design (moving from monolith)
- 47. Jonas Bonér , QConNewYork2018, DesigningEventsFirstMicroservices
- 48. Queue Workers Data Decorator Update Handler Confirmation Broker ● Independently : ○ scalable, deployable, versionable ● Ideally idempotent ● Avoid (synchronous) dependencies ○ maybe "dependency" could be a separate worker ? ○ upstream ? downstream ?
- 49. Asynchronous message bus Request gateway Data Decorator Update Handler Confirmation Broker updateRequested updateReqPrepared updateConfirmed confirmationDelivered Response gateway
- 50. Events updateRequested updateReqPrepared updateConfirmed confirmationDelivered ● Can also be versioned ○ Upgrade/Downgrade xlat ○ maintain backward compatability ● Key to information flow ● Also key to Tracing, Debugging
- 51. Sample event-driven application Request gateway Update Handler Confirmation Broker updateRequested updateConfirmed confirmationDelivered Response gateway
- 52. Update Handler ● Listen for updateRequested ● Publish Facts: updateConfirmed, updateFailed ● Update dynamoDB ○ enforce data integrity ○ marshall request ○ receive reply bundle extra/new data into event
- 53. Sample event-driven application Request gateway Update Handler Confirmation Broker updateRequested updateConfirmed confirmationDelivered Response gateway +code sample
- 54. Confirmation Broker ● Listen for updateConfirmed ● Publish Facts: confirmationDelivered ● Send msg(s) over mqtt channels 2 channels (topics)
- 55. Demo Time ! and look at logs, tracing
- 56. Publish/Subscribe, Queues, Streams Which ? Serverless Streams, Topics, Queues, & APIs! How to Pick the Right Serverless Application Pattern From: Chris Munns – Senior Developer Advocate – AWS Serverless, August 2018
- 57. CQRS Command Query Responsibility Segregation Jonas Bonér , QConNewYork2018, DesigningEventsFirstMicroservices From:
- 58. Event Sourcing ● The Event Stream is the source of truth ● The database is just a snapshot of accumulated events at a certain point in time
- 59. Event Sourcing ● The Event Stream is the source of truth ✓ RDBMS already works in a similar way internally ● The database is just a snapshot of accumulated events at a certain point in time
- 60. Event Sourcing ● The Event Stream is the source of truth ✓ RDBMS already works in a similar way internally ✓ Microservices only keep subset snapshots of what they're interested in ● The database is just a snapshot of accumulated events at a certain point in time
- 61. Event Sourcing ● The Event Stream is the source of truth ✓ RDBMS already works in a similar way internally ✓ Microservices only keep subset snapshots of what they're interested in ✓ Can replay the log whenever needed ○ For auditing, tracing, adding observability metrics ○ On Failure ○ For Replication ○ For historic debugging ● The database is just a snapshot of accumulated events at a certain point in time
- 62. Event Sourcing ● The Event Stream is the source of truth ✓ RDBMS already works in a similar way internally ✓ Microservices only keep subset snapshots of what they're interested in ✓ Can replay the log whenever needed ○ For auditing, tracing, adding observability metrics ○ On Failure ○ For Replication ○ For historic debugging ● The database is just a snapshot of accumulated events at a certain point in time Time Travel !!
- 63. Go build something ! ● Take advantage of Free Tiers All major cloud providers offer some form of this ● Check out: AWS Appsync Build data driven apps with real time and offline ● Check out: AWS Amplify easily integrate cloud services into your front-end framework ● Check out: AWS Serverless Application Repo
- 64. Jonathan Dee [email protected] ● cloud architecture ● serverless computing ● microservices design ● decoupling monolithic systems ● legacy migration ● database evolution
- 65. Questions ?