Kleine Services für schnelle Ergebnisse

Microservices – Neue Geheimwaffe oder SOA-Remake?

| Autor / Redakteur: Georg Lauer * / Stephan Augsten

Mit Microservices werden Anwendungen in möglichst kleine, selbständige Dienste aufgesplittet, was eine höhere Flexibilität ermöglicht.
Mit Microservices werden Anwendungen in möglichst kleine, selbständige Dienste aufgesplittet, was eine höhere Flexibilität ermöglicht. (Bild: bavarian_web_solutions - Pixabay.com / CC0)

Microservices – der Programmieransatz wird als Geheimwaffe gehandelt, die Software schneller und flexibler macht. Kleine Codeblöcke – Microservices – statt komplexer Anwendungssilos klingt gut. Doch wie? Und … hatten wir das nicht schon mal?

Es ist das Leid vieler Software-Entwickler rund um den Globus: Monatelang tüfteln sie Überstunden schiebend an neuen Software-Features, um ein von der Unternehmensführung vorgegebenes, zumeist unrealistisches Datum einzuhalten. Doch zum Release stellt sich dann heraus, dass das Tool nicht mit anderen Systemkomponenten kompatibel ist oder – und das ist meist noch schlimmer – gar nicht mehr gebraucht wird.

Den schwarzen Peter bekommen sie zu allem Überfluss auch noch in die Schuhe geschoben: entweder hätten sie an der Realität vorbei entwickelt, sich zu wenig mit den Kollegen aus den Fachabteilungen abgestimmt oder zu langsam gearbeitet. Immerhin sind die neuen Software-Versionen meistens einigermaßen sicher, da sie ausgiebig und umfangreich getestet wurden. Doch was nützt das, wenn sie nicht genutzt werden? Agil ist was anderes.

Doch es geht auch anders. Das zumindest versprechen Microservices: schnellere und flexiblere Software-Entwicklung. Einige sehr erfolgreiche Unternehmen wie Amazon, Google, Twitter, Netflix und eBay setzen auf Microservices – und auch der deutsche Otto-Versand schwört auf agile Software-Entwicklung mit Microservices. Was also steckt dahinter?

Die meinst recht kleinen, unabhängig einsetzbaren Komponenten bilden zusammen eine komplexe Anwendungssoftware, die untereinander Message-basiert mit sprachunabhängigen Programmierschnittstellen kommunizieren. Dabei versuchen die Entwickler, Microservices weitgehend zu entkoppeln und auf nur jeweils eine Funktion zu beschränken. Eine entsprechende Architektur besteht aus weiterentwickelbaren Software-Systemen, die sich in nach ihrer Funktion angeordneten Microservices gliedern lässt und hoch automatisiert ist.

Kurz die wichtigsten Charakteristika von Microservices:

  • klein
  • Messaging-fähig
  • begrenzt auf einen Context
  • autonom entwickelt
  • unabhängig einsetzbar
  • dezentralisiert erstellt, getestet und freigegeben mit automatischen Prozessen

Gemeinsamkeiten und Unterschiede zu SOA

Diese Eigenschaften werden den ein oder anderen an SOA (Service-orientierte Architektur) erinnern – und das zu Recht. Der Grundgedanke und das Konstrukt sind im Wesentlichen die gleichen. Beides sind dienstorientierte Architekturen. Alter Wein in neuen Schläuchen also? Nicht ganz.

In einer Service-orientierten Architektur bieten die Komponenten mit einem Kommunikationsprotokoll anderen Komponenten Dienste über ein Netzwerk an. Sie fungieren also als Anbieter oder Konsument. Ein Enterprise Service Bus (ESB) sorgt für Verbindungen zwischen ihnen.

In einer Microservices Architektur kommunizieren kleine, unabhängige Prozesse über eine Sprach-unabhängige APIs miteinander. Diese Unabhängigkeit macht den wesentlichen Unterschied.

Beiden Ansätzen ist gemein, dass sie dezentral, stark serviceorientiert und zielgerichtet sind. So lassen sich neue Dienste sehr schnell umsetzen. Microservices sind kein Selbstzweck, sondern sind an einem klaren Ziel – einem bestimmten Dienst – ausgerichtet.

Dieser Service stellt sich nach außen über ein Interface dar, das seine Features und Daten zugreifbar macht. Es bietet sich also an, APIs zu standardisieren, etwa als http, oder sich auf eine Interface-Description-Sprache (Swagger, WADL, Blueprint, RAML, etc.) festzulegen.

Kleine Lösungen für große Probleme

Doch zurück zum entscheidenden Vorteil von Microservices: Da sie extrem klein und leicht veränderbar sind, verleihen sie Programmierern eine geradezu magische Gabe: Agilität. Programm-Code kann extrem schnell geschrieben, viele Technologien, Sprachen und Frameworks unterstützt werden.

Unternehmen, die auf Microservices setzen, werden innovativer, weil Neues schneller umgesetzt werden kann und nicht Monate vergehen, bis neue Software-Versionen fertig sind. Wenn ein Service einmal veraltet ist oder auf bestimme Veränderungen nicht adäquat reagieren kann, können einzelne Komponenten wie bei einer Puzzle-Kette entnommen, verändert oder umgeschrieben werden.

Alternativ schreibt man gleich einen neuen Service. Denn das ist ein weiterer elementarer Kerngedanke: entsprechend der Unix-Philosophie „Do One Thing and Do It Well“ lieber einen Service neu schreiben und ihn so auf aktuellsten Stand zu haben, als Altes zu verbessern.

Damit können auch die klassischen Probleme monolithischer – also großer und alter – Systeme gelöst werden. Viele Systeme sind über die Jahre weit über das hinausgewachsen, wofür sie ursprünglich konzipiert wurden. Und genau aus diesem Umfang erwachsen nun die Schwierigkeiten. Der Funktionsumfang ist zu groß, die operationelle Größenordnung und die Change-Frequenz passen nicht mehr.

Die Idee hinter Microservices ist, diese Monolithen durch eine Serie kleiner Code-Elemente zu ersetzen, die extrem dynamisch agieren können. Und damit steigt auch die Sicherheit, denn diese monolithischen Code-Blöcke waren letztlich nicht mehr überschaubar und damit besonders anfällig für Angriffe.

Trotz Hürden zur Balance

Allerdings: Microservices sind mehr als ein technologisches Architektur-Modell, sondern auch Sinnbild einer eigenen Kultur, die nicht jedermanns Sache ist. Der Ansatz kann nicht auf jeden Kontext und jede Umgebung bzw. Anforderungen eingehen. Auch gelten Verwaltung, Koordination und Kontrolle eines Microservices-Systems als sehr aufwändig. Und Dezentralisierung heißt letztlich auch, dass der Großteil der Arbeit im System nicht länger zentral gemanagt und kontrolliert wird.

Die Autonomie der Programmier-Teams macht die Veränderungen an der Software einfacher und schneller, setzt aber Vertrauen, gemeinsame Werte und Überzeugungen voraus. Dazu zählen eine offene Kommunikation, eine strikte Ausrichtung an einem gemeinsamen Ziel und das Zulassen von Innovationen und Veränderungen. Wenn diese Unternehmenskultur noch nicht gelebt wird, werden sich Entwickler-Teams mit Microservices schwer tun.

Tatsächlich steigen auch die Kosten für die Kontrolle und das Management des Outputs erheblich. In einer Microservice-Architektur werden die Services einfacher, aber die Architektur komplexer – eine Komplexität, die mit Tools, Automatisierung und Prozessen in den Griff zu bekommen ist. Es gilt also, die höheren Kosten für Kontrolle gegen den Vorteil schnellerer Änderungen abzuwägen – und dann seine Entscheidung für oder gegen den Ansatz zu treffen.

Georg Lauer
Georg Lauer (Bild: CA Technologies)

Der eigentliche Wert aber auch die Herausforderung der Microservices liegt in der Balance zwischen Geschwindigkeit und Sicherheit. Geschwindigkeit ist die Möglichkeit der schnellen Veränderung und Anpassbarkeit. Es ist die Abkehr von den Major Releases, die in größeren Abständen heraus gegeben werden. Dass dabei Sicherheit immer eine große Rolle spielen muss, versteht sich von selbst - diese muss aber von Anfang an ins System eingebaut werden.

* Georg Lauer ist als Senior Principal Business Technology Architect bei CA Technologies tätig.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45015953 / Microservices)