Eda on the azure services platform
Download as PPTX, PDF1 like1,499 views
This document summarizes a presentation on implementing an event-driven architecture on the Windows Azure platform. The presentation discusses design challenges of cloud computing like latency, lack of distributed transactions, and instance availability. It then introduces event-driven architecture as a solution, covering event processing styles, loose coupling, and the relationship to CQRS. The presentation demonstrates how to address the cloud challenges through compensating events, eventual consistency, and autonomous services. It provides examples of using technologies like Azure queues, StreamInsight, and NServiceBus to build the architecture.
Eda on the azure services platform
- 1. Windows Azure User GroupEvent Driven Architecture on the Azure Services Platform27/05/2010
- 2. Yours trulyYves GoelevenSolution Architect @ CapgeminiMS Community Lead @ CapgeminiBoard member @ AzugContact me @Cloudshaper.wordpress.comMscop.be.capgemini.comTwitter.com/YvesGoelevenFacebookLinkedinYves@goeleven.com
- 3. IntroductionWhat are we going to discuss today?
- 4. AgendaIntroductionDesign challengesEvent driven architectureEvent Flow LayersEvent Processing StylesExtreme Loose couplingRelationship to CQRSAnswering the challengesTechnology MappingDemo & Implementation DetailsQuestions
- 7. SQL AzureBusiness AnalyticsReportingData SyncDatabase
- 8. The beauty of cloud computingInfinite compute and storage capacityOn demandExtreme flexibilityWithout upfront investmentsReduces overall costsBetter for the environment
- 9. Design challengesAren’t there any downsides to cloud computing then?
- 10. Impact of scaleLarge scale systems suffer fromData latencyNo distributed transactionsGlobal systems No guaranteed instance availability
- 11. LatencyAzure FabricData overlayData replication over peersMultiple failure & upgrade domainsMachines in different racksOr even different datacentersDepending on traffic and data sizeThis might lead to latency
- 12. No distributed transactionsThe very nature of 2 phase commitMakes each machine confirm twice in the commit processAdding more machinesMakes the commit process exponentially slowerThis drastically limits scalabilitySo distributed transactions are not supported in the cloud!
- 13. Instance availabilityAzure is a global platformCan be used by anyone from anywhere, 24 / 7No windows for maintenance and upgradesThe automated update system will take your system down whenever it feels like it!Failure & upgrade domains counteract thisNeed at least 2 instances of each role
- 14. Traditional composite SOASynchronous request reply integration It assumes little to no latencyIt assumes data from queries to be accurateIt assumes distributed transactionsTo undo the work of services in case of failureIt assumes service availabilityAs consumer is waiting for service completion
- 15. Event Driven ArchitectureIf synchronous composite SOA is unsuitable for the cloud, what is?
- 16. What’s an event anywayNotable, interesting, thing that happens in the businessState change, opportunity, threshold, deviationFrom a technical perspectiveMessage: header & payloadEvents are completely self descriptiveAll relevant state is encapsulatedBut whom decides what ‘interesting’ means?
- 17. Inversion of communicationEvent generatorsEventStreamTimeEventconsumers
- 18. EventflowlayersEvent generatorEvent ChannelEvent Processing EngineDownstream activityEvent Processing ActionsPublishEvent Processing EngineNotifyStandingQueryInvoke serviceStart business processCapture
- 19. Event Processing StylesWhat does ‘interesting event’ mean ?
- 20. SimpleEvent ProcessingEvent generatorEvent ChannelEvent Processing EngineDownstream activityEvent Processing ActionsPublishEvent Processing EngineNotifySimple EventInvoke serviceStart business processCapture
- 21. StreamEvent ProcessingEvent generatorEvent ChannelEvent Processing EngineDownstream activityEvent Processing ActionsPublishEvent Processing EngineNotifySimple EventInvoke serviceStart business processCapture
- 22. Complex Event ProcessingEvent generatorEvent ChannelEvent Processing EngineDownstream activityEvent Processing ActionsPublishEvent Processing EngineNotifySimple EventInvoke serviceComplex Event SeriesStart business processCapture
- 23. Extreme Loose CouplingEvent driven architecture delivers…
- 24. Extreme loose couplingDecoupling in multiple dimensionsImplementationEvent generator and consumer’s implementation are not boundThey even don’t know about the other’s existanceAll information encapsulated in eventDistributionEvent generator and consumer can be physically separatedAs long as they can access the event channel
- 25. Extreme loose couplingDecoupling (Continued)TimeEvents encapsulate all informationThey can be stored for later processingEvolutionEvent generators and consumers can evolve independentlyUsually they are ‘added’ instead of ‘changed’, contributing to ease of management
- 26. Brewers CAP TheoremA distributed system can satisfy any two of these guarantees at the same time, but not all threeConsistencyall nodes see the same data at the same timeAvailabilitynode failures do not prevent survivors from continuing to operatePartition ToleranceThe system continues to operate even if it becomes partitioned due to loss of connectivity
- 27. Eventual consistencyEDA sacrifices consistencyBut will eventually become consistentCompensating events Errors and exceptions are events as wellAnd should end up in the event streamCompensating transactionsEvent Consumers should subscribe to compensating eventsTo make things right again
- 28. Eventual consistencyLocal transactions, or similar mechanics, are still supportedSo even if a role goes down while processing a compensating eventThe local transaction will ensure that the event gets processed laterEvent consumers must be completely autonomousThey should not rely on other servicesThe long forgotten SOA principle ‘Service Autonomy’, is mandatory in an EDA
- 29. Service AutonomyHow to achieve it?Make every event consumer (aggregate root)a stand alone state machineBlog Comment (Submitted, Accepted, Rejected)Encapsulate state transitions with Tentative operations Submit / Accept / RejectInternally it uses the currently known state risk mitigation logic
- 30. Service AutonomyGive it a memory (Partner state machine)The relevant last known states of it’s remote partnersRequired to properly implement risk mitigation logicThis allows forStale, locally stored, state out of order events
- 31. Apology based computingEventual Consistency presents some challenges to the UIUsers need to be informed that the systemIs working on it, instead of waiting for the resultThe system will get back to them laterIn case of failure or successTask oriented UI’s support this better than data oriented UI’s
- 32. Relationship to CQRSHaven’t I seensome of thisbefore?
- 33. Similar to CQRS* Events* Command QueryResponsibilitySegregationBrowserWorkerroleWeb roleSubmit New Blog PostCommandRequest/ReplyPublishQueryRequest/ReplyView Recent Blog Posts
- 34. It happened, live with itEventsBlog Post SubmittedWorkerroleBrowserWeb roleEventOnewayEventStreamQueryRequest/ReplyView Recent Blog Posts
- 35. Open for extensionExtensionPointsBlog Post SubmittedWorkerroleBrowserWeb roleEventOnewayEventStreamQueryRequest/ReplyView Recent Blog Posts
- 36. Answering The ChallengesHow does all of thissolve the design challenges in the cloud?
- 37. Answering the challengesLatencyEvent consumers listen to what’s happeningThey react to events when they receive themTime between event occurrence and processingIs probably irrelevant for the event consumerAs all information is encapsulated inside the eventTake into account that events may arrive out of orderRisk mitigation strategies requiredBased on local state and partner state machine
- 38. Answering the challengesAvailabilityIf the event channel technology is durableLike azure storage queuesEvent consumers can go down without impactThey will receive the events once they come back up again
- 39. Answering the challengesAvailabilityThe absence of events in the streamCan be detected by a stream event processingThis can result into a new eventTriggering a self healing processOr human intervention
- 40. Answering the challengesNo distributed transactionsCompensating eventsCompensation logic , local transactionsHumans can subscribe to them as wellTo fix the issues manually
- 41. Technology MappingWhat technology could I use to implement this…
- 42. Event channelTable storage queuesDurable might lead to dead queues thoughQueue management requiredSupports queue-peek-lockSimilar to local transactions.NetServicebus’ messagebuffersTemporarily durable will disappear if unusedSupports queue-peek-lockSimilar to local transactionsWCF’s RelaybindingsCan reach outside of the cloud Even across NAT &FirewallsNo transaction support
- 43. Event processing engineMicrosoft StreamInsightStream event processingComplex event processing.NetServicebus used to* have routersIdeal for forwarding eventsSupported any / all forwarding*Rumored to come back soon
- 44. Event processing engineOpen source to the rescueNServicebusLibrary to implement service bussesRouting scenariosPublisher (All)Distributor (Any)Simple event processingMessage handlersComplex event processingSaga pattern
- 45. DemoCanyou show me anexample?
- 47. Implementation DetailsHow the helldidyou do that!
- 48. NHibernateInteraction with Azure is through REST API’sManually crafting requestsManually parsing responsesIs cumbersomeCo-created an NHibernate driverTo do the heavy lifting of interacting with table storageProvides persistence ignorance
- 50. NServiceBusPerforms messaging on Queue StorageClient API ( IBus )Server API ( IHandleMessages<T> )Pub/Sub with durable subscriptionsDistribution based on worker availabilityUses Nhibernate and azure storage driver internallyFor all it’s storage needs
- 51. NServiceBusCustom extensionsAzure Queue TransportSubscription storage Worker availability managementSaga support (not yet finished)
- 52. Nservice Bus extensionsWalkingthrough the code…
- 53. ModulesIn order to cut costsModules loaded ad runtimeFrom blob storageFor all componentsAllows for dynamic views, message handlers and CEP queriesPlan to switch to MEFStructureMap as IOCWires it all together
- 54. CMS Module WORKERWalkingthrough the code…
- 55. StreamInsightEventEventEventEventEventEventEventEventEventEvent consumersEvent generatorsCEP Application at RuntimeCEP EngineDevices, SensorsPagers & Monitoring devicesStanding QueriesOutput AdaptersInput AdaptersWeb & Worker RolesWeb & Worker rolesEvent stores & DatabasesEvent Stores & DatabasesMonitoring SystemsStatic reference data55
- 57. Web RoleASP.Net MVCHeavy use of JQueryAsynchronous semanticsWYSYWIG styleExtremely apology basedNhibernate’s second level cache on by defaultEffectively queries memory most of the timeSynchronization through events of courseSwitching to IronRuby as view engineViews stored in blob storageAllows for runtime customization
- 58. CMS Module webWalkingthrough the code…
- 61. ANY QUESTIONS?Wouldthisguystill have a sociallife?
- 62. Thank you for coming!Spread the word! www.azug.be
Editor's Notes
- #18: Services do not communicate directlyInstead event generators constantly report what is happening Resulting in a stream of eventsEvent consumers may subscribe to these events And might react to them
- #19: Event generatorEvent sources come in many forms: Devices, humans, software, nature, …Event generators capture events from the sources, and translate them into a format understood by the event channelEvents are pushed onto the event channel by the generatorEvent ChannelThe event channel is a communication medium,transports the events throughout the systemPreferably it is durable, supports local transactionsAzure offerings that can fulfill this role: Queue storage, .NetServicebus’ messagebuffers, WCF’s RelaybindingsEvent Processing EngineContinuous and incremental processing of event streams with near-zero latencyIdentification of eventsStanding queries (aggregation, grouping, …)Event correlationEvent transformationWindow inspectionEvent forwardingDownstream activityResult of event processingPush : Service Invocation, Notification (Email, sms), Business Process Invocation (Workflow)Pull : Message handler from queue, RSS, Event Stores
- #34: Separation betweenreads (queries) and writes (commands)QueryUI queries directly from data storeData is potentially staleIs read-only from a UI perspectiveCan cache the data in memoryWill send messages to the command processing sideCommand processingAsynchronous by defaultTypically on other data or event storedoesn’t make sense for Azure table storageSynchronization Real time by means of eventsOr background processes
- #56: Used as a libraryIn a worker roleNot as easy to deploy as it looks …Standing QueriesImplemented with LinqOn top of the CepStream<T> constructCustom AdaptersInput AdapterOutput AdapterImplemented on top of the custom NServiceBus transport for queue storage