BaseCloud: Wann Hybrid Sinn ergibt — und wann nicht

„Wir brauchen Hybrid“ ist einer der häufigsten Einstiege in Cloud-Workshops — und einer der unpräzisesten. Hybrid ist kein Produkt-SKU, sondern ein Betriebsmodell, bei dem Workloads on-premises oder in einer souveränen Region bleiben, während andere in der Public Cloud laufen. Das kann für einen Mittelständler mit Shopfloor-PLCs, die keinen 40-ms-Roundtrip nach Frankfurt tolerieren, richtig sein. Es kann auch bedeuten, harte Entscheidungen zu verschieben, bis zwei parallele Plattformen Budget verbrennen und niemand die Integrationsschicht besitzt.

Bei QData sehen wir beide Muster jedes Quartal. Der Unterschied ist selten Technologie. Es geht darum, ob das Management die Constraint benannt hat, die Hybrid lösen soll, ein Review-Datum gesetzt und den Betrieb für zwei Estates finanziert hat — ohne so zu tun, als könne ein Team beides nebenbei.

Wann Hybrid rational ist

Drei Signale rechtfertigen in unseren Architektur-Reviews konsequent einen geteilten Estate. Erstens Latenz und Ort. Fertigungslinien, Trading Floors, klinische Geräte oder Lagerautomatisierung brauchen oft Compute in Metern oder Millisekunden Entfernung. Batch-Analytik in die Cloud, Regelkreis on-prem — ein klassischer, vertretbarer Split, sofern Datenflussrichtung und Change-Freigabe dokumentiert sind.

Zweitens Datengravitation und Recht. Ein polnischer Versicherer durfte Rohdaten nicht in eine US-Region-SaaS, aber aktuarielle Modelle auf anonymisierten EU-Aggregaten. Die Grenze war explizit: nur pseudonymisierte Extracts, nächtlich, mit DPO-Sign-off auf dem Transformationsjob. Hybrid ist hier keine Unentschlossenheit, sondern eine rechtliche Partition mit technischer Durchsetzung.

Drittens Legacy-Kopplung. Ein ERP, das in 12–18 Monaten nicht containerisiert werden kann, aber Bestellungen mit einem neuen Kundenportal tauschen muss, ist ein legitimer Hybrid-Kandidat — mit Integrationsvertrag, Sunset-Datum und Verweigerung eines vierten Ad-hoc-VPN „für nur ein Büro mehr“.

In diesen Fällen ist Hybrid ein Übergang oder dauerhafte Partition mit klaren Grenzen. Der Fehler ist, es als „Best of both worlds“ zu behandeln, ohne Betreiber, Incident-Owner über die Grenze und Identity-Flow zu benennen.

Wann Hybrid eine Falle ist

Hybrid scheitert bei Komfortentscheidungen. Wir auditieren regelmäßig Estates mit alten VMs „zur Sicherheit“, zwei Monitoring-Stacks mit widersprüchlichem Status und doppeltem Patch Tuesday, weil niemand Konsolidierung besitzt. Teams zahlen Cloud-Flexibilität und betreiben vollständig On-Prem — ohne Automatisierung für beide Seiten.

Eine weitere Falle ist Network Spaghetti. Site-to-Site-Links, Hairpinning und manuelle Firewall-Tickets pro Microservice machen Hybrid zur Reibung. Wenn ein neuer Service ein Change Window über zwei Netzwerkteams und ein vierzehntägiges CAB braucht, haben Sie keine Resilienz gebaut — sondern eine Warteschlange. Ein Kunde gab mehr für MPLS aus als für die Refaktorierung eines Monolithen zu einer Cloud-API.

Subtiler ist Identity Drift: doppelte Konten, unterschiedliche MFA on-prem vs Cloud, Break-Glass-Passwörter an drei Orten. Incidents in SaaS-Admin-Konsolen enden in AD ohne korrelierte Logs. Hybrid ohne Single-IdP-Strategie sind zwei Angriffsflächen mit VPN dazwischen.

Entscheidungsframework für einen Workshop

Bewerten Sie Workloads auf vier Achsen (1–5): Refaktorierbarkeit, Regulierung, operative Reife, Egress-Kostensensitivität. Hohe Regulierung und niedrige Refaktorierbarkeit → On-Prem oder Private Zone. Hohe Refaktorierbarkeit und elastische Nachfrage → Public Cloud. Die Mitte → Pilot-Landing-Zone mit 90-Tage-Review und benanntem Executive Sponsor.

In einem Halbtags-Workshop mit einem Logistiker mit 200 Mitarbeitern zeigte die Übung einen klaren Cloud-Gewinner (Track-and-Trace-API) und einen klaren Verbleib (Etikettendrucker im flachen L2). Die strittige Mitte — nächtliche Routenoptimierung — ging in den Pilot mit Egress-Cap und Git-Reproduzierbarkeit. Die Politik verstummte, weil die Kriterien an der Wand hingen.

Dokumentieren Sie Exit-Trigger: z. B. „wenn monatliche Cross-Estate-Incident-Stunden 40 übersteigen, konsolidieren wir das Netzwerk“ oder „wenn die ERP-REST-Fassade live ist, wandern Batch-Jobs in die Cloud“. Ohne Trigger driftet Hybrid endlos.

BaseCloud als Landing Zone — kein Slogan

Bei QData ist BaseCloud der strukturierte Start: IdP-Identity, zentrales Logging, verschlüsseltes Backup, Netzwerksegmentierung und IaC. Ob die Landing Zone in Public Cloud, Partner-DC oder Mix liegt — es geht um eine operative Sprache: Runbooks, Monitoring, Access Reviews, bevor die Workload-Anzahl wächst.

BaseCloud ist absichtlich langweilig. Wenige Integrationspunkte. Standard-Tags. Eine Karte, welche Subnetze welche Datenklassen erreichen dürfen. Backup-Policies nach Tier, nicht nach Heldentum. Wenn ein Prüfer fragt „wie wissen Sie, dass diese VM im Scope ist?“, öffnen Sie ein Dashboard, kein Spreadsheet von 2019.

Hybrid-Architekturen, die Audits und Incidents überstehen, sind absichtlich langweilig: starke Observability, dokumentierte Datenflüsse, eine On-Call-Rotation für beide Seiten — oder ein Managed Partner. Wenn Ihr Diagramm eine Legende für Pfeilrichtungen braucht, vereinfachen Sie vor dem Skalieren.

Szenario: Hersteller vs SaaS-Scale-up

Vergleichen Sie zwei Kunden mit derselben Schlagzeile — „wir sind hybrid“. Der Hersteller hält SCADA und Historian on-prem, sendet anonymisierte Telemetrie in die Cloud für Predictive Maintenance, nutzt SaaS für HR/CRM mit SSO aus Entra ID. Incidents haben Runbooks pro Tier; Cross-Boundary-Flows sind drei, nicht dreißig. Exit-Trigger: „neue Linie bekommt Edge-Gateway-Standard in Q3“.

Der Scale-up betreibt Produktions-Kubernetes in der Cloud, aber „temporäres“ PostgreSQL auf einem Büro-NAS, Dev-DBs auf Laptops und vergessenes Jenkins auf einer VM „weil Pipelines sensibel sind“. Das ist kein Hybrid, sondern Schulden mit einer Multi-Cloud-Folie. Die Lösung: Konsolidierung in eine Landing Zone und Moratorium für neues On-Prem ohne Architecture Board.

Ihre Organisation ähnelt wahrscheinlich einer dieser Geschichten mehr als der anderen. Die Benennung, welche Sie erzählen, ist der erste Schritt zu einem Hybrid-Design, das in achtzehn Monaten noch Sinn ergibt.

Nächster Schritt

Inventarisieren Sie zehn Workloads — nicht fünfzig in einem veralteten Wiki. Führen Sie die Vier-Achsen-Bewertung mit Infrastruktur, Security und Business Owner durch. Wählen Sie einen Piloten, der sicher scheitern darf, mit Rollback und 90-Tage-Checkpoint. Für externe Prüfung von Landing Zone, Migrationssequenz oder TCO zweier Estates beginnt unsere Praxis Cloud-Dienste mit Architektur und Betrieb — nicht mit Regalware-Lizenzen.