Wann On Premises und Cloud bewusst zusammengehören

Hybride Infrastruktur: Wann On Premises und Cloud bewusst zusammengehören

Hybride Infrastruktur wird häufig als Zwischenlösung verstanden. Ein Teil bleibt lokal, ein Teil wandert in die Cloud, und irgendwann soll alles vollständig migriert sein.

Diese Sicht ist zu einfach. In vielen Unternehmen ist hybride Infrastruktur keine Übergangsphase, sondern die sachlich richtige Architektur. Nicht jede Anwendung, jede Datenhaltung und jeder Prozess gehört automatisch in die Public Cloud. Entscheidend ist, ob die Entscheidung bewusst getroffen wurde.

Eine hybride Umgebung wird dann problematisch, wenn sie ungeplant entsteht. Sie wird tragfähig, wenn klar definiert ist, welche Systeme lokal bleiben, welche Dienste in Azure betrieben werden und wie Identität, Netzwerk, Sicherheit, Betrieb und Datenflüsse zusammenspielen.

Was bedeutet hybride Infrastruktur?

Hybride Infrastruktur verbindet lokale IT-Systeme mit Cloud-Diensten. Dazu gehören zum Beispiel lokale Server, Fachanwendungen, Datenbanken, Active Directory, Standorte, Produktionssysteme oder Spezialsoftware, die mit Azure, Microsoft 365 oder anderen Cloud-Plattformen verbunden werden.

Microsoft beschreibt Hybrid Cloud als Umgebung, in der lokale oder private Infrastruktur mit Public-Cloud-Diensten kombiniert wird.

Wichtig ist: Hybrid bedeutet nicht automatisch veraltet. Hybrid bedeutet, dass Workloads und Daten an unterschiedlichen Orten betrieben werden. Das kann technisch, regulatorisch oder wirtschaftlich sinnvoll sein.

Wann lokale Systeme sinnvoll bleiben

Es gibt mehrere Gründe, warum Teile einer IT-Umgebung weiterhin On Premises betrieben werden.

Ein häufiger Grund sind Fachanwendungen mit lokaler Abhängigkeit. Viele Branchenlösungen wurden über Jahre an lokale Datenbanken, Dateifreigaben, Maschinensteuerungen oder spezielle Schnittstellen angebunden. Eine direkte CloudMigration kann hier technisch möglich sein, aber unverhältnismäßig teuer oder riskant.

Auch regulatorische Anforderungen können eine Rolle spielen. Bestimmte Daten müssen nachvollziehbar gespeichert, verarbeitet oder getrennt betrieben werden. Dabei geht es nicht nur um Datenschutz, sondern auch um Nachweispflichten, Branchenvorgaben, Auditierbarkeit und interne Sicherheitsrichtlinien.

Ein weiterer Grund ist Latenz. Produktionssysteme, lokale Steuerungen oder Anwendungen mit sehr kurzen Reaktionszeiten sind nicht immer geeignete Kandidaten für eine vollständige Verlagerung in die Cloud. Wenn Millisekunden im Prozess relevant sind, muss die Architektur diese Anforderung berücksichtigen.

Lokale Systeme sind also nicht automatisch ein Rückstand. Sie sind dann sinnvoll, wenn es eine klare Anforderung dafür gibt.

Das eigentliche Risiko ist ungeplanter Wildwuchs

Hybride Infrastruktur wird selten durch die bloße Existenz lokaler Systeme problematisch. Problematisch wird sie, wenn keine klare Architektur vorhanden ist.

Typische Risiken sind:

• lokale und cloudbasierte Identitäten werden uneinheitlich verwaltet

• Berechtigungen sind nicht nachvollziehbar

• Netzwerkverbindungen entstehen punktuell statt geplant

• Daten liegen an mehreren Orten ohne klare Verantwortlichkeit

• Monitoring und Security sind getrennt

• Backups, Wiederherstellung und Notfallkonzepte sind nicht durchgängig

• Altanwendungen werden dauerhaft angebunden, obwohl eine Ablösung sinnvoller wäre

Dann entsteht keine hybride Architektur, sondern eine technische Zwischenwelt. Die Umgebung funktioniert zwar operativ, wird aber schwer prüfbar, schwer wartbar und schwer skalierbar.

Identität: Entra ID als zentrales Steuerungselement

In hybriden Microsoft-Umgebungen ist Identität ein zentraler Architekturpunkt. Benutzer, Gruppen, Rollen und Zugriffe müssen über lokale und cloudbasierte Systeme hinweg konsistent verwaltet werden.

Microsoft stellt dafür die Dokumentation zu Microsoft Entra Hybrid Identity bereit. Ziel ist es, lokale Verzeichnisse mit Microsoft Entra ID zu integrieren und Benutzern eine gemeinsame Identität für Microsoft 365, Azure und angebundene Anwendungen zu ermöglichen.

Für die Synchronisierung zwischen Active Directory und Microsoft Entra ID stehen zwei Werkzeuge zur Verfügung: das ältere Microsoft Entra Connect (Connect Sync, früher Azure AD Connect) und das neuere Microsoft Entra Cloud Sync. Cloud Sync ist ein cloudverwalteter Synchronisierungsdienst mit einem leichtgewichtigen Agenten und gilt als strategische Richtung von Microsoft. Neue Funktionen werden vorrangig für Cloud Sync entwickelt.

Cloud Sync ist allerdings nicht für jedes Szenario die passende Lösung. Zwischen beiden Werkzeugen bestehen weiterhin funktionale Unterschiede, die Microsoft in einem Decision Guide gegenüberstellt. Einige Szenarien werden von Cloud Sync derzeit nicht abgedeckt und erfordern weiterhin Connect Sync, zum Beispiel:

• Gerätesynchronisierung für Microsoft Entra Hybrid Join

• Konfiguration von Pass-through Authentication und AD FS

• komplexe, regelbasierte Synchronisierungslogik

• sehr große Umgebungen ab etwa 150.000 Objekten pro Domäne oder Gruppen mit mehr als 50.000 Mitgliedern

• bestimmte forestübergreifende Szenarien

Gerade in Enterprise-Umgebungen führt deshalb häufig kein Weg an Connect Sync vorbei, etwa wenn Geräte über Hybrid Join synchronisiert werden oder Pass-through Authentication im Einsatz ist.

Microsoft hat eine schrittweise Umstellung von Connect Sync auf Cloud Sync offiziell angekündigt und in den Entra-Release-Notes als geplante Änderung markiert. Ein verbindliches Enddatum für Connect Sync ist bislang nicht genannt. Die Umstellung erfolgt schrittweise und beginnt mit Umgebungen, die bereits vollständig von Cloud Sync unterstützt werden. Für die Architekturentscheidung bedeutet das: Das Synchronisierungswerkzeug sollte anhand der konkreten Anforderungen gewählt werden und nicht unter der Annahme, dass Cloud Sync bereits jeden Fall abdeckt.

Unabhängig vom Werkzeug bleibt das Zielbild entscheidend:

• Welche Identität ist führend?

• Welche Gruppen werden synchronisiert?

• Welche Berechtigungen werden lokal vergeben?

• Welche Berechtigungen werden in der Cloud vergeben?

• Wie werden privilegierte Konten geschützt?

• Welche Anwendungen hängen noch am lokalen Active Directory?

• Welche Anwendungen können direkt über Entra ID angebunden werden?

Ohne diese Klärung wird Identität in hybriden Umgebungen schnell zur Schwachstelle.

Netzwerk: Verbindung ist nicht gleich Architektur

Eine hybride Umgebung braucht eine geplante Netzwerktopologie. Es reicht nicht, lokale Systeme irgendwie mit Azure zu verbinden.

Microsoft beschreibt verschiedene Dienste für Azure-Hybridkonnektivität. Dazu gehören unter anderem VPN Gateway, ExpressRoute und Azure Virtual WAN.

^{Bildquelle: Microsoft Learn, Azure Virtual WAN and working remotely}

Ein VPN Gateway kann sinnvoll sein, wenn lokale Standorte verschlüsselt mit Azure Virtual Networks verbunden werden sollen. ExpressRoute ist relevant, wenn private Verbindungen über einen Connectivity Provider benötigt werden. Azure Virtual WAN kann eingesetzt werden, wenn mehrere Standorte, Verbindungen und Hubs zentral verwaltet werden sollen. Microsoft beschreibt Azure Virtual WAN als Dienst, bei dem VPN-, ExpressRoute- und Point-to-Site-Verbindungen über virtuelle Hubs organisiert werden können.

Die Architekturentscheidung sollte vor der Umsetzung fallen. Wichtige Fragen sind:

• Welche Standorte müssen angebunden werden?

• Welche Systeme kommunizieren mit welchen Cloud-Diensten?

• Welche Datenflüsse sind erlaubt?

• Wo werden Firewalls, DNS und Routing zentralisiert?

• Welche Verbindungen müssen redundant sein?

• Welche Anforderungen bestehen an Latenz und Verfügbarkeit?

• Wie wird der Netzwerkverkehr überwacht?

Wer diese Fragen nicht klärt, baut häufig Punkt-zu-Punkt-Verbindungen, die kurzfristig helfen, aber langfristig schwer kontrollierbar werden.

Betrieb: Azure Arc für einheitliche Verwaltung

Hybride Infrastruktur darf nicht bedeuten, dass lokale Systeme und Cloud-Systeme vollständig getrennt betrieben werden.

Mit Azure Arc stellt Microsoft eine Möglichkeit bereit, Ressourcen außerhalb von Azure in die Azure-Steuerungsebene einzubinden. Dazu zählen zum Beispiel lokale Server, Kubernetes-Cluster, Datenservices und Systeme in anderen Clouds.

^{Bildquelle: Microsoft Learn, Azure Arc overview}

Azure Arc erweitert Azure-Management-, Security- und Governance-Funktionen auf Ressourcen außerhalb von Azure. Das ist besonders relevant, wenn Unternehmen lokale Systeme behalten, aber trotzdem einheitlicher verwalten wollen.

Typische Ziele sind:

• zentrale Sicht auf lokale und cloudbasierte Ressourcen

• einheitlichere Governance

• bessere Nachvollziehbarkeit

• konsistenteres Monitoring

• Sicherheits- und Compliance-Auswertungen über mehrere Umgebungen hinweg

Azure Arc ersetzt keine saubere Architektur. Es kann aber helfen, hybride Umgebungen kontrollierter zu betreiben.

Daten: Nicht nur der Speicherort zählt

Bei hybrider Infrastruktur wird oft nur gefragt, wo Daten gespeichert werden. Das ist zu kurz gedacht.

Wichtiger ist die vollständige Datenlogik:

• Wo entstehen die Daten?

• Wo werden sie verarbeitet?

• Wo werden sie gespeichert?

• Wer greift darauf zu?

• Welche Daten dürfen die Umgebung verlassen?

• Welche Daten müssen lokal bleiben?

• Welche Daten werden synchronisiert?

• Welche Systeme sind führend?

• Wie werden Änderungen nachvollzogen?

Besonders kritisch sind halb migrierte Szenarien. Eine Anwendung bleibt lokal, ein Reporting läuft in der Cloud, Daten werden regelmäßig exportiert, und zusätzliche Prozesse greifen über APIs darauf zu. Ohne klare Datenarchitektur entstehen Inkonsistenzen und Verantwortungsprobleme.

Eine hybride Architektur muss deshalb nicht nur Systeme verbinden. Sie muss Datenflüsse definieren.

Wann ein vollständiger Schnitt sinnvoller ist

Nicht jede Altanwendung sollte dauerhaft angebunden werden. Manchmal ist die bessere Entscheidung, eine Anwendung abzulösen, statt sie über Jahre in eine hybride Architektur einzubinden. Das gilt besonders dann, wenn die Anwendung fachlich kaum noch weiterentwickelt wird, viele Sonderlösungen benötigt oder nur durch technische Umwege cloudfähig gemacht werden kann.

Die zentrale Abwägung lautet:

• Ist die lokale Abhängigkeit fachlich notwendig?

• Gibt es regulatorische oder technische Gründe für den lokalen Betrieb?

• Ist eine Modernisierung wirtschaftlich sinnvoller?

• Entsteht durch die Anbindung dauerhaft Komplexität?

• Wird ein Altsystem nur erhalten, weil es historisch vorhanden ist?

• Gibt es eine realistische Roadmap zur Ablösung?

Diese Entscheidung gehört in die Architekturphase. Im laufenden Betrieb wird sie meist zu spät getroffen, weil die Anbindung dann bereits existiert und produktiv genutzt wird.

Prüffragen für hybride Infrastruktur

Eine bestehende hybride Umgebung lässt sich mit wenigen Fragen grob bewerten:

• Welche lokalen Systeme sind aus klaren Anforderungen lokal?

• Welche lokalen Systeme sind nur aus Gewohnheit lokal?

• Gibt es ein dokumentiertes Zielbild für Identität?

• Ist Entra ID sauber in die lokale Identitätsstruktur eingebunden?

• Sind Netzwerkverbindungen geplant oder historisch gewachsen?

• Gibt es klare Datenflüsse zwischen lokal und Cloud?

• Werden lokale Systeme zentral überwacht?

• Sind Security, Backup und Wiederherstellung durchgängig betrachtet?

• Ist dokumentiert, welche Anwendungen abgelöst werden sollen?

• Gibt es eine klare Entscheidung zwischen Anbindung, Modernisierung und Migration?

Wenn diese Fragen nicht beantwortet werden können, ist die hybride Umgebung wahrscheinlich nicht bewusst entworfen, sondern über Zeit entstanden.

Fazit

Hybride Infrastruktur ist kein halber Schritt in die Cloud. Sie kann eine sinnvolle und notwendige Architektur sein.Voraussetzung ist, dass lokale Systeme nicht aus Gewohnheit erhalten bleiben, sondern aufgrund konkreter Anforderungen. Identität, Netzwerk, Daten, Betrieb und Sicherheit müssen dabei gemeinsam geplant werden.

Die eigentliche Frage lautet nicht: Cloud oder On Premises? Die bessere Frage lautet: Welche Workloads gehören wohin, aus welchem Grund, und wie wird die gesamte Umgebung kontrolliert betrieben?

Hybrid wird dann zum Problem, wenn es ungeplant entsteht. Als bewusste Architekturentscheidung kann es genau die richtige Lösung sein.