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

Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Microservices

Embed Size (px)

Citation preview

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/

14 Tipps für die Nutzung von Microservices.

#01 Technologie-Vielfalt mit Vorsicht genießen

n Sprachen mit m Frameworks und x Bibliotheken in y Versionen

= Version(ierung)shölle

#2 Design neu lernen

#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

Zusammenfassung

Fragen?

Bei Fragen gern fragen ...