Versionierung und Release-/Abhängigkeits-Management in einer großen Microservice Architektur

[LimDul]

Ich stehe wahrscheinlich demnächst vor der Herausforderung die Versionierung und dem Abhängigkeitsmanagement einer großen Microservice Architektur verantwortlich zu sein. (Oder zumindest einen Plan ausgearbeitet zu haben).

Frage wäre da, was gibt es an Tools/Best-Practices dafür? Gerne auch Links oder ähnliches.

Kontext: Wir reden von ca. 40-50 Services in verschiedenen Größenklassen. Von extrem kleinen Microservices mit 2 Rest-Services bis hin zu fully featured Business Anwendungen die eigentlich kein Microservice mehr sind. Es gibt die diversesten Abhängigkeiten untereinander (also wer welchen Service konsumiert) und die Abhängigkeiten sind auch nicht zyklenfrei.

Die Herausforderung aus meiner Sicht ist da den Überblick zu behalten, was mit wem kompatibel ist. Jede Anwendung wird ihre eigene Versionsnummer angelehnt an Sementic Versioning (https://semver.org/) erhalten. Nur wie manage ich, welche Anwendung von welcher Abhängig ist? Aktuell würde es entweder Confluence oder Excel werden - beides mit Sicherheit nicht die besten Tools dafür

Hinzu kommt dann auch das Thema Release Management - wir haben zig Umgebungen die mit unterschiedlichen Versionsständen bestückt sein werden, wo wir auch den Überblick behalten müssen, was da drauf ist. Es wird (nicht am Anfang, aber im Laufe des Projektes) auch parallele Entwicklungen geben, was das ganze noch mal verkomplizieren wird.

Deswegen gerne Anregungen zu Tools, Artikeln, Tutorials, Best Practices etc. Ich weiß was ich will, aber nicht wie ich effizient dahin komme

 

[KonradN]

Hier ist jetzt natürlich die Frage, auf welche Problematiken Du genau hinaus willst.

Wenn es nur rein um das Management geht: Da sollte es eine zentrale Dokumentation geben, was wie vorhanden ist und wer wofür verantwortlich ist. Das kann z.B. ein eigenes Portal sein, in dem sowas klar dokumentiert wird. Das ist sinnvoll, um alleine schon eine Dokumentation zu haben, was es schon alles gibt um zu vermeiden, dass irgendwas an mehreren Stellen verwaltet wird. Ob man hier dann wirklich auch Abhängigkeiten Dokumentieren will? Eigentlich sollte es egal sein, wer einen Service nutzt. Der Service ist halt da und jeder kann ihn nutzen. Aber ja: Wenn man sowas erfasst, dann hat man natürlich auch die Möglichkeit, sich diese Daten aufzubereiten um dann z.B. grafisch die Dependencies aufzuzeigen.

Was man in so ein Portal alles hinein packen will, kann man sich überlegen. Da kann man dann halt zum einen viele Informationen hinterlegen (Beschreibungen, ggf. fertige Libraries oder Tools zur Nutzung) als auch so Dinge wie Automatische Info-Emails. (Also so nach dem Motto: Ich will Service X nutzen, also füge ich mich da in einer Art Mailliste hinzu und schon bekomme ich alle Informationen zu Änderungen und so ...)

Breaking Changes sind natürlich immer schlecht. Also Worst Case sozusagen: Ein Service wechselt die Schnittstelle von v1 zu v2. Das wäre dann aber über die definierten Schnittstellen zu kommunizieren. Im Idealfall hat man einen Parallelen Betrieb und dann haben die Nutzer eine gewisse Zeitspanne, umzusteigen.

Das Ganze bedarf dann nach meiner Erfahrung einer Art Governance Truppe oder Architektur oder so. Also eine Autorität, die gewisse Dinge durchsetzen kann und auch Zeit hat, sich da aktiv drum zu kümmern.

Was Anderes / Besseres sehe ich jetzt auch nicht wirklich. Was man natürlich auch noch machen könnte: Bündelung von Services. Statt also viele einzelne Services zu verwalten, kann man intern viele einzelne Services haben, aber man gibt dann nach außen eine Schnittstelle heraus. Ich weiss nicht, wie Ihr organisiert seid, aber wenn es da Strukturen gibt, dann kann man da tatsächlich Dinge bündeln.
Dann habt ihr nicht mehr die einzelnen Services A, B, C, D ... sondern nur noch einen großen. Das geht dann natürlich alles auf die einzelnen Services, aber da hat man dann deutlich mehr Spielraum für Veränderungen. Wie sowas aussehen könnte muss man dann sehen. (Ich bin in so einem Umfeld tätig, wobei ich keinen wirklichen Einblick habe, was da dann unter der Oberfläche an Technologien eingesetzt wurde.)

 

[Oneixee5]

Mir kam auch als erstes in den Sinn ein Proxy davor zu stellen. So kann man gegenseitige und zyklische Abhängigkeiten intern halten/kapseln und alles nach außen als einen kompletten Service darstellen..

 

[Ebi]

Meine Idee wäre, dass man die Abhängigkeiten in den Services selbst dokumentiert, als JSON zum Beispiel irgendwie so:

{
    "dependencies": [
        {
            "service": "A",
            "version": "1.+"
        },
        {
            "service": "B",
            "version": "2.1.1"
        }...
    ]
}

Dann würde ich in jedem service einen Endpunkt bauen, der diese Info + die aktuelle Version des services zurück gibt. Damit könnte man zu jedem Service gehen, sich seine Version und seine Dependencies holen und die Infos aufbereiten. Zum Beispiel in Confluence, als Powerpoint fürs Management, in excel, mit graphviz visualisieren oder mit irgendeinem hippen Javascript-Framework ein kleines Portal basteln.
Ich finde es gut, wenn Doku so nahe wie möglich am Code ist, damit die Informationen zwischen Doku und Code nicht so leicht auseinander laufen.