Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Neue zeiten verlangen nach neuen Paradigmen - Bernd Rücker

276 Aufrufe

Veröffentlicht am

Mehr als eine Dekade wurden Anwendungen in drei Schichten gebaut. Doch zunehmende Digitalisierung und Vernetzung führen zu einer Komplexität, derer man mit dieser Architektur nicht mehr Herr wird. Daher gibt es viele neue Paradigmen und Trends wie z.B. Microservices, Cloud, Serverless, Event Driven Architecture oder Domain Driven Design. Was ist da dran und wie wirkt sich das alles auf BPM aus? Dieser spannenden Frage wird Camunda-Mitgründer Bernd Rücker nachgehen. Dabei wird er den Bogen von methodischen Aspekten rund um Prozessmodellierung und Ownership bis hin zu technischen Architekturen und Herausforderungen spannen.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Neue zeiten verlangen nach neuen Paradigmen - Bernd Rücker

  1. 1. Neue Zeiten verlangen nach neuen Paradigmen bernd.ruecker@camunda.com Co-founder and developer advocate
  2. 2. Neue Zeiten verlangen nach neuen Paradigmen …und nach englischen Folien…
  3. 3. Software is eating the world. Marc Andreessen, Entrepreneur & Investor „
  4. 4. Applications Platforms & collaborating systems
  5. 5. Do you know Game Neverending?
  6. 6. But you probably know flickr?
  7. 7. to pivot | pivoted, pivoted | [Tech]
  8. 8. If you are not embarrassed by the first version of your product, you’ve launched too late. Reid Hoffman, Co-Founder LinkedIn (and others) „
  9. 9. Microservices: It is about speed and agility at scale • Small components with clear responsibilities • Isolation • Autonomy • Replaceability • Flexibility • Experimentation • Resilience • Individual scalability DevOps, polyglott, asynchronous, reactive, message- / event-driven
  10. 10. Example InventoryPayment ShippingCheckout Bus
  11. 11. Example InventoryPayment ShippingCheckout Bus Order Placed Does not know recepient Does not know sender Event: Fact that happened in the past, Immutable fact, 0..n recepients Order Placed
  12. 12. It is not SOA InventoryPayment ShippingCheckout Bus Order Placed Does not know recepient Does not know sender Event: Fact that happened in the past, Immutable fact, 0..n recepients Order Placed Smart endpoints and dumb pipes
  13. 13. Distributed systems
  14. 14. Service A Challenge: Asynchronous collaboration Send message to B Service B Wait for response Timeout handling Message correlation & deduplication State handling Parallelism & merging
  15. 15. Challenge: Distributed transactions 1. book hotel 2. book car 3. book flight 6. cancel hotel 5. cancel car 4. In case of failure trigger compensations book trip Service A Car ServiceHotel Service Flight Service ACID-Transactions only local in the service contexts Distributed transaction via Saga pattern using compensating activities
  16. 16. BPMN can help
  17. 17. BPMN can help
  18. 18. BPMN can help
  19. 19. Toolbox for distributed systems Handling of time & timeouts Retry Versioning Compensation & Saga Message correlation & deduplication Performance & scalability
  20. 20. The microservice community *Picture randomly taken from http://wareflo.com/2016/11/from-apis-to-microservices-workflow-orchestration-and-choreography-across-healthcare-organizations/. Not connected to statements on slide. Orchestration… …introduces single point of failure… …leads to god services… …leads to tight coupling… „
  21. 21. Example InventoryPayment ShippingCheckout Bus Order Placed Decentral data management Event: Fact that happened in the past, Immutable fact, 0..n recepients Customer status changed
  22. 22. End-to-end processes using eventflows? InventoryPayment ShippingShop Order placed Payment received Goods fetched Goods shipped
  23. 23. Commanding is important InventoryPaymentOrder ShippingShop Bus Order Placed Event: Fact that happened in the past, Immutable fact, 0..n recepients Order Placed Command: Intend, 1 recipient. Coupling the other way round Retrieve Payment Fetch Goods Ship Goods
  24. 24. The case for orchestration
  25. 25. The end-to-end order process?
  26. 26. End-to-end processes cross microservice boundaries Order Inventory Payment
  27. 27. For execution: respect boundaries and distribute ownership
  28. 28. Payment Processes are “implementation detail” of services Order Distributed orchestration
  29. 29. And that‘s good?
  30. 30. End-to-end processes as 1st class citizen InventoryPaymentOrder ShippingCheckout Core Capabilities Support Capabilities Business Capabilities
  31. 31. Finally!
  32. 32. Order Order Order Order Architecture Order Engine A Payment Engine B Monitoring Human Task Management Coarse grained central monitoring Fine grained monitoring & operations (per context) DevOps Tec Ops Biz Ops Central
  33. 33. Code: https://github.com/berndruecker Slides: https://bernd-ruecker.com

×