Slide deck zu meinem Vortrag auf der Seacon am 08.05.2015

1. Microservice architecture applied.
14 Praxis-Tipps für die Nutzung
von Microservices.
Bildquelle: Stephanie Hofschlaeger / pixelio.de
Ramon Anger
Capgemini

2. Micro ... was?
Bildquelle: BirgitH / pixelio.de Bildquelle: lichtkunst.73 / pixelio.de
Monolith Microservices
Gern hunderttausende Zeilen Code Einige hundert Zeilen Code je Service
Intrinsisch von sich selbst abhängig Unabhängig von anderen Services
Artefakt für System Artefakt je Service
Gern viele Schichten Nur die notwendigen Schichten
Von großem Team gewartet werden Von kleinem Team gewartet
Potentiell komponenten-orientiert Lösen fachliche/technische Probleme
passgenau
In der Regel schwer austauschbar Leicht austauschbar

3. Welche Rolle spielen Microservices in der IT?
0% 5% 10% 15% 20% 25% 30% 35% 40%
Hyperscale
Microservices / APIs / Atomic Services
Public Cloud
DevOps
Converged Platforms (e.g. IBM PureSystems)
Containers (e.g. Docker, Rocket)
Server Virtualization
Converged Infrastructure (e.g. Cisco UCS)
Software Defined Networking / Storage
Network Function Virtualization
Private Cloud
#1 Trend
#2 Trend
#3 Trend
Please select the top three (3) technology trends that will have the highest impact
on your IT infrastructure trough 2017
Quelle: Saugatuck Technology, Cloud Infrastructure Survey, April 2015, n=327 (global), http://blog.saugatucktechnology.com/microservices-on-
the-horizon/

4. 14 Tipps für die Nutzung von Microservices.

5. #01 Technologie-Vielfalt mit Vorsicht genießen
n Sprachen mit m Frameworks
und x Bibliotheken in y Versionen
=
Version(ierung)shölle

6. #2 Design neu lernen

7. #3 Latency kills, parallelisieren
• HTTP-Requests kosten Zeit
• Microservices-Anwendungen führen viele HTTP-Requests durch
– Antwortzeitproblem
• Performanceoptimierung im Web: Bandbreite erhöhen
– Reduzierung der HTTP-Requests
• HTTP-Requests parallelisieren wo nur möglich
– Abfrage dauert so lange wie der langsamste Request
• Serviceschnitt unter Performance-Gesichtspunkten neu bewerten
Bildquelle: http://pixabay.com/de/stoppuhr-microchronometer-zeit-uhr-161283/

8. #4 Kein Enterprise Service Bus
• Service Bus?
– SOA wg. ESB häufig DOA (Dead on Arrival)
– Martin Fowler: Smart filters and dumb pipes*
• Microservice Service Registry
• Application Server (AS)?
– Microservice aus einigen hundert Zeilen Code benötigt AS?
– Mehrere AS Instanzen wg. Skalierung / Verfügbarkeit
• Ressourcen, Wartung, Lizenzgebühren
Bildquelle: http://commons.wikimedia.org/wiki/File:Singapore_Road_Signs_-_Restrictive_Sign_-_No_buses.svg
* http://martinfowler.com/articles/microservices.html

9. #5 Microservice mit Oberfläche?
• Martin Fowler: „Such services take a broad-stack implementation of software for
that business area, including user-interface, persistant storage, and any external
collaborations.“*
• Im eigenen Kontext nicht in jedem Fall praktikabel
– Microservices von Native Apps, Webseiten und Partner-Anwendungen verwendet
– Apps und Webseiten von Microservices getrennt
* http://martinfowler.com/articles/microservices.html
Bildquelle: http://pixabay.com/de/schere-muster-schere-schnitt-cutter-209583/

10. #6 Organisation durch Microservices gestalten
„... organizations which design systems [...] are
constrained to produce designs which are copies
of the communication structures of these
organizations ...“ (Mel Conway)
• Microservices bieten die Chance, Organisation so zu gestalten, dass die
angestrebte Architektur darin abgebildet wird
Melvin E. Conway, 1967, http://www.melconway.com/Home/Committees_Paper.html

11. #7 Microservices oder Testers Paradise
• Microservice: einige hundert Zeilen Code
– Fünf Klassen plus sieben Testklassen
– Beherrschbare Komplexität
• Verzicht auf Unit-Tests ist verlockend
– Fehlersuche schwieriger, aber machbar
• Alternative: nur Komponententests
– Testabdeckung vergleichbar hoch
– Risiko/Nutzen abwägen
• Integrationstests mit anderen Microservices
– Aufbau einer Integrationstestumgebung für viele Microservices für bestimmten
Test(zeitpunkt)  Integrationshölle
• Unbedingt auf Continuous Integration / Deployment setzen
Bildquelle: http://pixabay.com/de/seil-strick-geflochten-knoten-667314/

12. #8 Nur mit DevOps
• Bauen ist noch das Einfachste
• Individuelles Deployment  Overhead für Operations
– Container Engines helfen Komplexität zu kapseln  Rocket, Docker
Technologie-
vielfalt
DevOps
Overhead für
Operations
abwägen
hochüberschaubar
und dann doch lieber

13. #9 Security bitte passgenau
• Status Quo Schichtenarchitektur  mindestens ein Security Layer
• Bei Microservices abwägen
– Enthält Geschäftslogik kritische Informationen oder doch nur die Daten?
Firewall
Intrusion Detection System
SSO Login
Data Authorization
SSL Webservices
SSL
Firewall
Data
Authorization
Monolith Microservices
Bildquelle: http://pixabay.com/de/vorhängeschloss-sicherheit-sperre-308589/

14. #10 Querschnittsaspekte per Seitenwagen
• Jede Software beinhaltet Querschnittsaspekte
– Logging, Monitoring, Authentifizierung, Fehlerbehandlung, Validierung, Caching,
Persistenz, Synchronisierung, Transaktionen
• Entwickler neigen dazu Querschnittsaspekte mit jedem System neu zu erfinden
– Auch bei Microservices
• Netflix  Side Car Services
– Microservices in der selben VM
– Bieten Querschnittsaspekte als Service an
Bildquelle: http://commons.wikimedia.org/wiki/File:Sidecars_Isle_of_Man_TT_Race.jpg

15. #11 Synchronität verboten
• Asynchronität sicherstellen ist schwierig
– Größte Herausforderung neben Größe und Abgrenzung von Microservices
– Nicht nur Lastproblematik ... Ausfallsicherheit
– Listener, Message Queues
• Synchronität Alternative?
– Problem: Blockierende Ressourcen
– Innerhalb von Microservices ok; zwischen Microservices oder hin zum Service-Nutzer
ist No go
synchron

16. #12 Monitoring – Fäden zusammenhalten
• Monitoring von monolithischen Anwendungen überschaubar
– Anwendungen aus Microservices ist stark verteilt
• Überblick bei sehr vielen Microservices behalten schwierig
– Informationen über jeden einzelnen Webservice relevant
– Queues, Datenbanken, Fehler ...
Bildquelle: Martin Jäger / pixelio.de

17. #13 Microservices unterstützen Veränderung anders
• Funktionalität und Technologie ändern sich unterschiedlich schnell
• Microservices Architekturen unterstützen schwer vorhersehbare
Änderungsfrequenz besser als Monolithen
– einzelne Microservices sind leicht austauschbar
• Brownfield vs. Greenfield
– Sam Newman: Building Microservices
– Microservices bei Brownfield stabiler
Bildquelle: Janusz Klosowski / pixelio.de

18. #14 Microservices machen einsam ... heute
• Microservices sind immer noch sehr neu
• Nur wenige Patterns, Practices oder Guidelines verfügbar
– http://microservices.io
– Patterns und Practices aus Cloud- und DevOps-Umfeld helfen
– Reactive Programming
– Tools verstehen, erst dann einsetzen
• Keine Microservice Standards ... mit Blick auf WS-* nicht erstrebenswert
Heute mit Microservices einsetzen*
bedeutet echte Pionierarbeit leisten.
*und nicht bei Amazon, Netflix, Paypal, Ebay & Co arbeiten

19. Zusammenfassung

20. Fragen?
Bei Fragen gern fragen ...