Maintenance Without Windows: Rolling Upgrades Through Regional Decoupling

In the traditional IT world, maintenance windows are often a necessary evil. Operating system updates, Kubernetes upgrades, or critical database patches are usually performed at night or on weekends to minimize user disruption. However, in a KRITIS environment that requires 24/7 availability, this model poses a high risk: if something goes wrong during maintenance, the system comes to a halt, and redundancy is often suspended during the process.

Through our multi-region architecture with separate clusters, we transform the risk of “maintenance” into a standard process with zero downtime.

1. The Concept of Rolling Regional Maintenance

Instead of updating the entire platform at once, we use geographic separation as a safety barrier. We treat an entire region as a unit that can be temporarily taken offline.

1. Traffic Drain: Through Anycast routing or the Global Load Balancer, all incoming traffic is controlled and redirected from Region A to Region B. Thanks to session persistence (see Part 7), users do not notice this switch.
2. Isolated Maintenance: Region A is now completely load-free. The Ops team can calmly make deep changes: jump Kubernetes versions, reprovision nodes, or swap hardware components.
3. Validation: Before traffic is redirected back, Region A undergoes automated health checks and smoke tests. Only when the region is demonstrably healthy is it released back for production traffic.
4. Cross-Check: The process is then repeated for Region B.

2. Risk Minimization Through “Canary Releases” at the Infrastructure Level

A major advantage of this strategy is error containment (blast radius). If a new update contains a subtle bug that only appears under real load, this error initially affects only one region. Since the second region is still running on the old, stable version, we can switch the traffic back within seconds. The platform as a whole remains 100% available to the outside world while internal root cause analysis begins in the affected region.

3. Relief for the Ops Team

Maintenance windows at 3 AM lead to fatigue and human error. Through regional decoupling, upgrades occur during regular working hours.

• Better Support Coverage: Should a problem arise, all specialists and even the support teams of software vendors (e.g., cloud providers or database vendors) are on duty.
• No “Point of No Return” Fear: Since a fully functional region is always available in the background, the pressure on administrators is significantly reduced.

Conclusion: Availability as a Constant State

A modern KRITIS platform is characterized by its ability to renew itself during operation. The multi-region architecture makes maintenance windows obsolete while simultaneously increasing security with each update. For the customer, this means: The platform is simply always there—without “planned interruptions” in the availability statistics.

FAQ

Are there brief connection drops during traffic switching? With properly configured load balancers and Anycast routes, existing connections (“long-lived connections”) are often completed (connection draining) while new requests already flow to the other region. A minimal packet loss in the millisecond range is theoretically possible but is automatically corrected by modern web protocols like TCP/QUIC.

Can a single region handle the entire load of all customers? Yes, this is the prerequisite for this model. Each region must be dimensioned to take over 100% of the system’s load in the event of maintenance or a real disaster.

How is it ensured that configurations remain synchronized after maintenance? We use GitOps (e.g., ArgoCD) for this. The configuration of both regions is defined in the Git repository. After maintenance, the system automatically ensures that the target state matches the repository again to avoid “configuration drift.”

What happens if an application requires a database schema update? This is the most complex part. We use strategies like “Expand and Contract.” The database schema is expanded so that both the old and new versions of the application can work with it simultaneously. Thus, Region A can already run with the new code while Region B still uses the old one.

How does ayedo support the planning of update processes? We develop “update playbooks” with you and automate traffic switching. We ensure that your infrastructure upgrades are no longer nerve-wracking but become an unspectacular standard procedure.