More Speed for Nubus, More Predictability for UCS: Separate Maintenance Cycles for IAM and Operating Environment

With UCS 5.3, we are introducing an important structural change to our maintenance concept: We are following our product structure and splitting the previously shared maintenance commitment for the combination of Nubus as an Identity & Access Management solution (IAM) and UCS as the operating environment into two independent commitments.

What may initially sound like an internal restructuring has practical benefits for operators: more predictable updates at the operating level (UCS) and faster access to new features at the IAM level (Nubus).

In this article, we explain why we are taking this step, what specifically is changing – and what stays the same.

Until now, the maintenance commitment for Nubus and the underlying UCS operating environment was jointly tied to the release cycle of UCS. This meant: A shared commitment for stable, backward-compatible maintenance, with optionally long durations (LTS), covered both the IAM functionality of Nubus and the technical operating environment UCS.

Larger, potentially incompatible changes, for example new features affecting existing configurations, the switch to a new major version of an upstream component such as a new Debian version, or the deprecation of individual features, were generally tied to UCS minor or major releases.

This model was common practice for many years: Within a minor release, the environment remains stable, and larger changes are bundled and announced.

With Nubus as an independent product that can be operated both on UCS and on Kubernetes, the limits of this tight coupling to exactly one release rhythm became apparent. The different requirements of IAM functionality and operating platform can be better represented through separate release and maintenance cycles.

Two challenges have become particularly evident in this regard:

1. New features had to wait for the next release: A planned change, for example a new Nubus feature or an update of an IAM component, could not be released as soon as it was ready. Instead, it had to wait for the next minor release of UCS. As a result, new features were unnecessarily delayed.

2. Too many changes came at once: When a minor or major release was published, it inevitably contained both changes to the operating environment (for example the Debian base or system services) and changes at the IAM level, such as the switch to Keycloak in UCS 5.2.
   For operators, this meant: A single update event that simultaneously involved infrastructure testing, adjustments to connected applications, as well as coordination with various responsible parties and stakeholders.

As a result, updates became more extensive than they needed to be. In practice, this often led to rollouts taking longer, because many different tasks had to be taken into account at the same time.

With UCS 5.3, we are splitting the maintenance commitment into two independent lines:

• UCS as the operating environment receives its own maintenance commitment for the underlying distribution, system services, and operation in virtual machines or on hardware.
• Nubus as the IAM solution receives its own maintenance commitment for directory service, single sign-on, portal, and the features built upon them, regardless of whether Nubus is operated under UCS or under Kubernetes.

Both commitments continue to follow the proven principle of stable, backward-compatible maintenance with optionally long durations (LTS). The change does not mean a reduction in maintenance, but rather a better alignment with the actual product structure.

Larger, potentially incompatible changes will in future be tied to the respective release cycle of each individual level, no longer automatically to one another.

Specifically, this means:

• New Nubus features can be released independently of the release cycle of the UCS operating environment, without having to wait for the next minor release of UCS.
• Updates to the UCS operating environment can be planned without automatically including larger changes to the IAM functionality.
• Operators can manage testing effort and stakeholder involvement in a more targeted way: A UCS update primarily affects administrators and infrastructure managers. A Nubus update primarily affects application owners and teams that manage connected applications.

This makes operations overall simpler and more predictable and new features can be provided faster.

As important as this structural change is: The fundamental promise does not change.

• The maintenance commitments remain comprehensive. For both UCS as the operating environment and Nubus as the IAM solution, the following continues to apply: stable, backward-compatible maintenance, optionally with long durations (LTS). We are splitting the commitment across two levels, we are not reducing it.
• The scope of contracts does not change. There are no changes to our fundamental customer promise within existing subscription contracts.
• Nubus remains flexible to operate. The separate maintenance commitment applies to Nubus regardless of the operating form, both for Nubus on UCS as a virtual machine and for Nubus for Kubernetes.

The new, separate maintenance policy takes effect with the stable release of UCS 5.3.

The exact details, for example specific durations, affected components, and the precise delineation between the UCS operating environment and the Nubus level, will be discussed with interested customers and communicated in good time before the availability of UCS 5.3.

This change is a direct result of the feedback we have received from operators and IT decision-makers regarding the previous update rhythm. If you are interested in being involved in the further discussion, please feel free to get in touch with us!

We look forward to your feedback, here, at help.univention.com, or with your contact person at Univention.