Microservices sind kleine, autonome Dienste, die unabhängig voneinander funktionsfähig sind und ein hohes Maß an Modularität bieten. Sie haben sowohl Vor- als auch Nachteile, einschließlich höherer Komplexität und der Notwendigkeit robuster Überwachungsstrategien, während sie gleichzeitig die Skalierbarkeit und Flexibilität fördern. Der Übergang von monolithischen Architekturen zu Microservices erfordert eine sorgfältige Planung und Integration, einschließlich der Berücksichtigung von Datenbanken, Transaktionsmanagement und Kommunikationsprotokollen.

1. Microservices
Do one thing well

2. Übersicht
Was sind µServices?
Nachteile / Vorteile
Definitionen
Voraussetzungen
Integration
Aufteilen des Monolithen + Datenbank
Wie anfangen?
Beispiel
Zusammenfassung
Quellen

3. Was sind µServices?
Kleine, autonome Services (Dienste), die zusammen arbeiten.
Do one thing well

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. Autonom
Selbständig deploybar
Kann der Service deployed werden, ohne etwas anderes ändern zu müssen?
Decoupling
Auch auf Teamebene!

6. Nachteile
Viele deploybare Einheiten
Hohe Modularisierung erforderlich
Latenzen
Können ausfallen - Murphy’s Law
Größere Infrastruktur

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. 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. Integration
Avoid breaking changes

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. Integration
Orchestration Choreography
God-Classes
Vorteile
Nachteile Mehraufwand
Monitoring
Tracking
Einfacher zu implementieren Weniger Abhängigkeiten
Flexibler
mehrere CRUD-Classes

12. Integration
Synchron Asynchron
Einfacher
Wissen: erfolgreich?
Blockiert
Long running jobs
Blockiert nicht
annehmen, es hat funktioniert
Request/Response Event-based

13. Integration - Request/Response
RPC - gRPC
REST
HATEOAS
gRPC Remote Procedure Calls, of course!

14. Integration - Event Based
Message Queues
RabbitMQ
HTTP (ATOM)

15. Integration - Zusatz
Service as State Machines
Reactive Extensions
Observables
Semantic Versioning
Koexistierende Endpoint-Versionen
Migration zu neuen Endpunkten

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. 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. Aufteilen des Monolithen
Abhängigkeiten erkennen
modularisieren
Jedes Modul (jeder bounded Context)
Ein µService

19. Pattern
http://microservices.io/patterns/microservices.html

20. Datenbank?

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. Service 1 Service 2
Datenbank
Service 1
Datenbank
Service 2
Foreign Keys?
Weglassen - in den Services managen
Transactions?

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. Beispiel - Uber
https://eng.uber.com/soa/

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. Zusammenfassung
No silver bullet
Anfangs mehr Aufwand nötig
Größere Infrastruktur
Schnelleres Deployment
Mehr Fehlerquellen
Keine Abhängigkeiten

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/