The slides for my talk on how to implement an event driven architecture on top of the azure platform

1. Windows Azure User Group Event Driven Architecture on the Azure Services Platform27/05/2010

2. Yours truly Yves Goeleven Solution Architect @ Capgemini MS Community Lead @ Capgemini Board member @ Azug Contact me @ Cloudshaper.wordpress.com Mscop.be.capgemini.com Twitter.com/YvesGoeleven Facebook Linkedin Yves@goeleven.com

3. Introduction What are we going to discuss today?

4. Agenda Introduction Design challenges Event driven architecture Event Flow Layers Event Processing Styles Extreme Loose coupling Relationship to CQRS Answering the challenges Technology Mapping Demo & Implementation Details Questions

5. Windows Azure

6. .Net Service Bus

7. SQL Azure Business Analytics Reporting Data Sync Database

8. The beauty of cloud computing Infinite compute and storage capacity On demand Extreme flexibility Without upfront investments Reduces overall costs Better for the environment

9. Design challenges Aren’t there any downsides to cloud computing then?

10. Impact of scale Large scale systems suffer from Data latency No distributed transactions Global systems No guaranteed instance availability

11. Latency Azure Fabric Data overlay Data replication over peers Multiple failure & upgrade domains Machines in different racks Or even different datacenters Depending on traffic and data size This might lead to latency

12. No distributed transactions The very nature of 2 phase commit Makes each machine confirm twice in the commit process Adding more machines Makes the commit process exponentially slower This drastically limits scalability So distributed transactions are not supported in the cloud!

13. Instance availability Azure is a global platform Can be used by anyone from anywhere, 24 / 7 No windows for maintenance and upgrades The automated update system will take your system down whenever it feels like it! Failure & upgrade domains counteract this Need at least 2 instances of each role

14. Traditional composite SOA Synchronous request reply integration It assumes little to no latency It assumes data from queries to be accurate It assumes distributed transactions To undo the work of services in case of failure It assumes service availability As consumer is waiting for service completion

15. Event Driven Architecture If synchronous composite SOA is unsuitable for the cloud, what is?

16. What’s an event anyway Notable, interesting, thing that happens in the business State change, opportunity, threshold, deviation From a technical perspective Message: header & payload Events are completely self descriptive All relevant state is encapsulated But whom decides what ‘interesting’ means?

17. Inversion of communication Event generators EventStream Time Eventconsumers

18. Eventflowlayers Event generator Event Channel Event Processing Engine Downstream activity Event Processing Actions Publish Event Processing Engine Notify Standing Query Invoke service Start business process Capture

19. Event Processing Styles What does ‘interesting event’ mean ?

20. SimpleEvent Processing Event generator Event Channel Event Processing Engine Downstream activity Event Processing Actions Publish Event Processing Engine Notify Simple Event Invoke service Start business process Capture

21. StreamEvent Processing Event generator Event Channel Event Processing Engine Downstream activity Event Processing Actions Publish Event Processing Engine Notify Simple Event Invoke service Start business process Capture

22. Complex Event Processing Event generator Event Channel Event Processing Engine Downstream activity Event Processing Actions Publish Event Processing Engine Notify Simple Event Invoke service Complex Event Series Start business process Capture

23. Extreme Loose Coupling Event driven architecture delivers…

24. Extreme loose coupling Decoupling in multiple dimensions Implementation Event generator and consumer’s implementation are not bound They even don’t know about the other’s existance All information encapsulated in event Distribution Event generator and consumer can be physically separated As long as they can access the event channel

25. Extreme loose coupling Decoupling (Continued) Time Events encapsulate all information They can be stored for later processing Evolution Event generators and consumers can evolve independently Usually they are ‘added’ instead of ‘changed’, contributing to ease of management

26. Brewers CAP Theorem A distributed system can satisfy any two of these guarantees at the same time, but not all three Consistency all nodes see the same data at the same time Availability node failures do not prevent survivors from continuing to operate Partition Tolerance The system continues to operate even if it becomes partitioned due to loss of connectivity

27. Eventual consistency EDA sacrifices consistency But will eventually become consistent Compensating events Errors and exceptions are events as well And should end up in the event stream Compensating transactions Event Consumers should subscribe to compensating events To make things right again

28. Eventual consistency Local transactions, or similar mechanics, are still supported So even if a role goes down while processing a compensating event The local transaction will ensure that the event gets processed later Event consumers must be completely autonomous They should not rely on other services The long forgotten SOA principle ‘Service Autonomy’, is mandatory in an EDA

29. Service Autonomy How to achieve it? Make every event consumer (aggregate root) a stand alone state machine Blog Comment (Submitted, Accepted, Rejected) Encapsulate state transitions with Tentative operations Submit / Accept / Reject Internally it uses the currently known state risk mitigation logic

30. Service Autonomy Give it a memory (Partner state machine) The relevant last known states of it’s remote partners Required to properly implement risk mitigation logic This allows for Stale, locally stored, state out of order events

31. Apology based computing Eventual Consistency presents some challenges to the UI Users need to be informed that the system Is working on it, instead of waiting for the result The system will get back to them later In case of failure or success Task oriented UI’s support this better than data oriented UI’s

32. Relationship to CQRS Haven’t I seensome of thisbefore?

33. Similar to CQRS* Events * Command QueryResponsibilitySegregation Browser Workerrole Web role Submit New Blog Post Command Request/Reply Publish Query Request/Reply View Recent Blog Posts

34. It happened, live with it Events Blog Post Submitted Workerrole Browser Web role Event Oneway EventStream Query Request/Reply View Recent Blog Posts

35. Open for extension ExtensionPoints Blog Post Submitted Workerrole Browser Web role Event Oneway EventStream Query Request/Reply View Recent Blog Posts

36. Answering The Challenges How does all of thissolve the design challenges in the cloud?

37. Answering the challenges Latency Event consumers listen to what’s happening They react to events when they receive them Time between event occurrence and processing Is probably irrelevant for the event consumer As all information is encapsulated inside the event Take into account that events may arrive out of order Risk mitigation strategies required Based on local state and partner state machine

38. Answering the challenges Availability If the event channel technology is durable Like azure storage queues Event consumers can go down without impact They will receive the events once they come back up again

39. Answering the challenges Availability The absence of events in the stream Can be detected by a stream event processing This can result into a new event Triggering a self healing process Or human intervention

40. Answering the challenges No distributed transactions Compensating events Compensation logic , local transactions Humans can subscribe to them as well To fix the issues manually

41. Technology Mapping What technology could I use to implement this…

42. Event channel Table storage queues Durable might lead to dead queues though Queue management required Supports queue-peek-lock Similar to local transactions .NetServicebus’ messagebuffers Temporarily durable will disappear if unused Supports queue-peek-lock Similar to local transactions WCF’s Relaybindings Can reach outside of the cloud Even across NAT &Firewalls No transaction support

43. Event processing engine Microsoft StreamInsight Stream event processing Complex event processing .NetServicebus used to* have routers Ideal for forwarding events Supported any / all forwarding *Rumored to come back soon

44. Event processing engine Open source to the rescue NServicebus Library to implement service busses Routing scenarios Publisher (All) Distributor (Any) Simple event processing Message handlers Complex event processing Saga pattern

45. Demo Canyou show me anexample?

46. Architecture Web Web Web Web Web Queue Storage StreamInsight NServicebus AzureRoles CEP Publisher Publisher (All) Table Storage Distributor Distributor (Any) Worker Worker Worker Worker Worker

47. Implementation Details How the helldidyou do that!

48. NHibernate Interaction with Azure is through REST API’s Manually crafting requests Manually parsing responses Is cumbersome Co-created an NHibernate driver To do the heavy lifting of interacting with table storage Provides persistence ignorance

49. NhibernateDriver Walkingthrough the code…

50. NServiceBus Performs messaging on Queue Storage Client API ( IBus ) Server API ( IHandleMessages<T> ) Pub/Sub with durable subscriptions Distribution based on worker availability Uses Nhibernate and azure storage driver internally For all it’s storage needs

51. NServiceBus Custom extensions Azure Queue Transport Subscription storage Worker availability management Saga support (not yet finished)

52. Nservice Bus extensions Walkingthrough the code…

53. Modules In order to cut costs Modules loaded ad runtime From blob storage For all components Allows for dynamic views, message handlers and CEP queries Plan to switch to MEF StructureMap as IOC Wires it all together

54. CMS Module WORKER Walkingthrough the code…

55. StreamInsight Event Event Event Event Event Event Event Event Event Event consumers Event generators CEP Application at Runtime CEP Engine Devices, Sensors Pagers & Monitoring devices Standing Queries Output Adapters Input Adapters Web & Worker Roles Web & Worker roles Event stores & Databases Event Stores & Databases Monitoring Systems Static reference data 55

56. STREAMINSIGHT EXTENSIONS Walkingthrough the code…

57. Web Role ASP.Net MVC Heavy use of JQuery Asynchronous semantics WYSYWIG style Extremely apology based Nhibernate’s second level cache on by default Effectively queries memory most of the time Synchronization through events of course Switching to IronRuby as view engine Views stored in blob storage Allows for runtime customization

58. CMS Module web Walkingthrough the code…

59. RUNTIME Walkingthrough the code…

60. Let’sRecap We’refinallythere!

61. ANY QUESTIONS? Wouldthisguystill have a sociallife?

62. Thank you for coming! Spread the word! www.azug.be