Mehr Tempo für Nubus, mehr Planbarkeit für UCS: Getrennte Maintenance-Zyklen für IAM und Betriebsumgebung

Mit UCS 5.3 führen wir eine wichtige strukturelle Änderung unseres Maintenance-Konzepts ein: Wir folgen unserer Produktstruktur und trennen die bisher gemeinsame Pflegezusage für die Kombination aus Nubus als Identity-&-Access-Management-Lösung (IAM) und UCS als Betriebsumgebung in zwei eigenständige Zusagen.

Was zunächst nach einer internen Umstrukturierung klingt, hat für Betreiber praktische Vorteile: planbarere Updates auf der Betriebsebene (UCS) und schnelleren Zugang zu neuen Funktionen auf der IAM-Ebene (Nubus).

In diesem Artikel erklären wir, warum wir diesen Schritt gehen, was sich konkret ändert – und was gleich bleibt.

Bisher war die Maintenance-Zusage für Nubus und die zugrunde liegende UCS-Betriebsumgebung gemeinsam an den Release-Zyklus von UCS gekoppelt. Das bedeutete: Eine gemeinsame Zusage für stabile, abwärtskompatible Pflege mit optional langen Laufzeiten (LTS) deckte sowohl die IAM-Funktionalität von Nubus als auch die technische Betriebsumgebung UCS ab.

Größere, potenziell inkompatible Änderungen, beispielsweise neue Funktionen mit Auswirkungen auf bestehende Konfigurationen, der Wechsel auf eine neue Major-Version einer Upstream-Komponente wie eine neue Debian-Version oder die Abkündigung einzelner Funktionen, waren grundsätzlich an UCS Minor- oder Major-Releases gekoppelt.

Dieses Modell war über viele Jahre gängige Praxis: Innerhalb eines Minor-Releases bleibt die Umgebung stabil, größere Veränderungen werden gebündelt und angekündigt.

Mit Nubus als eigenständigem Produkt, das sowohl auf UCS als auch auf Kubernetes betrieben werden kann, wurden die Grenzen dieser engen Kopplung an genau einen Release-Rhythmus sichtbar. Die unterschiedlichen Anforderungen von IAM-Funktionalität und Betriebsplattform lassen sich besser durch getrennte Release- und Maintenance-Zyklen abbilden.

Zwei Herausforderungen haben sich dabei besonders gezeigt:

1. Neue Funktionen mussten auf das nächste Release warten: Eine geplante Änderung, beispielsweise eine neue Nubus-Funktion oder ein Update einer IAM-Komponente, konnte nicht veröffentlicht werden, sobald sie fertig war. Stattdessen musste sie auf das nächsten Minor-Release von UCS warten. Dadurch wurden neue Funktionen unnötig verzögert.
2. Zu viele Änderungen kamen gleichzeitig: Wenn ein Minor- oder Major-Release erschien, enthielt er zwangsläufig sowohl Änderungen an der Betriebsumgebung (beispielsweise Debian-Basis oder Systemdienste) als auch Änderungen an der IAM-Ebene, wie der Umstieg auf Keycloak in UCS 5.2.
   Für Betreiber bedeutete das: Ein einziges Update-Ereignis, das gleichzeitig Infrastrukturtests, Anpassungen an angebundenen Anwendungen sowie die Abstimmung mit verschiedenen Verantwortlichen und Stakeholdern.

Dadurch wurden Updates umfangreicher, als sie sein müssten. In der Praxis führte dies häufig dazu, dass Rollouts länger dauerten, weil viele unterschiedliche Aufgaben gleichzeitig berücksichtigt werden mussten.

Mit UCS 5.3 trennen wir die Maintenance-Zusage in zwei eigenständige Linien:

• UCS als Betriebsumgebung erhält eine eigene Maintenance-Zusage für die zugrundeliegende Distribution, Systemdienste und den Betrieb in virtuellen Maschinen oder auf Hardware.
• Nubus als IAM-Lösung erhält eine eigene Maintenance-Zusage für Verzeichnisdienst, Single Sign-on, Portal und die darauf aufbauenden Funktionen – unabhängig davon, ob Nubus unter UCS oder unter Kubernetes betrieben wird.

Beide Zusagen folgen weiterhin dem bewährten Prinzip stabiler, abwärtskompatibler Pflege mit optional langen Zeiträumen (LTS). Die Änderung bedeutet keine Abschwächung der Maintenance, sondern eine bessere Anpassung an die tatsächliche Produktstruktur.
Größere, potenziell inkompatible Änderungen sind künftig an den jeweiligen Release-Zyklus der einzelnen Ebene gekoppelt, nicht mehr automatisch aneinander.

Das bedeutet konkret:

• Neue Nubus-Funktionen können unabhängig vom Release-Zyklus der UCS-Betriebsumgebung veröffentlicht werden, ohne auf den nächsten Minor-Release von UCS warten zu müssen.
• Updates der Betriebsumgebung UCS können geplant werden, ohne dass automatisch größere Änderungen an der IAM-Funktionalität enthalten sind.
• Betreiber können Testaufwand und Stakeholder-Einbindung gezielter steuern: Ein UCS-Update betrifft primär Administratoren und Infrastrukturverantwortliche. Ein Nubus-Update betrifft primär Anwendungsverantwortliche und Teams, die angebundene Anwendungen betreuen.

So wichtig diese strukturelle Änderung ist: Am grundsätzlichen Versprechen ändert sich nichts.

• Die Maintenance-Zusagen bleiben umfassend. Sowohl für UCS als Betriebsumgebung als auch für Nubus als IAM-Lösung gilt weiterhin: stabile, abwärtskompatible Pflege, optional mit langen Laufzeiten (LTS). Wir teilen die Zusage auf zwei Ebenen auf – wir reduzieren sie nicht.
• Der Umfang von Verträgen ändert sich nicht. Es gibt keine Änderungen an unserem grundsätzlichen Kundenversprechen im Rahmen bestehender Subskriptionsverträge.
• Nubus bleibt flexibel betreibbar. Die getrennte Maintenance-Zusage gilt für Nubus unabhängig von der Betriebsform, sowohl für Nubus auf UCS als virtuelle Maschine als auch für Nubus für Kubernetes.

Die neue, getrennte Maintenance Policy tritt mit dem stabilen Release von UCS 5.3 in Kraft.

Die genauen Details, beispielsweise konkrete Laufzeiten, betroffene Komponenten und die genaue Abgrenzung zwischen UCS-Betriebsumgebung und Nubus-Ebene, werden wir mit interessierten Kunden diskutieren und rechtzeitig vor Verfügbarkeit von UCS 5.3 kommunizieren.

Diese Änderung ist ein direktes Ergebnis der Rückmeldungen, die wir von Betreibern und IT-Entscheidern zum bisherigen Update-Rhythmus erhalten haben. Wenn Sie Interesse haben, in der weiteren Diskussion eingebunden zu sein, melden Sie sich gerne bei uns!

Wir freuen uns auf Ihr Feedback, hier, auf help.univention.com oder bei Ihrer Ansprechperson bei Univention.