Angenommen, ein mittelständischer Maschinenbauer betreibt seine Kundenportale bei einem großen US-Hyperscaler. Die Anwendungen laufen stabil, aber die Rechnung steigt jedes Jahr, und in der Geschäftsführung wächst die Frage, was eigentlich passiert, wenn man den Anbieter wechseln möchte. Die ehrliche Antwort lautet oft: Es wird teuer. Datenbanken, Warteschlangen und Identitätsdienste sind eng mit den Eigenheiten genau dieser einen Plattform verwoben.

Hier setzt Open Source in der Cloud an. Nicht als Sparmodell, sondern als Bauweise: Wer Infrastruktur auf offenen, weit verbreiteten Werkzeugen aufbaut, kann sie grundsätzlich bei mehreren Anbietern oder im eigenen Rechenzentrum betreiben. Wie die offene Softwarebewegung überhaupt entstand und wovon ihre Hersteller leben, beschreibt unser Beitrag über den Siegeszug von Open Source. Hier geht es um die Praxis: welche Werkzeuge eine Cloud tragen, was sie leisten und wo die Grenzen liegen.

Warum offene Software in der Cloud-Infrastruktur eine Rolle spielt

Fast jede Cloud läuft im Kern auf Open Source. Die virtuellen Maschinen der großen Anbieter laufen überwiegend auf Linux, Container werden mit offenen Werkzeugen gebaut, und Kubernetes ist zum gemeinsamen Nenner für den Betrieb containerisierter Anwendungen geworden. Der Unterschied liegt in der Schicht darüber: Die Hyperscaler verpacken diese Technik in eigene Dienste mit eigenen Schnittstellen.

Für Unternehmen ergibt sich daraus eine Abwägung. Proprietäre Managed Services sind bequem, weil der Anbieter Updates, Ausfallsicherheit und Skalierung übernimmt. Jede dieser Bequemlichkeiten bindet jedoch ein Stück der eigenen Architektur an diesen Anbieter. Fachleute sprechen von Lock-in, also einer Abhängigkeit, die den Wechsel technisch und wirtschaftlich erschwert.

Offene Werkzeuge lösen dieses Problem nicht automatisch. Sie verschieben aber die Grenze: Eine Anwendung, die auf Kubernetes, PostgreSQL und einem S3-kompatiblen Objektspeicher aufbaut, lässt sich mit überschaubarem Aufwand zu einem anderen Anbieter umziehen. Eine Anwendung, die auf ein Dutzend anbieterspezifischer Dienste setzt, eher nicht.

Die Bausteine einer offenen Cloud im Überblick

Eine Cloud-Infrastruktur besteht aus mehreren Schichten. Für jede gibt es etablierte Open-Source-Projekte.

Virtualisierung und Infrastructure as a Service

Ganz unten steht die Frage, wie aus physischen Servern bedarfsgerecht virtuelle Maschinen, Netze und Speicher werden. Diese Ebene heißt Infrastructure as a Service (IaaS).

• OpenStack ist ein Baukasten aus vielen einzelnen Diensten, etwa für Rechenleistung, Netzwerk, Block- und Objektspeicher sowie Identitäten. Viele europäische Cloud-Anbieter und Forschungseinrichtungen betreiben ihre Plattformen damit. OpenStack ist mächtig, aber komplex: Ohne erfahrenes Team ist der Betrieb kaum zu stemmen.
• Apache CloudStack verfolgt ein ähnliches Ziel mit einer kompakteren Architektur und gilt als einfacher aufzusetzen. Es wird unter anderem von Anbietern öffentlicher Clouds eingesetzt.
• Proxmox VE ist keine vollständige Cloud-Plattform, sondern eine Virtualisierungsumgebung. Für viele mittelständische Rechenzentren ist sie aber der pragmatische Einstieg, gerade seit Lizenzänderungen bei VMware viele Firmen nach Alternativen suchen.
• Ceph ist ein verteiltes Speichersystem, das Block-, Datei- und Objektspeicher bereitstellt und häufig zusammen mit OpenStack oder Proxmox eingesetzt wird.

Container und Orchestrierung

Container bündeln eine Anwendung mit allen Abhängigkeiten in ein portables Paket. Kubernetes verteilt diese Container auf viele Server, startet sie bei Ausfällen neu und skaliert sie nach Last. Das Projekt stammt ursprünglich von Google und wird heute unter dem Dach der Cloud Native Computing Foundation (CNCF) weiterentwickelt, einer Stiftung innerhalb der Linux Foundation.

Kubernetes selbst ist nur der Kern. Für den Unternehmensbetrieb kommen Distributionen hinzu, die Sicherheit, Updates und Verwaltung bündeln. Red Hat OpenShift ist ein kommerzielles Produkt auf Kubernetes-Basis, dessen Community-Variante OKD heißt. Rancher von SUSE verwaltet mehrere Kubernetes-Cluster über verschiedene Umgebungen hinweg. Fast alle großen und viele europäische Anbieter bieten zudem Managed Kubernetes an, bei dem der Anbieter die Steuerungsebene betreibt.

Infrastructure as Code

Wer Server, Netze und Firewalls per Mausklick anlegt, kann diese Umgebung kaum reproduzieren. Infrastructure as Code beschreibt die Infrastruktur stattdessen in Textdateien, die versioniert und geprüft werden wie Programmcode.

Lange war Terraform von HashiCorp das Standardwerkzeug dafür. 2023 stellte HashiCorp die Lizenz von der offenen Mozilla Public License auf die Business Source License (BSL) um, die die Nutzung in konkurrierenden Produkten einschränkt. Daraufhin entstand mit OpenTofu eine Abspaltung (ein Fork) unter dem Dach der Linux Foundation, die unter der ursprünglichen offenen Lizenz weitergeführt wird. Für Anwender hat sich im Alltag zunächst wenig geändert, beide Werkzeuge lesen weitgehend dieselben Konfigurationen. Der Fall zeigt aber, dass auch „offene“ Werkzeuge ihre Lizenz ändern können, wenn ein einzelnes Unternehmen die Rechte am Code hält. Für die Konfiguration einzelner Server ist Ansible verbreitet, das ebenfalls quelloffen ist.

Beobachtbarkeit und Betrieb

Eine Cloud, die man nicht beobachten kann, betreibt man im Blindflug. Prometheus sammelt Messwerte wie Auslastung und Antwortzeiten, Grafana stellt sie in Dashboards dar, OpenTelemetry ist ein offener Standard für Metriken, Logs und Traces. Gerade OpenTelemetry ist strategisch interessant: Wer seine Anwendungen damit instrumentiert, kann das Backend für die Auswertung später austauschen, ohne den Code anzufassen.

Digitale Souveränität: mehr als ein politisches Schlagwort

In Deutschland und der EU wird Open Source in der Cloud zunehmend unter dem Begriff digitale Souveränität diskutiert. Gemeint ist die Fähigkeit, selbst zu entscheiden, wo Daten liegen, welche Software sie verarbeitet und wie man im Zweifel den Anbieter wechselt.

Dahinter stehen handfeste Fragen. US-Anbieter unterliegen dem CLOUD Act, der US-Behörden unter bestimmten Bedingungen Zugriff auf Daten erlaubt, auch wenn diese in europäischen Rechenzentren liegen. Ob und wie sich das mit der DSGVO verträgt, ist seit Jahren Gegenstand juristischer Auseinandersetzungen. Für Unternehmen mit sensiblen Daten, etwa im Gesundheitswesen oder in der öffentlichen Verwaltung, ist das ein echtes Auswahlkriterium.

Mehrere Initiativen setzen deshalb auf offene Bausteine:

• Der Sovereign Cloud Stack (SCS) definiert einen offenen, standardisierten Software-Stack auf Basis von OpenStack und Kubernetes, den unterschiedliche Anbieter gleichartig betreiben können. Das Projekt wurde mit Fördergeld des Bundes gestartet.
• openDesk, getragen vom Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS), bündelt quelloffene Büro- und Kollaborationssoftware für Behörden, darunter Nextcloud für Dateien und Element für Chat.
• Der EU Data Act enthält Regeln, die den Wechsel zwischen Cloud-Anbietern erleichtern sollen, unter anderem zu Wechselentgelten und Datenübertragbarkeit.

Hier lohnt ein nüchterner Blick. Open Source ist eine notwendige, aber keine hinreichende Bedingung für Souveränität. Wer OpenStack bei einem Anbieter betreibt, ohne eigene Betriebskompetenz aufzubauen, ist am Ende wieder abhängig, nur von einem anderen Partner. Souverän wird eine Infrastruktur erst, wenn offene Software, offene Schnittstellen und eigenes Wissen zusammenkommen.

Was offene Cloud-Werkzeuge kosten

Das Argument „Open Source spart Lizenzkosten“ stimmt, greift aber zu kurz. Die Kosten verschieben sich:

• Personal: Eine eigene OpenStack- oder Kubernetes-Umgebung braucht Fachleute für Betrieb, Updates und Sicherheit. Diese sind gefragt und entsprechend teuer.
• Support: Viele Unternehmen kaufen kommerziellen Support oder Subskriptionen, etwa für OpenShift, SUSE Rancher oder eine OpenStack-Distribution. Das ist kein Widerspruch zu Open Source, sondern oft der Grund, warum sie sich im Unternehmen überhaupt einsetzen lässt.
• Hardware und Rechenzentrum: Wer selbst betreibt, trägt Strom, Kühlung, Ersatzteile und Redundanz.
• Opportunitätskosten: Zeit, die ein Team mit dem Betrieb von Infrastruktur verbringt, fehlt bei der Entwicklung von Produkten.

Angenommen, ein Webshop mit zehn Entwickler:innen überlegt, Kubernetes komplett selbst zu betreiben. Für diese Größe ist das meist unwirtschaftlich. Sinnvoller ist ein Managed-Kubernetes-Angebot eines europäischen Anbieters: Die Anwendungen bleiben auf offenen Schnittstellen portabel, den Betrieb der Steuerungsebene übernimmt aber der Dienstleister. Erst wenn Größe, Datenschutzanforderungen oder Kosten es rechtfertigen, kommt ein eigener Betrieb infrage.

Eine offene Cloud-Strategie in fünf Schritten

Der Weg zu einer offeneren Infrastruktur muss kein Großprojekt sein. Bewährt hat sich ein schrittweises Vorgehen:

1. Bestandsaufnahme: Welche Anwendungen laufen wo, und auf welche anbieterspezifischen Dienste stützen sie sich? Oft zeigt sich, dass nur wenige Systeme wirklich eng gebunden sind.
2. Kritikalität bewerten: Für welche Daten und Anwendungen ist ein Anbieterwechsel oder Datenstandort wirklich relevant? Nicht jede interne Wiki-Instanz braucht eine Souveränitätsstrategie.
3. Portable Standards festlegen: Container, Kubernetes, PostgreSQL, S3-kompatibler Speicher, OpenTelemetry und Infrastructure as Code als gemeinsame Basis definieren.
4. Betriebsmodell wählen: Selbst betreiben, Managed Service eines europäischen Anbieters oder Hybrid. Diese Entscheidung hängt vor allem vom vorhandenen Team ab.
5. Lizenzen und Governance beobachten: Prüfen, wer die Rechte an einem Werkzeug hält und ob es von einer neutralen Stiftung getragen wird. Projekte unter dem Dach der Linux Foundation, der CNCF oder der Apache Software Foundation gelten als stabiler gegenüber plötzlichen Lizenzwechseln.

Wer eine bestehende Umgebung umziehen möchte, findet Grundlagen zu Vorgehen und Planung bei unserer Beratung zur Cloud-Migration.

Was das für Ihr Unternehmen bedeutet

Open Source ist in der Cloud kein Gegenentwurf zu den großen Anbietern, sondern die Grundlage, auf der auch diese arbeiten. Die eigentliche Entscheidung lautet daher nicht „Open Source oder Hyperscaler“, sondern: An welchen Stellen akzeptieren Sie Bindung im Tausch gegen Bequemlichkeit, und wo bestehen Sie auf Portabilität?

Unsere Einschätzung: Für die meisten mittelständischen Unternehmen lohnt es sich, Anwendungen konsequent auf offene Standards wie Container, Kubernetes und Infrastructure as Code auszurichten, den Betrieb aber zunächst einem Dienstleister zu überlassen. Überschätzt wird dagegen der Gedanke, mit einer eigenen OpenStack-Cloud automatisch Geld zu sparen. Unterschätzt wird, wie viel Freiheit schon entsteht, wenn man bei neuen Projekten auf anbieterspezifische Dienste bewusst verzichtet.

Wer prüfen möchte, welche offenen Werkzeuge zur eigenen Infrastruktur passen und wie sich Lizenzen, Support und Betrieb sinnvoll organisieren lassen, findet Unterstützung bei unserer Beratung und den Seminaren zu Open Source im Unternehmen.

Häufige Fragen zu Open Source in der Cloud

Ist eine Cloud auf Open-Source-Basis sicher genug für Unternehmensdaten?

Die Sicherheit hängt weniger vom Lizenzmodell ab als vom Betrieb. Offener Code lässt sich unabhängig prüfen, und große Projekte wie Kubernetes oder OpenStack haben eigene Prozesse für Sicherheitsmeldungen. Entscheidend sind aber zeitnahe Updates, saubere Konfiguration und Zugriffskontrolle. Eine schlecht gepflegte Open-Source-Cloud ist unsicherer als ein gut betriebener proprietärer Dienst.

Brauchen wir eigene Fachleute für eine Open-Source-Cloud?

Für den Eigenbetrieb ja, und zwar mehrere, damit Urlaub und Krankheit nicht zum Risiko werden. Wer Managed-Angebote nutzt, braucht vor allem Wissen über Container, Kubernetes-Grundlagen und Infrastructure as Code. Dieses Wissen lohnt sich unabhängig vom Anbieter.

Was passiert, wenn ein Werkzeug seine Lizenz ändert?

Bei Projekten mit großer Nutzerbasis entsteht häufig ein Fork, der unter der alten Lizenz weitergeführt wird, wie bei OpenTofu nach dem Lizenzwechsel von Terraform. Ein Restrisiko bleibt. Deshalb ist es sinnvoll, bevorzugt Werkzeuge einzusetzen, die von einer neutralen Stiftung getragen werden und deren Rechte nicht bei einem einzelnen Unternehmen liegen.

Ist Nextcloud eine Open-Source-Cloud?

Nextcloud ist eine Anwendung für Dateiablage und Zusammenarbeit, die man selbst oder bei einem Hoster betreiben kann, also eher eine offene Alternative zu Diensten wie OneDrive oder Google Drive. Mit Cloud-Infrastruktur im Sinne von OpenStack oder Kubernetes hat sie nur insofern zu tun, als sie darauf laufen kann.