Vom Softwaremonolithen zu Microservices: Systemumstellung am Praxisbeispiel

Inhaltsverzeichnis

Aus der komplexen und unübersichtlichen Monolith-Software bei Studitemps sollte eine Microservice-Landschaft mit fachlich voneinander abgegrenzten Applikationen entstehen – ein Projekt, das ebenso viele Hürden wie Learnings brachte.

Um die Ausgangslage besser zu verstehen, sei kurz auf die Geschichte von Studitemps hingewiesen: Bei der Gründung 2008 lag das Geschäftsmodell von Studitemps noch auf Stellenanzeigen, die auf der eigenen Studentenjob-Plattform Jobmensa verkauft wurden. Neben dem Online-Portal auf Basis von Ruby on Rails entstand dafür eine Python-basierte Backend-Software, über die sich die Kunden und Anzeigen verwalten ließen. Das System bekam intern den Namen KISS (Kunden-Informations-Super-System).

2011 stellte Studitemps den Fokus des Geschäfts um: Das Unternehmen wuchs zu einem Personaldienstleister für Studenten heran – auf der Basis von Zeitarbeit, was andere Anforderungen an die Softwarelandschaft stellte. Anstatt Anzeigenkunden zu verwalten, waren nun plötzlich Kundenaufträge, Arbeitnehmer, Einsatzplanung, Arbeitsverträge, Rechnungen und Lohnauszahlungen abzubilden. Das KISS wurde mit der Zeit zu einem schnell wachsenden Unternehmens-ERP (kurz für Enterprise Resource Planning). KISS entwickelte sich zu einem unübersichtlichen Softwaremonolithen und wurde zunehmend komplexer zu betreiben, zu warten und weiterzuentwickeln. Weil die Testabdeckung unvollständig blieb, wurde es zunehmend schwieriger, neue Features auszuliefern oder Fehlerfälle nachzustellen und zu beheben.

Ein Nachfolger für KISS musste her. Um das Tagesgeschäft im Unternehmen fortsetzen zu können, sollte der Monolith nicht sukzessiv umgebaut, sondern parallel zum laufenden Betrieb eine Microservice-Struktur geschaffen werden. Das Ziel war eine Neuentwicklung von Anwendungen mit klar definierten Abgrenzungen und die schrittweise Etablierung neuer Anwendungen. Diese Parallelentwicklung machte es möglich, Ideen und neue Vorgehensweisen immer wieder zu überdenken. Auf Abwärtskompatibilitäten im Prozess musste man keine Rücksicht nehmen.

Neuausrichtung der Software zu fachlich abgegrenzten Services

Im Rahmen der Neuentwicklung wurden Prozesse und Funktionen auf verschiedene Anwendungen und Teams aufgeteilt, um zukünftig schneller auf Änderungen reagieren zu können. Das neue System, das aus unterschiedlichen und fachlich klar voneinander abgegrenzten Services besteht, heißt "Studitemps Works". Die verschiedenen Anwendungen und Services werden separat voneinander betrieben und können auf den unterschiedlichen Programmiersprachen und Frameworks basieren – je nach fachlicher und technologischer Problemstellung.

Dieser Schritt weg vom Monolithen hin zu Microservices war der Grundstein für einen Neustart mit aktuellen Softwarekomponenten und eine fundierte technologische Basis. Die klare (fachliche) Abtrennung der Applikationen bedeutet für die Entwickler Arbeitserleichterung: Der Problem- und somit auch Lösungsraum wird dadurch eingegrenzt und ist nicht immer auf ein riesiges System weiterzudenken. Ganz lässt sich KISS aber noch nicht ablösen, vor allem weil es Überschneidungen im Prozessablauf gibt und manche Funktionen in den neuen Anwendungen in überarbeiteter Form implementiert wurden. Für diese Fälle waren Features zu deaktivieren und Austauschmöglichkeiten für Daten zu schaffen. Augenmerk lag hier auf einer einfachen und schnellen Integration im Bestandssystem.

Aus diesem Grund kamen vorwiegend Programmierschnittstellen (APIs) mit JSON oder Dateiexporte- und -importe wie CSV zum Einsatz, die im weiteren Produktlebenszyklus durch eine asynchrone event-basierte Kommunikation abgelöst wurden. Das gelingt, wenn bereits von Beginn an in den Anwendungen ein Fokus auf solch eine Architektur gelegt wird. So kann auch ein legacy CSV-Import lokal die geeigneten Funktionen auslösen, die für die neue Architektur konzipiert wurden. Diese temporäre Integration schlägt die Brücke zwischen alter und neuer Architektur.