olly - Fotolia

Microservices verändern die Organisation und fördern Innovationen in Unternehmen

Microservice helfen Firmen, Innovation voranzutreiben. Die einzelnen Services sind weniger komplex und erlauben es Entwicklern, agiler zu agieren.

Die Digitalisierung erfordert es von Unternehmen, agil zu agieren. Es besteht sonst die Gefahr, hinter Start-ups zurückzubleiben, die mit flexiblen Strukturen den Anforderungen der digitalen Transformation rasch nachkommen können.

Dass Nachholbedarf herrscht, zeigt eine Studie von Capgemini. Laut der Studie ist der Anteil der deutschen Unternehmen, die Probleme mit der Digitalisierung haben, von 41 Prozent im Jahr 2015 auf 60 Prozent im letzten Jahr gestiegen. Im aktuellen Jahr haben sogar 73 Prozent der CIOs Schwierigkeiten damit (Zusammenfassung der Cagemini-Studie als PDF).

Gründe dafür sind neben mangelnder Erfahrung vor allem unflexible Geschäftsprozesse und starre, veraltete IT-Strukturen. Eine Möglichkeit, um Innovationen schneller vorantreiben zu können und Software skalierbar zu machen, sind Microservices.

Was steckt hinter Microservices?

Bei Microservices handelt es sich um einen Softwarearchitektur- und Organisationsansatz für agile Deployments: Innovationen können schneller vorangetrieben werden, Software lässt sich besser skalieren und warten.

Microservice-Architekturen zeichnen sich dadurch aus, dass die einzelnen Bestandteile einer Software in kleine, unabhängige Services aufgeteilt sind. Diese Services kommunizieren über Programmierschnittstellen (Application Programming Interfaces, APIs) miteinander. Die einzelnen Microservices werden jeweils von kleinen Entwicklungsteams betreut. Das bringt Vorteile mit sich.

Microservices ist ein Sammelbegriff für diese Dienste – so gibt es keine klare Definition, allerdings teilen sich Microservice-Architekturen einige Gemeinsamkeiten:

  • „Do one thing well“: Jede Komponente einer Microservice-Architektur fokussiert sich auf eine spezifische Domäne. Falls im Laufe der Zeit zusätzliche Komplexität hinzukommt, sind diese Funktionen eventuell Kandidaten für einen eigenen Microservice.
  • Dezentralisiert: Microservice-Architekturen sind verteilte Systeme mit zentralisiertem Daten-Management. Jeder Microservice hat die Hoheit über die Daten einer Domäne. Die einzelnen Services sind so dezentralisiert, dass sie unabhängig voneinander entwickelt, ausgerollt und betrieben werden können.
  • Unabhängig: Verschiedene Komponenten einer Microservice-Architektur können unabhängig voneinander geändert, aktualisiert und ausgetauscht werden, ohne dass dadurch die Funktionalität anderer Komponenten beeinflusst wird. Das gleiche gilt für die Teams, die für die einzelnen Komponenten einer Microservice-Architektur verantwortlich sind. So können diese unabhängig voneinander arbeiten.
  • Polyglott: Microservice-Architekturen folgen keinem „one size fits all”-Ansatz. Teams haben die Freiheit, die beste Plattform für spezifische Problemstellungen zu wählen. Die Konsequenz: Microservice-Architekturen sind in der Regel heterogen im Hinblick auf das genutzte Betriebssystem, Programmiersprachen, Datenbanken und Tooling.
  • Black Box: Einzelne Komponenten sind als sogenannte „Black Boxes“ entworfen. Das heißt, die Komplexität der Implementierung bleibt anderen Komponenten verborgen. Jede Kommunikation erfolgt über die APIs. Die Nutzung von geteilten Komponenten, wie zum Beispiel Bibliotheken oder gemeinsamen Datentöpfen, beeinträchtigt die Unabhängigkeit einzelner Services.
  • „You build it, you run it”: Typischerweise ist das Team, das für die Implementierung eines Services verantwortlich ist, auch für dessen Betrieb zuständig – ganz nach dem DevOps–Prinzip. Die Teams können unabhängig voneinander entwickeln, Entwickler in engen Kontakt mit den eigentlichen Nutzern ihrer Software treten. Das hilft, die Anforderungen von Kunden besser zu verstehen.

Microservices verändern die Organisation

Aufgrund ihrer dezentralen Struktur begünstigen Microservices eine Organisationsform, in der kleine unabhängige Teams die Hoheit über ihre Services haben. Die Nutzung von Microservices als Entwurfsmuster hat – nach Conway’s Law – zwangsläufig Änderungen in der Organisation zur Folge. Conway’s Gesetz besagt, dass „Organisationen, die Systeme entwerfen, […] auf Entwürfe festgelegt sind, welche die Kommunikationsstrukturen dieser Organisationen abbilden“.

Die einzelnen Teams arbeiten unabhängig voneinander. Das erhöht die Geschwindigkeit bei der Entwicklung von Software und beim Deployment. Die Codebasis, an denen die einzelnen Teams arbeiten, ist kleiner, darüber hinaus gibt es weniger Abhängigkeiten im Quellcode. Der Effekt: Codekonflikte werden reduziert, Testzyklen verkürzt und die Auslieferungszeit von neuen Features und Services wird minimiert.

„Aufgrund ihrer dezentralen Struktur begünstigen Microservices eine Organisationsform, in der kleine unabhängige Teams die Hoheit über ihre Services haben.“

Matthias Jung, AWS Germany

Auch das Feedback von Kundenseite kann schneller in kommende Releases integriert werden, da alle Teams an ihren individuellen Baustellen arbeiten. Da die kleinen Teams autonom agieren und Technologien, Frameworks und Tools auswählen können, die am besten für die entsprechende Problemdomäne geeignet sind, lassen sich Innovationen agiler vorantreiben.

Da Teams die Kompetenzen sowohl zum Entwickeln als auch zum Betreiben einer Applikation haben, werden mögliche Reibungen und sich widersprechende Ziele vermieden. Die Automatisierung der Entwicklungsprozesse wird nicht länger unterbrochen, wenn es zum Deployment kommt, sondern auf den gesamten Lebenszyklus einer Software ausgeweitet – vom initialen Code-Commit bis zum Release.

Auf diese Weise können neue Ideen einfach als neue Features ausgerollt und bei Bedarf wieder entfernt werden. Die Kosten dafür halten sich in Grenzen. Das begünstigt eine Kultur des Wandels und der Innovation, da Fehler keine weitreichenden Auswirkungen haben. Diese Faktoren tragen wiederum dazu bei, die Qualität des Quellcodes zu erhöhen.

Granulare Entkopplung ist eine der Best Practices, um hochskalierbare Systeme zu bauen und eine Voraussetzung für Performance-Optimierung. Der Grund: Sie erlaubt es, Services individuell zu betrachten und die optimale Technologie für den jeweiligen Service zu nutzen. Dadurch ist es möglich, dass jeder Service mit der für ihn sinnvollen Sammlung von Sprachen und Frameworks implementiert wird, um in Kombination mit dem optimalen Datenspeicher die beste Performance zu erreichen. Sinnvoll entkoppelte Services können horizontal und unabhängig voneinander skaliert werden.

Vertikale Skalierung – also die Ausführung derselben Software auf leistungsfähigeren Servern – ist durch die Kapazität der einzelnen Server begrenzt und kann zudem zu Ausfallzeiten bei der Skalierung führen.

„Die Codebasis, an denen die einzelnen Teams arbeiten, ist kleiner, darüber hinaus gibt es weniger Abhängigkeiten im Quellcode.“

Sascha Möllering, AWS Germany

Horizontale Skalierung ist hier der bessere Ansatz. Dabei ist es möglich, auf einfache Weise weitere Server dem Pool an Ressourcen hinzuzufügen. Dieser Prozess kann darüber hinaus auch automatisiert werden. Die Robustheit der Applikation steigt durch diese Maßnahme ebenfalls, denn Komponenten können einfach und automatisch ersetzt werden.

Mit Microservice-Architekturen ist es einfacher, Ausfälle einzelner Komponenten zu isolieren: Design-Patterns wie zum Beispiel Health-Checks, Caching, Bulkheads oder Circuit-Breaker erlauben es, Fehler lokal zu begrenzen und verhindern Kaskadeneffekte mit Auswirkungen auf den kompletten Quellcode.

Microservice-Architekturen helfen Unternehmen, eine Kultur von Innovation und Wandel voranzutreiben. Die einzelnen Services sind in ihrer Gesamtheit weniger komplex und ermöglichen es Entwicklungsteams, agiler zu agieren. Zudem können die Teams eine Fehlerkultur leben, bei der es möglich ist, Neues auszuprobieren, ohne dass einzelne Probleme im Code gleich einen ganzen Geschäftsprozess lahmlegen.

Über die Autoren:
Matthias Jung ist Solutions Architect bei Amazon Web Services Germany und hat bereits viele deutsche Start-ups auf ihrem Weg in die Cloud unterstützt. Bevor er zu AWS kam, gründete er selbst ein Start-up im Cloud-Security-Bereich.

Sascha Möllering arbeitet als Solutions Architect bei Amazon Web Services Germany. Seine Interessen liegen in den Bereichen Automation, Infrastructure as Code, Distributed Computing, Container und JVM.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im März 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Software-Entwicklung

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close