Microcloud: Der Weg zur eigenen unabhängigen Cloud
Daten gelten längst als zentrale Ressource fast aller Unternehmen. Sie steuern Prozesse, bilden die eigene Geschäftslogik ab und entscheiden zunehmend darüber, wie wettbewerbsfähig ein Unternehmen ist. Umso wichtiger ist die Frage, wer die Kontrolle über die Infrastruktur tatsächlich behält und wie flexibel diese auf die eigenen Bedürfnisse angepasst werden kann.
In vielen Fällen kann statt des Auslagerns der Verantwortung über die geschäftskritische Infrastruktur die eigene Microcloud eine sinnvolle Alternative darstellen.
Dieser Artikel zeigt, welche Vorteile eine Microcloud gegenüber klassischen Public-Cloud-Modellen bieten kann, welche Anforderungen eine solche Plattform erfüllen muss und welche Herausforderungen beim Aufbau und Betrieb entstehen. Ausgehend von typischen Problemen heutiger Hyperscaler-Modelle wird Schritt für Schritt hergeleitet, welche architektonischen Entscheidungen für eine eigene Lösung relevant sind und mit welchen Technologien sie sich umsetzen lassen.
- Welche Probleme Unternehmen heute tatsächlich lösen müssen
- Kontrolle und Abhängigkeit
- Wirtschaftliche Planbarkeit
- Compliance
- Motivation
- Der Tech Stack – was brauchen Sie für eine eigene Cloud?
- Die Webschicht
- Die Netzwerk-Schicht
- Die Management-Schicht
- Infrastructure as Code – Reproduzierbarkeit als Architekturprinzip
- Die hybride Architektur
- Flexibilität und Kreativität im Plattform-Team
- Ausblick: Zukunft von Hybrid- und On-Prem-Strategien
Welche Probleme Unternehmen heute tatsächlich lösen müssen
Die Entscheidung für Public-Cloud-Angebote fällt in vielen Unternehmen zunächst aus guten Gründen. Neue Umgebungen lassen sich schnell bereitstellen, Ressourcen flexibel skalieren und viele Betriebsaufgaben an externe Anbieter auslagern. Erst mit wachsender Nutzung treten jedoch oft neue Anforderungen in den Vordergrund, die in der frühen Projektphase noch kaum sichtbar waren: wachsende technische Abhängigkeiten, schwer kalkulierbare Kosten, regulatorische Fragen und die grundsätzliche Frage, wie viel Kontrolle über geschäftskritische Infrastruktur im Unternehmen zukünftig verbleiben soll.
Es lohnt sich bereits früh, eine Diskussion nicht als Gegenüberstellung von Cloud und On-Premises zu führen, sondern entlang der Probleme, die Unternehmen aktuell und in der Zukunft lösen müssen. Und wie sich strategisch positioniert werden soll.
Kontrolle und Abhängigkeit
Viele Plattformentscheidungen beginnen anfangs pragmatisch und entwickeln erst im laufenden Betrieb ihre langfristig erhoffte Wirkung. Große kommerzielle Cloudanbieter vereinfachen den Einstieg, erhöhen aber zugleich die Bindung an den gewählten Anbieter. Je stärker Anwendungen und Prozesse an einzelne Dienste oder Schnittstellen eines bestimmten Ökosystems gebunden werden, desto aufwendiger kann ein späterer Wechsel vom Anbieter werden. Dieses entstehende Risiko wird auch als Vendor Lock-in bezeichnet. Mittlerweile wird diese Problematik auch auf europäischer Ebene regulatorisch adressiert. Der EU Data Act soll den Wechsel zwischen den Cloudanbietern erleichtern und sowohl technische als auch wirtschaftliche Hürden reduzieren [1].
Damit entsteht nicht nur eine technische, sondern auch eine organisatorische Abhängigkeit. Kritische Teile der eigenen Infrastruktur liegen außerhalb des direkten Einflussbereichs, während interne Teams ihre Prozesse zunehmend an externen Plattformvorgaben ausrichten.
Die Frage ist deshalb nicht nur, wo Workloads betrieben werden, sondern auch, wie offen künftige Wechseloptionen tatsächlich bleiben. Ziel ist eine reproduzierbare Infrastruktur mit offenen Standards und Flexibilität, sollte sich das Unternehmen architektonisch anders ausrichten wollen.
Wirtschaftliche Planbarkeit
Insbesondere zu Beginn von Projekten oder bei MVPs kann ein schneller Einstieg mit der Public Cloud wirtschaftlich attraktiv erscheinen. Anfangsinvestitionen in Hardware entfallen ganz und Ressourcen können bedarfsgerecht genutzt werden. Neben der reinen Rechenleistung fallen je nach Plattform dann jedoch bei der Skalierung weitere Kosten für Traffic, Storage, Managed Services, hohe Verfügbarkeit, Backups oder die Datenübertragung an.
Mit steigender Nutzung der Public Cloud wird die wirtschaftliche Planung zu einer eigenen Aufgabe. In der Flexera-State-of-the-Cloud-Studie aus dem Jahr 2025 bezeichneten 84 Prozent der befragten Organisationen das Management der eigenen Cloudausgaben als eine der zentralen Herausforderungen [2]. Für Unternehmen wird damit nicht nur die Höhe der Kosten immer relevanter, sondern insbesondere auch deren Transparenz und Vorhersehbarkeit.
Mit der Microcloud entsteht eine Infrastruktur, welche sich wirtschaftlich vorhersehbar kalkulieren lässt und technische Entscheidungen nicht dauerhaft an die Preismechanik eines externen Anbieters bindet.
Compliance
Neben Kosten und Abhängigkeiten rückt zunehmend die Frage in den Vordergrund, wo Daten liegen, wie sie verarbeitet werden und unter wessen Governance dies geschieht. Für ein Unternehmen ist Datenschutz aufgrund der europäischen Regulatorik insbesondere im B2B-Umfeld Teil ihrer betrieblichen und vertraglichen Verantwortung. Durch das Accountability-Prinzip der DSGVO bleibt jeder Verantwortliche verpflichtet, geeignete technische und organisatorische Maßnahmen umzusetzen und die Einhaltung der Datenschutzanforderungen nachweisen zu können. Dies gilt grundsätzlich auch beim Einsatz externer Auftragsverarbeiter [3].
Insbesondere bei sensiblen Daten, geschäftskritischem Code, internen Wissensbeständen oder regulierten Prozessen ist nicht nur die Verfügbarkeit eines Dienstes entscheidend, sondern auch, wie die Daten abgesichert werden.
Das Ziel ist daher nicht maximale Isolation, sondern die kontrollierte Datenverarbeitung sowie die Fähigkeit, bei externen Änderungen oder veränderten eigenen Anforderungen flexibel reagieren, Entscheidungen anpassen und bei Bedarf auf eine bessere Lösung migrieren zu können. Eine unternehmenseigene Microcloud oder eine hybride Lösung kann dabei die Datensouveränität stärken. Mit dem EU Data Act wird der Wechsel zwischen Datenverarbeitungsdiensten ausdrücklich adressiert. Damit wird eine architektonische Frage zunehmend auch zu einem regulatorisch relevanten Thema [1].
Motivation
Die Diskussion über Infrastruktur wird jedoch zu Teilen auch schnell polarisiert geführt. In der Praxis ist eine reine Gegenüberstellung oft zu grob. Sie blendet aus, dass Unternehmen sehr unterschiedliche Anforderungen an Kontrolle, Skalierung, Compliance im laufenden Betrieb haben.
Die eigene Cloud als On-Premise-Lösung kann langfristig sehr sinnvoll sein. Wichtig ist, sich bewusst zu sein, welche Teile der Infrastruktur unter der eigenen Kontrolle stehen sollten, welche Anforderungen an Portabilität und Governance bestehen und welche Komponenten dann ggf. zusätzlich extern in einem hybriden Modell bezogen werden können. Und auch hier gibt es von europäischen Anbietern Möglichkeiten, Dienstleistungen zu nutzen, welche einen stabilen Rahmen mit guter Compliance bieten.
Aus diesen Problemfeldern ergibt sich die zentrale Anforderung an eine moderne Microcloud: Sie muss nicht nur laufende Anwendungen betreiben, sondern Kontrolle, Planbarkeit, Datensouveränität und zuverlässige Betriebsfähigkeit in einer tragfähigen Architektur zusammenführen.
Der Tech Stack: was brauchen Sie für eine eigene Cloud?
Die Anforderungen an eine eigene oder hybride Microcloud reichen von Verfügbarkeit und Skalierbarkeit bis hin zur Sicherheit, Datensouveränität und zu einem zuverlässigen Betrieb. Diese und individuell abweichende Anforderungen lassen sich nicht durch ein einzelnes Werkzeug abdecken. Entscheidend ist, wie die Architektur aufgebaut ist und wie klar sich Verantwortung innerhalb dieser Architektur aufteilen lässt.
Ein praktikabler Ansatz ist ein Schichtenmodell, welches die Architektur der Microcloud entlang eines Outside-In-Prinzips beschreibt. Dabei wird die Infrastruktur von außen nach innen betrachtet. Vom externen Zugriff über die Verteilung und Ausführung von Anwendungen bis hin zu den Komponenten, die den dauerhaften Betrieb in den tieferen Schichten absichern. Jede dieser drei Ebenen adressiert eigene Probleme und erfüllt eine klar abgegrenzte Aufgabe.
In der hier beschriebenen Architektur lassen sich drei Ebenen unterscheiden:
- Die Webschicht regelt den externen Zugriff und sichert das Cluster von außen ab.
- Die Netzwerk- und Orchestrierungsschicht verteilt und verwaltet die benötigten Instanzen.
- Die Management-Schicht sichert Governance, Sichtbarkeit und Persistenz im laufenden Betrieb ab.
Diese Trennung ist bewusst gewählt. Sie verhindert, dass Verfügbarkeit, Sicherheit, Routing, Storage und operative Kontrolle in einer unübersichtlichen Gesamtschicht vermischt werden. In dieser Architektur kann für jede Ebene klar benannt werden, welches Problem diese löst. Auf dieser Entscheidungsgrundlage kann die Wahl der zu nutzenden Tools getroffen werden.
Beginnen wir mit der äußersten Schicht der Architektur, dem Punkt, an dem der Traffic unser Cluster erreicht.
Die Webschicht
Die Webschicht ist der äußerste Rand der Plattform und damit ein besonders kritischer Teil der Architektur. Hier trifft externer Traffic zuerst auf die eigene Cloud. An dieser Stelle entstehen oft die ersten Sicherheitsrisiken. Fehlentscheidungen können dazu führen, dass das System eingeschränkt erreichbar oder unnötig angreifbar wird. Besonders sensibel sind DNS, öffentliche Einstiegspunkte wie API-Schnittstellen und die Lastverteilung auf die erreichbaren Instanzen. Werden diese Komponenten nicht redundant angelegt, entstehen schnell sogenannte Single Points of Failure, also Schnittstellen, welche durch einen gezielten Angriff oder eine Fehlkonfiguration ganze oder große Teile des Systems nur noch teilweise oder gar nicht erreichbar machen. Ziel der Webschicht ist also High Availability by Design.
Typische Maßnahmen beginnen bei der Erreichbarkeit. Redundante DNS-Strategien oder Floating-IP-Konzepte helfen dabei, den Einstieg in die Plattform auch bei Ausfällen einzelner Komponenten verfügbar zu halten. Um solchen Ausfällen entgegenzuwirken, kann eine Floating IP genutzt werden, also eine öffentliche, statische IPv4-Adresse in der Cloud, die flexibel zwischen Instanzen (z. B. Servern, Loadbalancern) umgeschaltet werden kann, ohne die Netzwerkkonfiguration anpassen zu müssen. Eine weitere Möglichkeit sind Multi-IP-DNS-Records.
Ergänzend sorgt Loadbalancing auf den unteren Netzwerkschichten dafür, Anfragen auf mehrere Systeme zu verteilen und den äußeren Zugriff belastbar aufzubauen, was beispielsweise mithilfe quelloffener Software wie Nginx oder HAProxy umgesetzt werden kann.
Zu empfehlen ist ebenfalls die Integration durch ein CDN wie Cloudflare. Diese Lösung kann dazu beitragen, dass schadhafte Angriffe, z. B. durch Bots, bereits abgefangen werden können, bevor diese das Cluster erreichen [4]. Der schädliche Traffic sollte also möglichst weit vor den eigentlichen Workloads gestoppt werden. Wahlweise kann selbstverständlich ein anderer Servicedienstleister mit integrierter Web Application Firewall gewählt werden.
Neben Cloudflare gibt es auch europäische Alternativen wie BunnyCDN. Je nach Architektur, Standortanforderungen, Vertragsgestaltung und Datenflüssen kann die Wahl eines europäischen Anbieters für Unternehmen eine relevante Option innerhalb ihrer Datenschutz- und Souveränitätsstrategie darstellen. So werden auch hier gleichzeitig grundlegende Schutzmechanismen wie DDoS Mitigation, Rate Limiting und eine WAF bereitgestellt [5].
Hinzu kommt die verschlüsselte Kommunikation. Öffentliche Endpunkte sollten konsequent per TLS abgesichert werden. Dafür braucht es nicht nur Zertifikate, sondern auch einen verlässlichen Prozess für Ausstellung, Erneuerung und Einbindung. Automatisierte Zertifikatsverwaltung ist deshalb ein zentraler Bestandteil dieser Schicht. Damit also die Endpunkte der Anwendung und die Verbindung zum Cluster verschlüsselt sind, kann beispielsweise Let’s Encrypt SSL verwendet werden.
Die Netzwerk-Schicht
Sobald Anfragen die Webschicht passiert haben, müssen sie im Cluster korrekt an die passenden Instanzen weitergeleitet werden. Gleichzeitig müssen Anwendungen so betrieben werden, dass sie auch unter Last, bei Updates oder beim Ausfall einzelner Komponenten stabil weiterlaufen. Genau hier liegt die Aufgabe der Netzwerk-Schicht. Diese sorgt dafür, dass Workloads verteilt, skaliert und im Fehlerfall neu gestartet werden können, ohne dass der Betrieb unnötig fragil wird.
Für diese Anforderungen hat sich weitgehend Kubernetes als technischer de facto Standard für die Orchestrierung von containerisierten Anwendungen etabliert. Im CNCF Annual Cloud Native Survey 2025 gaben 82 Prozent der befragten Nutzer an, Kubernetes produktiv einzusetzen [6].
Kubernetes verwaltet containerisierte Anwendungen über mehrere Knoten hinweg, verteilt Instanzen auf verfügbare Ressourcen, ersetzt fehlerhafte Pods automatisch und unterstützt schrittweise Rollouts im laufenden Betrieb. Dadurch entsteht eine Plattform, auf der Anwendungen nicht nur gestartet, sondern kontrolliert und wiederholbar betrieben werden können. Hier stehen Eigenschaften wie Skalierung und Self Healing als Teil des Betriebsmodells im Vordergrund.
Die Orchestrierungsebene darf jedoch nicht selbst zu einem Risiko werden. Besonders kritisch sind hierbei die Control Plane und der API Server. Werden diese nur einfach betrieben, entsteht ein vermeidbarer Ausfallpunkt in einer Schicht, die eigentlich Stabilität schaffen soll. Deshalb ist eine hochverfügbare Control Plane sinnvoll. Mehrere Control-Plane-Knoten vermeiden einen einzelnen Ausfallpunkt der Steuerungsebene. Für das zugrunde liegende etcd Cluster wird eine ungerade Zahl von Mitgliedern empfohlen, damit ein stabiles Abstimmungsquorum erhalten werden kann [7].
Um Instanzen im Cluster administrativ zu erreichen und sicher konfigurieren zu können, wird ein kontrollierter Netzwerkzugang benötigt. Anstatt diese administrativen Schnittstellen öffentlich und frei zugänglich bereitzustellen, empfehlen wir den Zugriff ausschließlich über ein dediziertes VPN.
Lösungen wie OpenVPN oder WireGuard bieten einen verschlüsselten Tunnel zwischen Administrator und interner Clusterinfrastruktur.
Technisch bedeutet das, der API Server, SSH-Zugänge oder interne Services sind nicht direkt aus dem Internet erreichbar, sondern ausschließlich über das private Overlay-Netzwerk des VPN. Dadurch reduzieren sich die Angriffsflächen signifikant. Firewalls können dann zusätzlich konfiguriert werden, da nur definierte VPN-Endpunkte zugelassen werden können. Zugriffsrechte lassen sich dann ebenfalls einrichten und steuern.
WireGuard bietet dabei eine besonders schlanke und performante Implementierung mit moderner Kryptografie und geringem Overhead [8]. OpenVPN hingegen ist seit Jahren etabliert und in vielen Unternehmensumgebungen tief integriert. Welche Lösung gewählt wird, hängt von bestehenden Betriebsprozessen und Sicherheitsanforderungen ab.
Die Netzwerk-Schicht erfüllt damit mehrere Aufgaben zugleich: Sie verteilt Anfragen innerhalb des Clusters, betreibt Instanzen und macht diese skalierbar, ausfallsicher und schützt die zentrale Steuerungsebene vor unnötiger Exponierung.
Die Management-Schicht
In der Management-Ebene des Clusters stehen die Technologien und Prozesse im Vordergrund, welche über das reine Bereitstellen von Containern und die Zuordnung von Traffic zu diesen hinausgeht. Mit Deployment und Routing allein ist eine Plattform noch nicht produktionsreif, denn der eigentliche Betrieb des Clusters beginnt erst eine Schicht tiefer. Diese Schicht ist Teil der Architektur, welche den dauerhaften Betrieb überhaupt erst kontrollierbar macht.
Im Zentrum dieser Schicht stehen Governance und Lifecycle Management. Entwicklungsteams brauchen einen durchgehend konsistenten Blick auf Konfiguration, Zugriffe, Richtlinien und den Lebenszyklus der laufenden Umgebungen. In diesem Zusammenhang können Tools wie Rancher eingesetzt werden, um Cluster zentral zu verwalten, entsprechende Zugriffsmodelle abzubilden und operative Standards über mehrere Umgebungen konsequent durchzusetzen [9]. Der konkrete Nutzen liegt grundsätzlich eher weniger in der zentralisierten Oberfläche als darin, die operative Komplexität zu verringern.
Ergänzend können verteilte Speicherlösungen wie Ceph eingebunden werden. Ceph stellt Block-, Datei- und Objektspeicher bereit. Für den Objektspeicher kann unter anderem eine S3-kompatible Schnittstelle genutzt werden [10]. Das Tool verteilt die Daten über mehrere Knoten hinweg. Eine Microcloud braucht in dieser Schicht eine Speicherstrategie, die Ausfallsicherheit und Skalierbarkeit zusammenführt. Innerhalb des K8s Clusters übernimmt Rook dann die Rolle des Operators, der Ceph als Cloud Native Storage integriert und automatisiert Storage Pools bereitstellt [10].
Ebenso wichtig ist die Sichtbarkeit des laufenden Betriebs. Ohne belastbares Monitoring bleibt unklar, wie sich Nodes, Pods oder Services unter Last verhalten, wo Engpässe entstehen und sich Fehler im Betrieb ankündigen. Um das Cluster zu überwachen, können Open Source Tools wie Prometheus und Grafana genutzt werden. Prometheus ist ein Monitoringsystem mit integrierter Time-Series-Datenbank und sammelt Metriken aus konfigurierten Targets [11], während Grafana die Daten aufbereitet visualisiert und einen Live-Einblick in den Zustand des Clusters gibt. In Verbindung mit Alarmierungsregeln entsteht daraus eine Möglichkeit, nicht nur akute Störungen zu überblicken, sondern auch Trends sichtbar zu machen. Genau diese Transparenz ist die Voraussetzung für Kapazitätsplanung und die frühzeitige Reaktion auf problematische Entwicklungen im Cluster.
Zusammenfassend bildet diese Schicht das operative Rückgrat des Clusters, indem sie Kontrolle und Resilienz systematisch absichert und sicherstellt, dass das Cluster nicht nur heute funktioniert, sondern auch im laufenden Betrieb kontrollierbar bleibt.
Infrastructure as Code – Reproduzierbarkeit als Architekturprinzip
Ein belastbarer Technologie-Stack ist eine notwendige Grundlage für eine Microcloud. Diese allein genügt jedoch noch nicht. Auch mit geeigneten Komponenten für Routing, Orchestrierung, Storage und Monitoring bleibt eine Plattform schwer beherrschbar, wenn sie manuell aufgebaut und gepflegt wird. Ein Cluster ist also nicht schon deshalb portabel oder kontrollierbar, weil die richtigen Werkzeuge ausgewählt wurden. Entscheidend ist, ob sich seine Zielarchitektur reproduzierbar beschreiben und wiederholt ausrollen lässt.
Wer Infrastruktur langfristig kontrollieren möchte, muss diese deklarativ beschreibbar machen. Genau hier setzt Infrastructure as Code, kurz IaC, an. Statt einzelne Server manuell zu konfigurieren oder Infrastruktur über Weboberflächen zu klicken, wird der gewünschte Zielzustand der gesamten Umgebung in Code definiert und versioniert. Das Grundprinzip ist also nicht das manuelle "Wie", sondern das definierte "Was" der Zielarchitektur.
Eine Möglichkeit ist die Wahl von OpenTofu, einem Open Source Fork von Terraform, der für die deklarative Provisionierung von Infrastruktur entwickelt wurde [12]. Deklarativ bedeutet: Es wird nicht beschrieben, welche einzelnen Schritte nacheinander ausgeführt werden müssen, sondern welcher Zustand am Ende erreicht werden soll. Das Tool setzt eigenständig die notwendigen Änderungen um und führt sie aus. Es versetzt das Cluster in den gewünschten Zielzustand, ohne dass alles einzeln konfiguriert werden muss.
Das zentrale Prinzip ist dabei die Zustandsverwaltung über Statefiles. OpenTofu verwaltet, welche Ressourcen bereits existieren und vergleicht diesen Ist-Zustand mit der vom Entwicklungsteam gewünschten Definition im Code. Änderungen werden automatisiert erkannt und gezielt angewendet. Anschließend werden neue Ressourcen erzeugt, diejenigen, die nicht mehr benötigt werden, entfernt und bestehende angepasst. Abhängigkeiten zwischen einzelnen Modulen werden von OpenTofu berücksichtigt, sodass Ressourcen in der korrekten Reihenfolge erstellt oder gelöscht werden. So lassen sich Abweichungen zwischen gewünschtem und tatsächlichem Zustand systematisch erkennen und kontrolliert beheben.
Dieses Modell unterscheidet sich grundlegend von rein imperativen Ansätzen wie klassischen Shell-Skripten oder Konfigurationsabfolgen. Dort wird das "Wie" beschrieben, also eine Sequenz konkreter Schritte. IaC beschreibt hingegen das "Was" und überlässt die Orchestrierung dem Tool. Das reduziert Komplexität, insbesondere in skalierbaren Cluster-Umgebungen. Zugleich erhöht es die Nachvollziehbarkeit, weil Änderungen planbar, überprüfbar und wiederholbar werden. Damit bleibt Infrastrukturwissen nicht an Personen, Tickets oder Nebenabsprachen gebunden, sondern liegt in einer überprüfbaren Beschreibung der Plattform vor.
Ein weiterer entscheidender Vorteil von IaC liegt in der Versionierbarkeit. Infrastrukturdefinitionen liegen im Git-Repository und werden wie Applikationscode behandelt. Änderungen sind von jedem Entwickler nachvollziehbar, überprüfbar und reproduzierbar. Der Code wird damit zur sogenannten Single Source of Truth. Werden Infrastrukturänderungen konsequent über den versionierten IaC-Prozess durchgeführt, kann das Repository als zentrale Quelle für den gewünschten Infrastrukturzustand dienen. Dokumentation entsteht nicht ausschließlich nachgelagert in Wikis oder Diagrammen, sondern ist integraler Bestandteil der Infrastruktur selbst. Klassische Architekturdokumentation wird damit nicht vollständig ersetzt, aber um eine reproduzierbare und überprüfbare Beschreibung der tatsächlichen Ressourcen ergänzt.
In hybriden Szenarien zeigt sich die strategische Stärke dieses Ansatzes besonders deutlich. Ein Kubernetes-Cluster kann mit derselben Codebasis auf Bare Metal, bei einem europäischen Hoster wie Hetzner, OVHcloud oder in einer Public Cloud aufgebaut werden. Ein Anbieterwechsel wird dadurch nicht trivial, aber nachvollziehbarer und technisch besser vorbereitbar. Providerspezifische Module und Produkte müssen je nach Anbieter weiterhin angepasst werden. Der Lock-in-Effekt wird durch diese Herangehensweise jedoch deutlich reduziert, da die Architektur definiert vorliegt und so grundsätzlich bei verschiedenen Anbietern ausgeführt werden kann. Ohne eine solche standardisierte Beschreibung bleibt Portabilität meist theoretisch. Erst IaC macht die technische Wechseloption realistisch.
IaC durch OpenTofu ist damit kein reines Automatisierungstool, sondern schafft Transparenz, Struktur und ermöglicht es Plattform- oder Entwicklungsteams, Infrastruktur in der Microcloud als reproduzierbare portable Architektur zu gestalten.
Die hybride Architektur
Der technische Wert einer Microcloud zeigt sich nicht nur in der Ausführung einzelner in der Architektur vorhandener Komponenten, sondern in den Optionen, die daraus entstehen, wenn Infrastruktur reproduzierbar deklariert und mit offenen Bausteinen aufgebaut wird. In dem Fall können Plattformteile gezielt dort laufen, wo diese fachlich, regulatorisch oder wirtschaftlich am meisten sinnstiftend sind. Hybrid ist dann das Ergebnis einer bewusst portablen Architektur.
Wir haben selbst die Erfahrung gemacht, dass bestimmte Funktionen bei AWS wirtschaftlich nicht mehr sinnvoll darstellbar waren. Anstatt diese dauerhaft zu akzeptieren, konnten wir einzelne Komponenten gezielt zu einem anderen Anbieter verlagern. Genau hier zeigt sich der Vorteil einer deklarativ beschriebenen Infrastruktur: Die Architektur ist nicht implizit an eine Plattform gebunden, sondern explizit im Code definiert.
Wäre ein Anbieter morgen nicht mehr verfügbar, muss nicht bei null wieder angefangen werden. Die Infrastrukturdefinition liegt versioniert vor und kann in der Theorie, wenn die passenden Schnittstellen vorhanden sind, auf einer anderen Plattform erneut ausgerollt werden. Das bedeutet selbstverständlich nicht, dass ein Wechsel von heute auf morgen geschieht, aber die technische Grundlage ist dann vorhanden. Abhängigkeit entsteht nicht durch Bequemlichkeit, sondern durch fehlende Portabilität. Wer seine Infrastruktur reproduzierbar beschreibt, reduziert genau dieses Risiko.
Darüber hinaus eröffnet dieser Ansatz hybride Szenarien. Bestimmte Systemkomponenten können auf eigener oder angemieteter Hardware betrieben werden, während andere bewusst in einer Public Cloud laufen. Control Plane on Prem, Worker Nodes bei einem europäischen Hoster, spezialisierte Services bei einem Hyperscaler. Flexibilität bedeutet in diesem Kontext nicht, eine öffentliche kommerzielle Cloud grundsätzlich zu vermeiden, sondern Wahlfreiheit zu behalten.
Der Nutzen liegt in konkreten Entscheidungen: mehr Wahlfreiheit bei der Platzierung von Applikationen, geringere Lock-in-Risiken, bessere Kostensteuerung und eine Architektur, die sich an den Anforderungen des Unternehmens orientiert statt an den Grenzen eines einzelnen Anbieters.
Flexibilität und Kreativität im Plattform-Team
Zusammengefasst unter dem Motto "Be your own Vendor" lautet die Frage dann nicht: "Können wir alles selbst hosten?", sondern: "Wo müssen wir die Kontrolle behalten und wo ist es nicht geschäftskritisch?".
Heute arbeiten moderne Plattformteams beispielsweise hybrid mit:
- Private Master + Public Nodes: Kubernetes als Control Plane on-Premises, Worker Nodes bei Bedarf in AWS, Azure oder Hetzner
- Open Source Stack: von Linux über Docker bis hin zu Kubernetes – alles Open Source und auditierbar
- Offene CI/CD: GitLab und Jenkins – die Wahl des Toolings bleibt auch in Zukunft dem Team überlassen.
Der entscheidende Punkt ist nicht, dass Flexibilität grundsätzlich bedeutet, alles von Grund auf selbst entwickeln zu müssen! Vielmehr bedeutet es, dass Abhängigkeiten überhaupt selbstständig gewählt werden können, um sich so auch in Zukunft Optionen für den eigenen Tech Stack offenzuhalten.
Open Source spielt dabei immer eine entscheidende Rolle. Sicherheit ist aufgrund der Offenheit des Quellcodes kein Widerspruch. Kritische Software kann auf Sicherheitslücken geprüft und weiterentwickelt werden.
Dies ist bei Anbietern, welche Closed Source Software bereitstellen, also Software, bei welcher der Quellcode nicht eingesehen werden kann, nicht immer der Fall. Bei einer solchen Entscheidung muss das Vertrauen gegenüber dem externen Anbieter vorausgesetzt werden.
Open Source schafft die Möglichkeit, Quellcode unabhängig einzusehen, zu auditieren und auf Schwachstellen zu untersuchen. Transparenz kann die Bewertung technischer Risiken erleichtern [13]. Wenn eine fundiertere Wahl der Technologie mehr Raum für strategische Entscheidungen lässt, welche neuen Möglichkeiten ergeben sich dann, damit zu arbeiten?
Ausblick: Zukunft von Hybrid- und On-Prem-Strategien
Die zentrale Frage ist heute oft nicht mehr, ob Infrastruktur allein in der Public Cloud oder On-Premises betrieben werden sollte. Entscheidend ist vielmehr, wie viel Kontrolle über geschäftskritische Systeme und Betriebsprozesse im Unternehmen verbleiben soll.
Eine Microcloud ist kein Gegenmodell zur Cloud, sondern ein Ansatz, der einzelne Cloud-Funktionalitäten oder gesamte Systeme gezielt wieder auf eigener oder bewusst gewählter Infrastruktur umsetzt. Der Wert liegt in der Möglichkeit, Verfügbarkeit, Sicherheit, Persistenz und Governance reproduzierbar und kontrolliert aufzubauen.
Der eigentliche Unterschied entsteht dabei nicht allein durch die Technologiewahlen, denn erst das Zusammenspiel aus klarer Architektur, offenen Komponenten und IaC macht eine Plattform selbstständig betreibbar und enthaltene Komponenten langfristig portabel.
Genau daraus ergibt sich je nach Anforderung auch die Möglichkeit für einen hybriden Ansatz: Komponenten können dort eingesetzt und ausgeführt werden, wo sie fachlich, regulatorisch oder wirtschaftlich den meisten Wert stiften.
Wer Anforderungen an Souveränität, Portabilität, Reproduzierbarkeit und kontrollierten Betrieb hat oder aufbauen möchte, der kann Cloud-Funktionalität auch jenseits klassischer Public-Cloud-Modelle umsetzen und Kontrolle über die geschäftskritischen Komponenten zurückgewinnen.
Quellen
- Europäisches Parlament und Rat der Europäischen Union. (2023). Verordnung (EU) 2023/2854 des Europäischen Parlaments und des Rates vom 13. Dezember 2023 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung sowie zur Änderung der Verordnung (EU) 2017/2394 und der Richtlinie (EU) 2020/1828 (Datenverordnung), Kapitel VI (Wechsel zwischen Datenverarbeitungsdiensten), Art. 23–31, insb. Art. 23 und Art. 29 Abs. 1 und 3. EUR-Lex. Abgerufen am 19. August 2026, von https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32023R2854
- Flexera. (2025). 2025 state of the cloud report. Abgerufen am 19. August 2026, von https://info.flexera.com/cm-report-state-of-the-cloud
- Europäische Union. (2016). Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung), Art. 5 Abs. 2, Art. 24, Art. 28. EUR-Lex. Abgerufen am 19. August 2026, von https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679
- Cloudflare. (o. D.). Bot Management documentation. Abgerufen am 19. August 2026, von https://developers.cloudflare.com/bots/
- bunny.net. (o. D.). Bunny Shield documentation. Abgerufen am 19. August 2026, von https://docs.bunny.net/shield
- Cloud Native Computing Foundation. (2025). CNCF annual cloud native survey 2025: The infrastructure of AI's future. Abgerufen am 19. August 2026, von https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/
- Kubernetes Documentation. (o. D.). Creating highly available clusters with kubeadm. Abgerufen am 19. August 2026, von https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/; Operating etcd clusters for Kubernetes. Abgerufen am 19. August 2026, von https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/
- Donenfeld, J. A. (2020). WireGuard: Next generation kernel network tunnel. Abgerufen am 19. August 2026, von https://www.wireguard.com/papers/wireguard.pdf
- SUSE. (o. D.). Rancher | SUSE Edge Documentation. Abgerufen am 19. August 2026, von https://documentation.suse.com/suse-edge/3.5/html/edge/components-rancher.html
- Rook. (o. D.). Rook Ceph documentation. Abgerufen am 19. August 2026, von https://rook.io/docs/rook/latest-release/Getting-Started/intro/
- Prometheus & Grafana Labs. (o. D.). Prometheus documentation. Abgerufen am 19. August 2026, von https://prometheus.io/docs/; Grafana documentation. Abgerufen am 19. August 2026, von https://grafana.com/docs/grafana/latest/
- OpenTofu. (o. D.). OpenTofu documentation. Abgerufen am 19. August 2026, von https://opentofu.org/docs/
- Cybersecurity and Infrastructure Security Agency. (2023). CISA open source software security roadmap. Abgerufen am 19. August 2026, von https://www.cisa.gov/resources-tools/resources/cisa-open-source-software-security-roadmap
