Anstatt vorzustellen
Seit dem Start der ersten Microservices sind mehrere Monate vergangen. Und jetzt ist es unserer Meinung nach an der Zeit, über die gesammelten Erfahrungen zu berichten.
Es lohnt sich, sofort zu reservieren, was in diesem Artikel enthalten sein wird und was nicht. Der Artikel beschreibt keine architektonischen Lösungen und Beschreibungen mit den Gründen für diese Entscheidungen. Wir werden uns nicht auf den Technologie-Stack konzentrieren, auf dem wir Microservices erstellt haben.
Das Hauptaugenmerk des Artikels wird auf den globalen Problemen liegen, mit denen unser Team während des gesamten Projekts konfrontiert war.
Dieser Artikel wird der erste von vielen sein. Ihr Ziel ist es zunächst, unsere Probleme im Zusammenhang mit dem Übergang zu einer Microservice-Architektur vorzustellen und reibungslos zu den folgenden Themen zu führen, die bestimmte Aspekte des Übergangs im Detail aufzeigen.
Wie alles begann
Die Entscheidung, auf eine Microservice-Architektur umzusteigen, wurde vor ungefähr anderthalb Jahren getroffen. Unsere Herausforderung bestand darin, uns auf das schnelle Wachstum unseres Unternehmens vorzubereiten. Wir mussten flexibler in Bezug auf technische Lösungen werden, die Geschwindigkeit von Änderungen erhöhen und natürlich die Ausfallsicherheit unserer Systeme erhöhen.
Nachdem die Entscheidung getroffen wurde, auf eine Microservice-Architektur umzusteigen, wurde eine separate Einheit aus erfahrenen und proaktiven Mitarbeitern erstellt. Ausschlaggebend für die Prüfung eines Kandidaten für die Versetzung in eine neue Abteilung war das hohe Fachwissen in einem oder mehreren vorhandenen Informationssystemen.
Da es zu diesem Zeitpunkt kein klares Verständnis für die Arbeitsfront gab, wurde das Team etwas spontan gebildet. Gleichzeitig wurde damals bereits das Prinzip der Selbstversorgung festgelegt - Entwickler, Analysten und Tester im Team sollten ihre eigenen haben.
Als Strategie für die Umstellung auf Microservices wurden zwei Pfade gleichzeitig gewählt:
- wir nehmen in Microservices heraus, was (wie wir dachten) am einfachsten herauszunehmen ist;
- Wir bringen diejenigen in Microservices, deren Übertragung auf Microservices die meisten Probleme für Unternehmen und IT löst.
Der erste Weg war gut, da das Team dabei das erforderliche Fachwissen erwerben und seine Hand füllen würde, wodurch die Effizienz für spätere Arbeiten erhöht würde. Der zweite Weg bestand darin, dem Team eine Art schnellen Sieg zu bescheren, die Richtigkeit der gewählten Entscheidung zu zeigen, auf Microservices für das Unternehmen umzusteigen, und das Team für neue Leistungen zu motivieren.
Das Team war am Anfang der Reise. Es war eine glückliche Zeit: Die Zukunft sah hell und wolkenlos aus, und es schien uns, als hätten wir einen Plan.
Erste Schwierigkeiten
Und da es sich um Microservices handelt, müssen wir natürlich über Monolithen sprechen. Dies sind unsere Hauptinformationssysteme.
Die Architektur unserer einzelnen Systeme lässt sich am besten anhand dieses Bildes aus dem Artikel von Stefan Tilkov "Beginnen Sie nicht mit einem Monolithen" veranschaulichen. Wie wir sehen können, sind die Funktionsblöcke im Monolithen extrem eng miteinander verwandt. Dies ist ein ernstes Hindernis für die Übertragung einer separaten Funktionalität auf einen Mikrodienst.
Als Referenz sind unsere Monolithen ungefähr 13 Jahre alt und die durchschnittliche Codebasis des Monolithen beträgt ungefähr 1,2 Millionen Zeilen.
Mit anderen Worten, das Team hatte immer wieder mit folgenden Problemen zu kämpfen:
- extrem zeitaufwändiger Prozess zur Analyse der vorhandenen Funktionalität;
- oft mangelndes Verständnis dafür, was genau wir in den Microservice bringen;
- die Komplexität der Integration des Monolithen in den neuen Mikrodienst.
In Anbetracht der Tatsache, dass das Team nicht nur diese Probleme lösen musste, sondern auch das Fachwissen über einen neuen Stapel und einen neuen Entwurfsansatz erweitern musste, gingen die Fortschritte nicht sehr schnell voran.
Trotzdem zeigte das Team nach einigen Monaten die ersten Ergebnisse - die ersten Microservices stellten ihre APIs allen freundlich zur Verfügung. Das Team glaubte an sich selbst und wusste mit Sicherheit, dass sie alles richtig machten. Nun, viele Dinge in unserem Leben sind ziemlich illusorisch.
Erste Erfolge und neue Schwierigkeiten
Trotz der ersten Schwierigkeiten erhielt das Team sowohl neue Erfahrungen als auch erste Ergebnisse. Es sind jedoch einige Risiken aufgetreten, die den Start von Microservices verhindert haben.
- Es stellte sich heraus, dass die Monolithen nicht bereit waren, mit dem neuen Stapel zu arbeiten, und die Integration wurde verzögert.
- - .
- , , , , .
Die ersten beiden Probleme wurden ganz einfach gelöst - indem separate Clients geschrieben wurden, um den Monolithen und den Mikroservice zu integrieren, und die Monolithfunktionalität entsprechend angepasst wurde. Das dritte Problem ist jedoch bis heute nicht vollständig gelöst.
Ressourceninkonsistenzen wurden teilweise durch kollaborative Ressourcenplanung behoben. Es schien, als hätte das Team alle Fehler berücksichtigt, es gab ein Verständnis dafür, was und wie richtig zu tun ist, und bis Anfang 2020 wurden etwa ein Dutzend Microservices geschrieben (einige erwiesen sich als überhaupt keine Mikrodienste), die auf die Integration und Freigabe in die Produktion warteten. Sie deckten ihre Funktionalität ab Die meisten geschäftskritischen Prozesse wie die Berechnung der Kosten und der Lieferzeit, der Abschluss neuer Regionen und Büros auf der Verkaufsstelle, die Suche und Auswahl von Waren usw.
Wir sind zuversichtlich vorangekommen, haben bereits solide Erfahrungen gemacht und viele Unebenheiten gefüllt. Es schien, als wären wir mit all den Fallstricken konfrontiert, und jetzt bleibt es nur noch bewusst, Schritt für Schritt unseren Plan umzusetzen.
Gut…
Quarantäne, Arbeitskräfte und schließlich Erfolg
Zu Beginn des Jahres wurden unsere Pläne erheblich angepasst, was auf die Folgen des damals verbreiteten neuen Coronavirus zurückzuführen ist. Es ist offensichtlich nicht nötig zu erklären, worum es geht: Jeder weiß bereits viel über dieses Thema.
Der Ausbruch der Pandemie und die damit einhergehende Wirtschaftskrise zwangen unser Unternehmen, seine Entwicklungsprioritäten leicht zu überdenken. Infolgedessen änderten sich die IT-Prioritäten - neue Aufgaben wurden festgelegt, um Geschäftsprozesse schnell an neue Realitäten anzupassen.
Die Änderungen betrafen auch Pläne für Microservices. Aufgrund der Neuzuweisung von Ressourcen wurde die Integration von Mikrodiensten mit Monolithen und folglich die Freigabe der Mikrodienste selbst erneut verschoben.
Hier ist es schließlich notwendig, genauer zu untersuchen, was im Team geschah und wie sich das Team fühlte.
Erstens Demotivation. Aufgrund des langen Fehlens eines soliden Ergebnisses und der Tatsache, dass fast ein Jahr lang keine vollständig vorgefertigten und integrierten Mikrodienste in der Produktion waren, war das Team moralisch sehr ausgebrannt (gegen diesen Begriff, aber dennoch). Die Effizienz ist stark zurückgegangen. Nicht ohne seltene, aber lebhafte emotionale Zusammenbrüche.
Zweitens Quarantäne und ein vollständiger Übergang zur Fernbedienung. Natürlich haben wir eine Fülle von Erfahrungen in der Remote-Arbeit: Fast ⅔ der Entwickler sind Remote-Mitarbeiter. Aber alle, die an Microservices arbeiteten, arbeiteten im selben Büro zusammen, und der Übergang zur Remote-Arbeit hatte keinen optimalen Einfluss auf die Effektivität des Teams. Einerseits die Tatsache, dass es Zeit für die Umstrukturierung und den Übergang zu einem neuen Arbeitsformat brauchte. Andererseits war in Zeiten abnehmender Teammotivation mehr persönliche Kommunikation und gegenseitige Unterstützung innerhalb des Teams erforderlich.
Drittens musste das Team das Ergebnis zeigen. In der Tat hat das gesamte Team trotz interner und externer Probleme klar verstanden: Das weitere Schicksal des gesamten Unternehmens hängt davon ab, wie schnell wir unsere Ziele zu einem soliden Ergebnis bringen können. Viele in unserem Unternehmen waren bereit, das Experiment, auf Microservices umzusteigen, als unzeitgemäß, erfolglos zuzugeben und die Abteilung aufzulösen.
Fast zwei Monate lang arbeitete das Team 12 bis 15 Stunden, oft sieben Tage die Woche. Und sie konnte das gewünschte Ziel erreichen - vier Mikrodienste, die voll funktionsfähig und vollständig in monolithische Systeme integriert waren, wurden sofort vollständig produziert.
Es ist wichtig zu beachten, dass wir keine kniffligen Techniken angewendet haben, um das Team zu motivieren. Es gibt kein Know-how zum Teilen. Es ist nur Tag für Tag, als das Team Folgendes tat:
- häufige Skype-Anrufe mit Aktualisierung des aktuellen Arbeitsstatus und sofortiger Lösung neu auftretender Probleme;
- Aufrechterhaltung einer positiven Einstellung im Team mit ständiger Überprüfung des jeweiligen Ressourcenzustands.
Als Ergebnis
Anstelle einer Schlussfolgerung möchte ich auf die Schlussfolgerungen eingehen, die wir für uns selbst gezogen haben ...
- Cross Teams. Um solch ehrgeizige Projekte erfolgreich umzusetzen, muss es ein voll engagiertes und autonomes Team geben, das über ausreichende Ressourcen verfügt, um jedes Problem zu lösen. In unserem Fall bedeutet dies, dass das Team, das Microservices auf einem neuen Stack erstellt, Mitarbeiter der Monolith-Entwicklungsteams haben sollte. Wenn wir dies früher verstanden hätten und diese Idee bis zum Ende vorantreiben könnten, hätten wir Fehler vermeiden können, die mit unzureichendem Fachwissen über Geschäftsprozesse und inkonsistenten Ressourcen für die Integration von Microservice und Monolith verbunden sind.
- . , , . . , , , , . .
- . , . .
Nachdem wir nun an den Fehlern gearbeitet haben, können wir mit Zuversicht sagen: Das Experiment, das vor fast anderthalb Jahren begann, kann als erfolgreich angesehen werden. Und jetzt, aus der Kategorie eines Experiments, wird das Projekt des Übergangs zu einer Microservice-Architektur zu einer der wichtigsten IT-Strategien in unserem Unternehmen.
In Zukunft werden wir auf dieses Thema zurückkommen und detaillierter über den Technologie-Stack, individuelle Lösungen und vieles mehr sprechen. Wir haben genug Material und Erfahrung gesammelt.