Kleine Services für schnelle Ergebnisse Microservices – Neue Geheimwaffe oder SOA-Remake?

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?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

CA Deutschland GmbH

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?

Was sich bei der Microservice-Einführung bewährt hat

Microservices – Ein Einstieg in die Praxis

Die meist 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.

Mikrodienste entwerfen und strukturieren

Best Practices zu Microservice-Design, Logik und APIs

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

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.

(ID:45015953)