1    Einführung

In diesem Kapitel werden Sie Microservices und die Programmiersprache Go kennenlernen. Neben den Vorzügen von Go werden Sie erfahren, warum es vorteilhaft ist, Go für Ihre Microservice-Implementierungen zu verwenden.

1.1    Was sind Microservices?

Über lange Zeit wurden Enterprise-Anwendungen in Form von großen zusammenhängenden Einheiten entworfen und umgesetzt. Dieser Ansatz wird als monolithischer Architekturstil bezeichnet. Hier werden sämtliche Geschäftsfunktionalitäten in einer Einheit ausgeliefert und zur Laufzeit innerhalb eines (Betriebssystem-) Prozesses ausgeführt.

Die interne Strukturierung einer solchen Anwendung findet über Mittel der eingesetzten Programmiersprache in Form von Aufteilung in Klassen, Funktionen oder Namensräume statt.

Mit diesem Ansatz wurden und werden viele erfolgreiche Produkte bzw. Projekte umgesetzt. Allerdings nehmen mit zunehmender Größe und Projektlaufzeit der Anwendung auch oftmals die Probleme und damit Frustration über die Anwendung bei Anwendern, Fachabteilungen und Entwicklern zu.

1.1.1    Probleme bei monolithischen Architekturen

Zu den größten Problemen zählen die folgenden:

Neue Features einzubauen ist komplex und fehleranfällig

Die Umsetzung eines Features erfordert immer eine Änderung in der Komplettanwendung. Dies bedeutet, dass vor einer Auslieferung die gesamte Anwendung komplett getestet werden muss. Nebeneffekte können nie ausgeschlossen werden, und eine kleine Änderung z. B. an den Timeout-Einstellungen für den Transaktionsmanager, die in einem Anwendungsteil benötigt wird, kann unter Umständen an einer ganz anderen Stelle in der Anwendung zu massiven Problemen führen. Oftmals sind Abhängigkeiten in der Anwendung nicht völlig transparent und machen Änderungen fehleranfällig. Automatisierte Tests können zwar die Problematik entschärfen, aber leider nicht komplett aus der Welt schaffen. In vielen Systemen wird aus diesen Gründen angebaut und nicht angepasst, und dies führt wiederum zu komplexeren Systemen, die den Einbau von Features noch weiter erschweren.

Weiterentwicklung der Architektur ist schwierig

Monolithische Anwendungen sind oftmals über Jahre gewachsen, und die Architektur der Anwendung wurde zu Beginn festgelegt. Aus der schlanken Neuentwicklung wurde mit der Zeit eine schwerfällige Legacy-Anwendung. Die zu Beginn getroffenen Architektur- oder Technologieentscheidungen haben sich meist tief in das System eingegraben, und entsprechende Überarbeitungen im Falle einer Revidierung dieser Entscheidungen müssen oftmals an vielen Stellen, auch gleichzeitig, vorgenommen werden. Kluge Architekturentscheidungen wie die strikte Trennung zwischen Technologie und Fachlichkeit oder sinnvolle Abstraktionsschichten erleichtern in den meisten Fällen das Vorgehen, grundlegende Anpassungen bedeuten jedoch immer erheblichen Aufwand und ein gewisses Fehlerrisiko.

Skalierung zur Laufzeit

Eine Skalierung ist bei Monolithen nur für die komplette Anwendung möglich und macht diese unter Umständen sehr komplex, da nicht ausschließlich diejenigen Teilbereiche skaliert werden können, die tatsächlich mehr Ressourcen benötigen. Der technische Aufwand, um z. B. Caches und Synchronisationsmechanismen korrekt umzusetzen und zu testen, darf nicht unterschätzt werden. Skalierung bei Monolithen bedeutet immer, die Anwendung ein weiteres Mal auszuführen und die Last über einen vorgeschalteten Load-Balancer zu verteilen.

Skalierung bei der Entwicklung

Arbeiten mehrere Teams an derselben Codebasis eines Monolithen, muss oftmals viel Abstimmungsaufwand betrieben werden, um die Teams untereinander zu koordinieren. Welches Feature soll oder muss z. B. zu welchem Zeitpunkt ausgeliefert werden? Welche Änderung wirkt sich auf welche anderen Bereiche aus?

Lange Deployments

Monolithische Anwendungen besitzen beim Deployment immer die Komplexität des Gesamtsystems, da auch genau dieses deployt wird. Bei jedem Deployment müssen sämtliche interne Bestandteile sowie externe Abhängigkeiten konfiguriert und gestartet werden. Wird für einen Monolithen z. B. ein IBM WebSphere Application Server eingesetzt, kann der Start der Umgebung gut und gerne 30–60 Minuten dauern. Pro Instanz. Verwaltet die Anwendung zusätzlich einen Status pro Client, der nicht über die Instanzen repliziert wird, muss beim Herunterfahren eventuell gewartet werden, bis sich alle Clients abgemeldet haben bzw. ihre Session ausgelaufen ist.

Lange Build- und Release-Zyklen

Das Erstellen einer monolithischen Anwendung kann sehr viel Zeit in Anspruch nehmen, da sämtliche Codegenerierungsläufe ausgeführt werden müssen und sämtlicher Quellcode zu übersetzen ist. Anschließend müssen die kompletten Unit-Tests der Anwendung durchlaufen werden. Je größer die Codebasis ist, desto länger dauert die Erstellung eines Anwendungsartefakts, das außerdem vor einem Release noch den kompletten Integrations- und Regressionstests mit fachlichen Abnahmen unterzogen werden muss. Alles in allem ein langwieriger und fehleranfälliger Prozess, der oftmals dazu führt, dass weniger Releases durchgeführt und die Release-Zyklen immer länger werden. Eine agile Vorgehensweise lässt sich in einem solchen Umfeld nur schwer umsetzen.

Geringe Innovationskraft

Durch den recht engen und unflexiblen Rahmen bei der Entwicklung eines Monolithen ist es schwer, neue Ideen auszuprobieren und umzusetzen. Wie bereits beschrieben, sind Anpassungen an der Architektur, die für manche neuen Ideen nötig sind, nur sehr schwer umsetzbar. Eine Migration von z. B. einer rein HTML-basierten Anwendung, die ihre Seiten serverseitig generiert, zu einem AJAX/JavaScript-basierten Frontend wird erst dann möglich, wenn die technischen Voraussetzungen zur Umsetzung von REST-Services gegeben sind. Dass keine REST-Service-Unterstützung vorhanden ist, erscheint im ersten Moment vielleicht völlig abwegig, aber bei über Jahre gewachsenen Monolithen ist das Vorhandensein dieser Services nicht selbstverständlich. Eventuell verhindern auch alte Bestandteile der Anwendung ein Update auf eine neue Laufzeitumgebung, welches allerdings für bestimmte Features zwingend notwendig ist.

Herausforderndes Cloud Deployment

Zahlreiche Unternehmen stellen aus den verschiedensten Gründen von selbst betriebenen Rechenzentren mit on-Premise-Lösungen auf in der Cloud gehostete Systeme um. Um das volle Potential einer Cloud-Umgebung nutzen zu können, sind Anpassungen an der Anwendung nötig, die, wie bereits beschrieben, zum Teil nur schwer umsetzbar sind. Es ist auch denkbar, dass hohe Lizenzgebühren einer Laufzeitumgebung Deployment oder Ausführung einen Monolithen in der Cloud verhindern.

Auch die Dateigröße der Anwendung kann bei der Arbeit in einer Cloud-Umgebung von Nachteil sein.

Sicherstellung der internen Anwendungsarchitektur

Je größer die Codebasis ist und je mehr Entwickler an ihr arbeiten, desto schwieriger wird es, die interne Anwendungsarchitektur im Griff zu halten. Auch passen nicht alle Architektur- oder Programmiervorgaben auf alle Problemstellungen, die während der Entwicklung eines Projektes auftreten. Bei Monolithen wird aus diesem Grund oft versucht, »Wildwuchs« über komplexe Architekturüberwachungswerkzeuge oder durch erzwungene Projektstrukturen zu unterdrücken.

Die Einarbeitung neuer Entwickler in die komplette, bestehende und über mehrere Code-Generationen gewachsene Anwendung ist meist aufwändig.

1.1.2    Gemeinsame Eigenschaften von Microservices

Um alle oben beschriebenen Herausforderungen anzugehen, haben viele Projektteams damit begonnen, ihre monolithischen Systeme aufzulösen und durch kleinere Anwendungen zu ersetzen bzw. neue Bestandteile als separate Applikationen zu entwickeln.

James Lewis und Martin Fowler haben im Jahr 2012 versucht, die Gemeinsamkeiten der verschiedenen Ansätze zusammenzutragen und das entstandene Modularisierungskonzept zu beschreiben. In der Folge ist der Begriff Microservices entstanden. Eine einheitliche Definition existiert allerdings nicht. Wenn Sie den Architekturansatz verfolgen möchten, können Sie sich an den nachfolgend beschriebenen Eigenschaften orientieren.

Adrian Cockroft, der bei Netflix maßgeblich bei der Umstellung auf eine Microservice-Architektur beteiligt war, beschreibt den Architekturansatz beispielsweise so:

Service-oriented architecture composed of loosely coupled elements that have bounded contexts – Adrian Cockcroft

Komponenten als separate Services

In der Softwareentwicklung hat Modularisierung und somit die Gliederung eines Systems in kleine, beherrschbare Einheiten schon immer eine sehr große Rolle gespielt. Jede Programmiersprache bietet entsprechende Mechanismen, um einzelne Komponenten oder Module definieren bzw. erstellen zu können.

Für den Begriff...