microservice architecture applied. 14 praxis-tipps für die nutzung von microservices
TRANSCRIPT
Microservice architecture applied.
14 Praxis-Tipps für die Nutzung von Microservices.
Bildquelle: Stephanie Hofschlaeger / pixelio.de
Ramon AngerCapgemini
Micro ... was?
Bildquelle: BirgitH / pixelio.de Bildquelle: lichtkunst.73 / pixelio.de
Monolith MicroservicesGern 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
Welche Rolle spielen Microservices in der IT?
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
0% 5% 10% 15% 20% 25% 30% 35% 40%
#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/
#01 Technologie-Vielfalt mit Vorsicht genießen
n Sprachen mit m Frameworks und x Bibliotheken in y Versionen
= Version(ierung)shölle
#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/
#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
#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/
#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
#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/
#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
DevOpsOverhead für Operations abwägen
hochüberschaubar
und dann doch lieber
#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/
#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
#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
#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
#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
#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