Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices - Do one thing well

143 views

Published on

myposter Tech Talk: Microservices - Do one thing well

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Microservices - Do one thing well

  1. 1. Microservices Do one thing well
  2. 2. Übersicht Was sind µServices? Nachteile / Vorteile Definitionen Voraussetzungen Integration Aufteilen des Monolithen + Datenbank Wie anfangen? Beispiel Zusammenfassung Quellen
  3. 3. Was sind µServices? Kleine, autonome Services (Dienste), die zusammen arbeiten. Do one thing well
  4. 4. Wie klein ist „klein“? Single Responsibility Principle nach Robert C. Martin „Gather together those things, that change together for the same reason.“ „small enough, but not smaller“
  5. 5. Autonom Selbständig deploybar Kann der Service deployed werden, ohne etwas anderes ändern zu müssen? Decoupling Auch auf Teamebene!
  6. 6. Nachteile Viele deploybare Einheiten Hohe Modularisierung erforderlich Latenzen Können ausfallen - Murphy’s Law Größere Infrastruktur
  7. 7. Vorteile Unabhängige Technologien verwenden (MySQL, ElasticSearch, Java, PHP,…) Fehler kaskadieren nicht Hochskalierbar Leichtes Deployment einzelner Einheiten Composability - Zusammensetzbar Austauschbar Entwicklung einzelner Komponenten
  8. 8. Voraussetzungen für µServices Struktur des Unternehmens lässt es zu Team ist verantwortlich für den µService Entwicklung neuer Features dauert, im Moment, lange Monitoring/Logging You build it, you run it, you panic Conway’s Law
  9. 9. Integration Avoid breaking changes
  10. 10. Integration Orchestration Choreography Service 1 Service 2 Service 3 Service 4 Service 1 Event„Befehl“ „Befehl“ „Befehl“ Service 2 Service 3 Service 4 Veröffentlicht Subscribes Subscribes Subscribes
  11. 11. Integration Orchestration Choreography God-Classes Vorteile Nachteile Mehraufwand Monitoring Tracking Einfacher zu implementieren Weniger Abhängigkeiten Flexibler mehrere CRUD-Classes
  12. 12. Integration Synchron Asynchron Einfacher Wissen: erfolgreich? Blockiert Long running jobs Blockiert nicht annehmen, es hat funktioniert Request/Response Event-based
  13. 13. Integration - Request/Response RPC - gRPC REST HATEOAS gRPC Remote Procedure Calls, of course!
  14. 14. Integration - Event Based Message Queues RabbitMQ HTTP (ATOM)
  15. 15. Integration - Zusatz Service as State Machines Reactive Extensions Observables Semantic Versioning Koexistierende Endpoint-Versionen Migration zu neuen Endpunkten
  16. 16. Zusatz Immer davon ausgehen, dass der Service nicht funktioniert „Be conservative in what you do, be liberal in what you accept.“ Postel’s Law API Gateway Kein wildes Service->Service
  17. 17. Anfang Neue Features als µService SharedDB beibehalten Bounded contexts finden Stück-für-Stück in µServices auslagern Abhängigkeiten aufheben - Decoupling Business capabilities?
  18. 18. Aufteilen des Monolithen Abhängigkeiten erkennen modularisieren Jedes Modul (jeder bounded Context) Ein µService
  19. 19. Pattern http://microservices.io/patterns/microservices.html
  20. 20. Datenbank?
  21. 21. Datenbank Monolithischer Service Service Code 1 Service Code 2 monolithische Datenbank Monolithischer Service Service Code 1 Service Code 2 Datenbank Service 1 Datenbank Service 2
  22. 22. Service 1 Service 2 Datenbank Service 1 Datenbank Service 2 Foreign Keys? Weglassen - in den Services managen Transactions?
  23. 23. Transactions Transactional boundaries - pro Service Distributed transactions —> Transaction Manager Compensating transactions wenn eine fehlschlägt (Queue) Eventual consistency Transactions nicht aufteilen, wenn wirklich nötig
  24. 24. Beispiel - Uber https://eng.uber.com/soa/
  25. 25. Schwer, den richtigen Service zu finden (viele!) Beispiel - Uber Wenn gefunden: wie ansprechen? REST? RPC? standardisierter Weg Services zu definieren IDL - Apache Thrift Strikte Regeln -> „Vertrag“ Interfaces ändern sich nicht plötzlich - Fehler auf Thrift-Ebene Interface definition language
  26. 26. Zusammenfassung No silver bullet Anfangs mehr Aufwand nötig Größere Infrastruktur Schnelleres Deployment Mehr Fehlerquellen Keine Abhängigkeiten
  27. 27. Quellen Building Microservices - Sam Newman http://microservices.io/ Zalando - https://www.youtube.com/watch?v=I9zpROdDf48 https://dzone.com/articles/microservices-in-practice-1 https://eng.uber.com/building-tincup/ Das Beispiel - https://eng.uber.com/soa/

×