Serverless Toronto meetup group

1. Serverless Application
Using Event Streams
to orchestrate a
Jonathan Dee ( jon ) jd@tikisprings.com
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?

17. ❏Event Streams
❏Message Bus

18. ❏Event Streams
❏Message Bus

19. ❏Event Streams
❏Message Bus

20. ❏Event Streams
❏Message Bus

21. ❏Event Streams
❏Message Bus

22. ❏Event Streams
❏Message Bus

23. ❏Event Streams
❏Message Bus

24. ❏Event Streams
❏Message Bus

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

31. Asynchronous message bus
Request
gateway
updateRequested

32. Asynchronous message bus
Request
gateway
updateRequested
200 , OK

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
jd@tikisprings.com
● cloud architecture
● serverless computing
● microservices design
● decoupling monolithic systems
● legacy migration
● database evolution

65. Questions ?