Praxiserfahrungen beim Umstieg auf Microservices

Viele Unternehmen stehen vor der Entscheidung, ob sie an ihren monolithischen IT-Systemen festhalten oder auf Microservices umstellen. Natürlich ist die Modernisierung einer Software keine einfache Entscheidung, dennoch ist es für die meisten US-amerikanischen und europäischen IT-Entscheider der einzige Weg, um auch in Zukunft wettbewerbsfähig zu sein. Das ergab eine Studie, in der über 70 Prozent der Befragten angaben, bis zum Frühjahr 2018 Microservices einsetzen zu wollen.

Auch wir, als ein Unternehmen im Bereich Enterprise Architecture Management (EAM), müssen uns dem Lebenszyklus von Applikationen stellen. So haben wir, nach nur vier Jahren, die komplette Erneuerung der eigenen, zunächst monolithisch entstandenen Lösung, eingeleitet.

Monolithische Architekturen sind limitiert

Seit der Gründung in 2012 hat unser Produkt stark an Traktion gewonnen und wir konnten unseren Kundenstamm um ein Vielfaches ausbauen. Gestartet als ein sogenanntes "Minimal Viable Product" (MVP) lag der Fokus zunächst darauf, Probleme des Kunden zu lösen und die Markttauglichkeit zu beweisen. Später ergaben sich zahlreiche neue Anforderungen, wie beispielsweise Single-Sign-On-Authentifizierung, die Einführung neuer Workflows und die Flexibilisierung des Datenmodells. Der technische Unterbau muss dabei der konstanten Weiterentwicklung standhalten.

Unsere bestehende Plattform war auf einem klassischen LAMP-Stack aufgebaut, sprich Linux, Apache, MySQL und PHP, in einer gemeinsamen Codebasis. Eine Hürde für das Wachstum war, dass die zunehmende Anzahl an Entwicklern nicht länger an einer gemeinsamen Code-Basis arbeiten konnten und die Koordination von Tests und das Releasen einer Version aufwändiger wurden. Dies hatte vor allem den Verlust an Geschwindigkeit für neue Features und Innovation zur Folge. Dazu kamen technische Risiken, da die eingesetzten Software-Versionen aus dem regulären Support liefen, d.h. es waren nicht mehr für alle Komponenten Sicherheitsupdates verfügbar.

Als eine Antwort wurde eine Zerteilung der bestehenden Funktionalität in Microservices evaluiert und entschieden. Auch wenn es im Ansatz Gemeinsamkeiten zu einer Service Oriented Architecture (SOA) aufweist, gibt es gravierende Unterschiede.

Warum die Motive eines Startups repräsentativ für etablierte Unternehmen sind

Die Gründe eines Startups, sich für Microservices zu entscheiden, sind auch auf vielfach größere Unternehmen übertragbar. Häufig startet eine IT-Applikation mit kleinem Funktionsumfang im Rahmen eines Projekts und beginnt dann, mit zahlreichen Anforderungen zu wachsen. Es entsteht schnell ein Monolith, der eine erfolgreiche Marktdurchdringung und Skalierung des dahinterstehenden Teams verhindert. Um dem entgegenzuwirken, mussten wir bestimmte organisatorische, prozessuale und technische Voraussetzungen schaffen:

1. Agile Entwicklung

Hierfür haben wir zunächst das gesamte Team mittels erfahrener Trainer nach Scrum trainiert und mehr als zwölf Monate Erfahrung in der Zusammenarbeit mit den bestehenden Applikationen gesammelt. Dennoch durften wir uns nicht nur auf das Erlernen der agilen Prozesse beschränken, sondern wir mussten auch Fachwissen über die bestehende Anwendung erlangen.

Das Team arbeitet dabei nach dem sogenannten GitFlow-Prinzip, d.h. die Teams entwickeln neue Funktionalitäten in getrennten Feature-Branches. Mittels vier-Augen-Prinzip werden die Änderungen dann in den Haupt-Entwicklungsstrang überführt. Von diesem werden neue Releases der Software erstellt. Der Code wird hier mittels sogenannten Pull-Requests übernommen. Dadurch wird das Pair Programming zwischen den Entwicklern gefördert und das Wissen im Team geteilt.

2. API-First

Jeder neu entwickelte Service hat eine REST-API (REpresentational State Transfer; Application Programming Interface), die mittels sogenannter Swagger-Definition dokumentiert ist. Swagger ist eine Beschreibungssprache für APIs, aus der sich sowohl eine Dokumentation als auch ein SDK automatisch generieren lassen. Der Vorteil der generierten Dokumentation für Entwickler liegt darin, dass die Dokumentation interaktiv ist. Somit lässt sich die API direkt im Browser mit geeigneten Zugangsdaten aufrufen. Das spart Entwicklungszeit und erlaubt Rapid Prototyping. SDKs lassen sich dank Swagger in allen verfügbaren Programmiersprachen generieren, was die Nutzung der APIs aus anderen Services und durch Kunden erleichtert.

3. Containerisierung

Auf den Servern sind die Services nicht mehr im klassischen Sinne installiert, sondern in einer standardisierten Laufzeitumgebung von Docker als sogenanntem Container ausgeführt. Da wir schon seit mehr als zweieinhalb Jahren Docker produktiv nutzen, hatten wir dafür schon eine eigene Orchestrierungslösung entwickelt, die es ermöglicht, neue Software-Releases in Betrieb zu nehmen, ohne dass eine Downtime nötig ist. So bleibt die Bereitstellung neuer Releases für die Nutzer unbemerkt.

Dies wird durch ein sogenanntes Green-Blue-Deployment ermöglicht: Bei einem neuen Release werden Container in der neuen Version bereitgestellt, die dann parallel zu der alten Version laufen. Sobald die neue Version hochgefahren ist, werden die Nutzer auf die neue Version geleitet.

4. Automatisierung

Wir haben von der Entwicklung, über Tests bis hin zum Deployment eine stark automatisierte Toolchain aufgebaut. Zentral dabei ist die Nutzung von Continuous Integration (CI) & Deployment (CD) Servern, und der domänenspezifischen Sprache Ansible, mit der Infrastrukturaufgaben automatisiert werden.

Entwicklungsrechner und ServerServer können gleichermaßen mittels Ansible automatisiert eingerichtet, d.h. provisioniert werden. Auch unsere Applikation wird mittels Ansible deployed. Die CI/CD Server erstellen neue Versionen der Software, sobald Änderungen im zentralen Source Code Repository GitHub verfügbar sind. Alles zu Server auf CIO.de

Anschließend werden die neuen Versionen automatisch auf den Testsystemen aktiviert und sogenannte End-2-End-Tests gestartet. Bei diesen Tests sind Anwendungsfälle so automatisiert, als würden sie im Browser ausgeführt. Dadurch konnten wir möglichst realitätsnah die Anwendung aus Nutzersicht testen.

5. Zentraler Event-Hub

Um zahlreiche Punkt-zu-Punkt-Verbindungen zwischen den Services zu vermeiden, haben wir eine Publish-and-Subscribe-Architektur etabliert. Dabei produzieren die jeweiligen Services Events, die an einen zentralen Event-Hub verteilt werden. An dem Event-Hub können sich nicht nur die internen Dienste abonnieren, sondern auch Kunden sich extern dieser Events mittels Webhooks bedienen.

Wie ist die Transformation in unserem Unternehmen vorangegangen?

Vom Start der Entwicklung neuer Services bis zum Abschluss der Transformation, sind insgesamt 36 Monate vergangen. In den ersten 18 Monaten haben wir neue Funktionalitäten, wie beispielsweise Survey-Workflows, mittels neuer Services implementiert und neben dem bestehenden Kern betrieben. Aus der monolithischen Kernanwendung wurden zunehmend Funktionalitäten wie Benutzermanagement, Export zu Grafiken oder Bereitstellung von Bildern herausgeschnitten. Dadurch konnten wir den Kern schrittweise auf die wesentliche Funktionalität reduzieren.

In weiteren zwölf Monaten wurden die zentralen Funktionalitäten in der neuen Microservice-Architektur neu implementiert. Dabei fand nicht nur eine Eins-zu-eins-Migration der bestehenden Funktionalitäten statt, sondern zentrale Anforderungen, z.B. ein flexibles Datenmodell, wurden umgesetzt.

In den letzten sechs Monaten fand dann schrittweise die Migration bestehender Kunden statt. Dabei wurden über 80 Kunden von der alten auf die neue Plattform migriert. Gleichzeitig sind neue Kunden bereits auf der neuen Plattform live gegangen. Mittlerweile laufen über 100 Kunden weltweit mit mehreren tausend Nutzern auf der neuen Plattform "Pathfinder".

Die Erfolgsfaktoren während der Umstellung

Bei der Einarbeitung in die neue Architektur und Technologie war entscheidend, dass diese anhand von neuen Kundenanforderungen stattfand, die nicht die höchste Kritikalität besaßen. Dadurch hat das Team schnell belastbare Erfahrung gesammelt, indem die ersten Services bereits auf der Ziel-Technologie implementiert wurden. Wichtig war, dass wir die Services schrittweise umgestellt haben. Über 30 Monate hinweg wurden alte und neue Services dank Containerisierung mit Docker parallel betrieben.

Auch die Automatisierung der Datenmigration vom Alt- ins Neusystem spielte eine wichtige Rolle. Zu jedem Zeitpunkt der Entwicklung der neuen Hauptanwendung, wurde auch immer parallel die Migration der Daten automatisiert. So konnten die gesamten Arbeitsbereiche der Kunden in der alten Version immer parallel mit der neuen Version getestet werden, ohne dass die bestehende Lösung im Produktivbetrieb für Nutzer gestört wurde.

Natürlich bedarf es auch einer engen Abstimmung mit den Kunden und zwischen den internen Teams. Während unser Engineering-Team die Entwicklung der Anwendung vorangetrieben hat, hat das Customer-Success-Team die Kommunikation und Planung mit den Kunden umgesetzt.

Scrum und Kanban

Durch diese eng abgestimmte Arbeitsweise konnten wir sicherstellen, dass bestmöglich auf die Kundenwünsche eingegangen werden kann und die Migrationen möglichst dann stattfanden, wenn alle benötigten Features, die ein Kunde nutzt, auch vorhanden waren. Bis zur sechsmonatigen Migration hat das Engineering-Team in zweiwöchentlichen Scrum-Sprints gearbeitet. Während der Migration wurde die Methodik auf Kanban umgestellt. Dies hatte den Vorteil, dass besser auf unvorhergesehene Probleme reagiert werden konnte.

Für Kunden bedeutete die Umstellung auf die neue Software immer, dass Nutzer mit den Änderungen vertraut gemacht werden müssen und ein Training stattfinden muss. Für unsere Transformation haben wir die Entscheidung getroffen, die Modernisierung des User Interface zu entkoppeln: Es wurde zwar auf eine sehr moderne Single-Page-App umgestellt, die vollständig im Browser läuft, allerdings ist das User Interface in weiten Teilen nah an der vorherigen Version geblieben. Dadurch profitieren die Nutzer von schnelleren Ladezeiten, es ist aber keine komplette Neuschulung notwendig gewesen.

Was waren die Kernherausforderungen?

1. "Transform while Perform": Dank des schnell wachsenden Kundenstamms mussten neue Kunden und bestehende Kunden ausbalanciert werden. Die erhöhten Anforderungen, hauptsächlich die Performance betreffend, haben zu einer Erweiterung des ursprünglich geplanten Funktionsumfangs geführt. Dies hatte zur Folge, dass einzelnen Kunden Randfunktionen der alten Version zeitweilig nicht zur Verfügung standen.

2. Umgang mit der Migration von Daten: Bei einer Anwendung, die bereits mehr als fünf Jahre von Kunden genutzt wird und Daten produziert, entstehen zahlreiche Konstellationen, die nur sehr aufwändig durch Testdaten reproduzierbar sind. Die automatisierte Datenmigration war hier bereits eine entscheidende Basis. Allerdings wurde der Gesamtaufwand erst während des Prozesses ersichtlich.

3. Umstellung des Paradigmas: Die ursprüngliche Architektur war dadurch geprägt, dass jede Anfrage über den Browser in einem separaten Request abgearbeitet wurde, typisch für viele Web-Anwendungen auf der Basis von Scriptsprachen wie PHP. Mit dem Wechsel auf Java hat sich das ausführende Modell geändert. Dadurch laufen Anfragen gegen einen ständig laufenden Prozess. Hierdurch steigt die Gefahr für Engpässe im Speicher und das Risiko, dass einzelne Requests die gesamte Anwendung lahmlegen.

Wie geht die Reise weiter?

Seit Ende 2017 ist die Migration aller Kunden abgeschlossen. Dank der flexiblen Architektur konnten bereits weitere Features für Kunden umgesetzt und die Performance verbessert werden. Eine wesentliche organisatorische Herausforderung besteht in der Optimierung des Release- und Deployment-Prozesses. In der Theorie ist aufgrund gekapselter Services und stabiler APIs kaum Koordination zwischen den verschiedenen Teams notwendig.

In der Realität zeigt sich, dass funktionale Erweiterungen mehrere Services der Architektur betreffen. Hier ist ein Ziel von uns, den Schnitt der Services weiter zu verbessern, um eine möglichst hohe Unabhängigkeit der Teams voneinander zu gewährleisten. Ein zentraler Bottleneck hierbei ist häufig eine Single-Page-App, die auf verschiedene Services zugreift und damit fast immer bei fachlichen Erweiterungen betroffen ist.

Daneben steht die Erhöhung von SLAs an, da zunehmend kritische Use Cases auf unserer Plattform umgesetzt werden. Auf der Basis der neuen Architektur ist unser Unternehmen für das Wachstum bestmöglich aufgestellt, um sich weltweit als führende Lösung für das Management von IT-Architekturen zu etablieren.