Microservices
Last updated
Was this helpful?
Last updated
Was this helpful?
Microservices ist ein Modularisierungsansatz - ein Modul/Komponente/Service wird selbständig deployed. Durch Kombination mehrerer Microservices entsteht eine Lösung (= Anwendung).
Es gibt ganz unterschiedliche Meinungen dazu wie groß ein Mikroservice sein sollten. Von wenigen Zeilen Code (Nanoservices mit 10 Zeilen) bis zu mehreren Tausend Zeilen. Ich persönlich stelle mir schon etwas größeres darunter vor.
unabhängiges Arbeiten einzelner Teams
größere Verantwortung bei jedem einzelnen Entwickler und dadurch auch höhere Identifikation und Motivation
eigenständige Releasezyklen für jeden Microservice
bei Monolithen müssen zum Releasezeitpunkt ALLE Teile einen zumindest akzeptablen Qualitätsstand haben ... das erhöht die Anforderungen an Planung. Teilweise müssen fast fertige Komponenten wieder zurückgebaut werden, weil sie eben nur FAST FERTIG sind. Continuous Delivery ist damit sehr schwierig. Letztlich führt es zu einem längeren Time-to-Market.
könnten Feature-Branches das Dilemma lösen?
jeder Microservice kann einen eigenen Technologiestack wählen ... und wenn es nur unterschiedliche Versionen einer Library/Framework ist
weniger Abstimmung notwendig
es gibt dann nicht mehr DEN einen Architekten, sondern viele ... und das ist aus meiner Sicht eine sehr gute Idee, denn JEDER sollte ARCHITEKT sein
Nutzung neuer Technologien leichter möglich - es kann auch mal eine neue Technologie ausprobiert werden, die dann aber tatsächlich bis zur Produktionsreife (so daß man auch tatsächlich richtige Probleme lösen muß)
dadurch lebt die Architektur und die Software bleibt attraktiv für Entwickler (die nichts mehr hassen als immer wieder dasselbe zu machen)
gezielte horizontale und vertikale Skalierung einzelner Lösungsbestandteile möglich
kleinere Deployments mit kürzeren Startzeiten - hilft auch bei horizontaler Skalierung und zur Reduktion von Ausfallzeiten
Mikoservices bieten einen Migrationspfad, um Features in gewachsenen/alten Monolithen durch Neuimplementierungen zu ersetzen.
Spielt die freie Wahl das Technologiestacks tatsächlich eine Rolle? Wird ein Unternehmen einen Zoo von Technologien zulassen?
Bei großen Unternehmen kommt es evtl. wirklich vor, daß ganz unterschiedliche Programmiersprachen und Frameworks eingesetzt werden. Insofern ist das für solche Unternehmen sicherlich ein Gewinn.
Spielt das für kleine Unternehmen eine Rolle? Solche Unternehmen werden vermutlich gar nicht eine solche Breite an Technologien abdecken (können/wollen). Für solche Firmen liegt der Mehrwert in der Flexibilität und der Attraktivität als Arbeitgeber.
die gewonnenen Freiheiten bedeuten auch mehr Verantwortung
häufig ist das Team, das einen Microservice betreut/entwickelt, so klein, daß die Entwickler auch das Deployment und den Betrieb machen (inkl. Support) ... das muß man auch erst einmal wollen
in Microservice-Architekturen erhöht sich die Anzahl an Schnittstellen ... und Schnittstellen sind immer teuer/schwierig (Abstimmungsaufwand, Testen)
Monitoring und Deployment vieler Komponenten
Logging
Healthchecks ... die evtl. auch in die Loadbalancer und die Anwendnung (Resilience) integriert sind
Deployment der Gesamtlösung ist aufwendiger, weil nun nicht mehr nur EIN Deployment existiert, sondern VIELE
Debugging schwieriger
Administration der Infrastruktur aufwendiger (viele Rechner beteiligt, Firewall, ...)
Latenz
Redundanz von Daten vs. Performance
insbes. bei Benutzer-Identität und den daran hängenden Authorisierungen ... Ansätze wie OAuth, SAML und XACML könnten Lösungen sein
Caching wird ein zentraler Aspekt der Architektur
um den Durchsatz zu erhöhen (Skalierbarkeit ist ja häufig ein Grund für Microservices) wird man verteilte Transaktionen mit Two-Phase-Commit vermeiden wollen. Evtl. muß man sich von strikten Konsistenzgraden - wie wir sie aus relationalen Datenbanken kennen - verabschieden und pragmatischere Wege beschreiten (sofern möglich)
Fehler in der Netzwerkkommunikation
geringerer Abstimmungsaufwand beim Bau der Lösung bedeutet auch geringer Anteil an Management - wieviele Manager werden dann noch benötigt?
... für die Umsetzung von Microservices:
Docker
Service Discovery (Consul, Heureka, ...)
Spring Boot, Spring Cloud ...
ELK (Elasticsearch + Logstash + Kibana)
Resilience (Hystrix, ...)
Ein paar Stichworte:
jeder Microservice hat
seinen eigenen Build (z. B. Jenkins/Travis Datei im Source-Code)
seine eigene Persistenz (lose Kopplung)
sein eigenes Team
seinen eigenen Technologiestack
klar, als unternehmen muß man auch darauf achten, daß man die Services staffen kann - deshalb wird man hier nicht komplett frei sein
sein eingenes Operations-Team (das sich um alles kümmert ... Technologieauswahl)
sein eigenes Tooling
hier können sich Synergien ergeben, wenn man den Technologiestack ähnlich hält
stateless - nur so erreicht man elastische Lösungen, die skalieren können
Data-caching in jedem Microservice als zentrales Architekturelement. Würde man immer alle Daten aus den Origin-Data-Sources ziehen, dann wäre die Anwendnung zu langsam.
update-Strategy notwendig
Für jeden Client-Typ wird eine eigene API bereitgestellt, da ein mobiler Client sicher weniger/andere Daten benötigt als eine Desktop-Anwendung. Und hinsichtlich Desktop-Anwendungen gibt es auch noch mal unterschieden zwischen verschiedenen Usergruppen (Poweruser brauchen eine andere UI als Gelegenheitsnutzer). In diesem Zusammenhang wird der Ansatz Backend-for-Frontend gerne genannt.
Netflix ist zu einem großen Player in Sachen vieler relevanter Cloud-Eigenschaften (Elastizität, Resilience, Performance, ...) geworden. Viele Patterns und Implementierungen sind in OpenSource-Libraries geflossen und haben auch den Weg nach Spring gefunden. Dadurch sind sie wirklich sehr einfach und schnell integriert ... ein paar Annotation und schwupp funktionieren die eigenen Services à la Netflix.