Multi-Cloud-Bereitstellung im Jahr 2026: Wie Upsun, Fly.io und Render die cloud-Verteilung handhaben

Der Begriff „Multi-Cloud“ wird verwendet, um mindestens drei verschiedene Dinge zu beschreiben, und die Plattformen geben selten an, welche davon sie meinen. Manche Produkte verteilen eine einzelne Anwendung über verschiedene Regionen, um die Latenz zu verringern. Bei anderen kannst du pro Dienst eine Region auswählen, wobei keine Verbindung zwischen den Diensten besteht. Wieder andere ermöglichen es dir, dieselbe Anwendung bei Bedarf unverändert bei einem völlig anderen Cloud-Anbieter bereitzustellen.

Upsun, Fly.io und Render werden in Vergleichsartikeln alle unter „Multi-Cloud“ eingeordnet, lösen aber drei unterschiedliche Probleme. Wenn man sie verwechselt, kommt es vor, dass Teams eine Plattform wählen, die Regionen hervorragend handhabt, aber keinen anderen cloud-Anbieter unterstützt – oder umgekehrt. 

Dieser Beitrag erklärt, was jede dieser Lösungen tatsächlich leistet, wann sie die richtige Wahl ist und wo sie dich enttäuschen wird, wenn du etwas anderes erwartet hast.

Die meisten Multi-Cloud-Probleme sind Probleme der Zersplitterung

Bevor man Plattformen vergleicht, sollte man ein weit verbreitetes Missverständnis ansprechen: dass Multi-Cloud bedeutet, eine Anwendung gleichzeitig bei zwei oder mehr Anbietern laufen zu lassen – etwa AWS und GCP –, wobei der Datenverkehr live zwischen ihnen aufgeteilt wird. 

In der Praxis ist diese Art von Aktiv-Aktiv-Konfiguration selten, teuer und meist nicht das, was tatsächlich benötigt wird. Sie verursacht Latenz zwischen den Regionen, verdoppelt den Überwachungs- und Betriebsaufwand und lässt dich dennoch von den anliegenden anbieterspezifischen Diensten abhängig bleiben.

Die häufigere Realität, vor allem in mittelgroßen und größeren Unternehmen, sieht anders aus: mehrere unterschiedliche Anwendungen, die jeweils bei einem anderen cloud-Anbieter laufen – oft aus Gründen, an die sich derzeit niemand im Unternehmen mehr erinnert. Das CMS der Marketingabteilung läuft bei einem Anbieter. Das Kernprodukt bei einem anderen. Ein durch eine Fusion oder Übernahme gewonnenes Team hat seinen eigenen Stack mitgebracht. Jede dieser Anwendungen hat ihre eigene Deployment-Pipeline, ihr eigenes Runbook und ihren eigenen Audit-Trail. 

Das Problem ist nicht: „Wie kann ich eine App überall ausführen?“, sondern: „Wie kann ich aufhören, fünf verschiedene Betriebshandbücher für fünf verschiedene clouds zu pflegen?“

Drei verschiedene Modelle, jeweils in einem Absatz

• Fly.io ist für echtes Multi-Region-Computing ausgelegt. Es führt deine Anwendung in schlanken virtuellen Maschinen (Firecracker-MicroVMs) aus, die in mehr als 30 Regionen weltweit platziert sind, wobei Anycast-Netzwerk-Routing jeden Nutzer zur nächstgelegenen Maschine leitet. Dies ist eine Single-Provider-Plattform: Alles läuft auf der eigenen Infrastruktur von Fly. Was du verteilst, ist eine einzige Anwendung über verschiedene Regionen hinweg, nicht über verschiedene cloud-Anbieter.
• Render bietet dir die Wahl der Region pro Dienst, aber keine Verbindung zwischen diesen Regionen. Du kannst einen Dienst in Frankfurt und einen anderen in Oregon bereitstellen, aber sie befinden sich in getrennten privaten Netzwerken und können nicht direkt miteinander kommunizieren. Es gibt kein regionenübergreifendes Routing und überhaupt keine cloud-übergreifende Lösung. Die Stärke von Render liegt woanders, und darauf kommen wir noch zu sprechen.
• Upsun verfolgt einen Portabilitätsansatz. Du definierst deine Anwendung einmalig in einer einzigen Konfigurationsdatei und wählst bei der Projekterstellung einen Anbieter und eine Region aus (AWS, Azure, Google Cloud, IBM Cloud oder OVHcloud). Der gleiche Git-gesteuerte Workflow, die gleiche Build-Pipeline und die gleichen Dienstdefinitionen gelten unabhängig davon, welchen Anbieter du ausgewählt hast. Das ist kein automatisiertes Failover zwischen clouds. Es ist die Fähigkeit, konsistent auf dem Anbieter zu laufen, den ein bestimmtes Projekt benötigt, und auf einen anderen zu wechseln oder dort wiederherzustellen, ohne die Anwendung neu zu gestalten.

Direkter Vergleich

1. Fly.io: eine gute Wahl hinsichtlich Latenz, aber nicht für Cloud-Portabilität

Wenn dein Problem tatsächlich lautet: „Nutzer in Tokio und São Paulo benötigen beide schnelle Antwortzeiten von einer Anwendung“, dann ist Fly.io genau dafür gemacht. Ein paar Dinge machen es hier zu einer sinnvollen Wahl:

• Das Anycast-Routing leitet jede Anfrage automatisch an die nächstgelegene funktionierende Region weiter.
• Das Fly-Replay-Muster ermöglicht es dir, eine einzige beschreibbare Datenbank in einer Primärregion zu führen, während Lesezugriffe von regionalen Replikaten bedient werden und Schreibvorgänge bei Bedarf an die Primärregion weitergeleitet werden.
• Mehr Regionen als bei den meisten entwicklerorientierten Plattformen – was wichtig ist, wenn deine Nutzerbasis wirklich global ist und sich nicht auf ein oder zwei Kontinente konzentriert.

Die Nachteile:

• Operative Komplexität. Mit Anycast-Routing und dem „Fly-Replay“-Muster kannst du steuern, wohin der Datenverkehr und die Schreibvorgänge geleitet werden. Allerdings musst du das selbst verwalten, indem du in Regionen, Maschinen und Volumes denkst, anstatt einfach nur zu programmieren und die Plattform entscheiden zu lassen.
• Keine Wahl des Anbieters. Fly.io läuft nur auf seiner eigenen Infrastruktur. Es läuft nicht auf AWS, Azure oder Google Cloud. Wenn du auf einem bestimmten cloud-Anbieter laufen oder zu diesem wechseln musst, ist das mit Fly.io nicht möglich.
• Zuverlässigkeit. Die Zuverlässigkeitsbilanz von Fly.io war bisher durchwachsen. Im Oktober 2024 gab es einen größeren Ausfall, und seitdem kam es zu kleineren Zwischenfällen. Fly hat diesbezüglich offen kommuniziert, und es lohnt sich, diese Vorfälle bei der Planung zu berücksichtigen.

2. Render: einfach und zuverlässig, aber keine Flexibilität über Regionen oder cloud-Anbieter hinweg

Bei Render ging es nie wirklich um die Verteilung. Es geht darum, Reibungsverluste zu beseitigen:

• Git-basierte Deploys, bei denen für gängige Stacks keine Konfigurationsdateien benötigt werden.
• Erstklassige Unterstützung für Webdienste, statische Websites, Hintergrundprozesse, Cron-Jobs sowie verwaltete Postgres- und Redis-Instanzen.
• Integrierte Vorschau-Umgebungen.
• Planbasierte, vorhersehbare Preisgestaltung statt nutzungsabhängiger Abrechnung. Bezahlte Webdienste beginnen bei 7 $ pro Monat, die Standard-Stufe kostet 25 $.

Die Kompromisse:

• Auswahl der Region, aber keine Verbindung zwischen den Regionen. Du kannst einen Dienst in Frankfurt und einen anderen in Oregon hosten, aber sie laufen in völlig getrennten privaten Netzwerken ohne Verbindung zueinander.
• Keine Auswahl an cloud-Anbietern unterhalb der Enterprise-Stufe. Es gibt keine Cross-Cloud-Option, es sei denn, du vereinbarst einen individuellen Enterprise-Vertrag. Render versucht nicht, dies zu verheimlichen.

Es ist eine solide, ehrliche Wahl für Teams, die einen einzigen, verlässlichen Host für eine in sich geschlossene Anwendung suchen. Aber es ist nicht für Multi-Region- oder Multi-Cloud-Architekturen ausgelegt. 

3. Upsun: Portabilität über Anbieter hinweg, aber kein automatisches Failover

Das Modell von Upsun unterscheidet sich von den beiden oben genannten, da es eher das Anbieterproblem als das geografische Problem löst. In der Praxis bedeutet das:

• Eine einzige Konfigurationsdatei (.upsun/config.yaml) definiert die Anwendung, ihre Laufzeiten, ihre Dienste (Datenbanken, Caches, Suche) und wie diese miteinander in Beziehung stehen.
• Die gleiche Datei und der gleiche Workflow werden auf AWS, Azure, Google Cloud, IBM Cloud oder OVHcloud bereitgestellt, je nachdem, welchen Anbieter und welche Region du bei der Projekterstellung auswählst.
• Vorschauumgebungen in der Produktivumgebung: Jeder Branch erhält einen vollständigen Klon des Codes, der Konfiguration und der Produktionsdaten, mit Hooks, um deine eigenen Bereinigungsskripte auszuführen, bevor jemand anderes darauf zugreift.
• Compliance-Zertifizierungen werden konsistent über alle Umgebungen hinweg angewendet, darunter ISO/IEC 27001, SOC 2 Typ 2, PCI DSS Level 1, HIPAA und TX-RAMP – was für regulierte Teams wichtig ist, die unabhängig davon, in welcher Umgebung oder bei welchem Anbieter sich eine Workload befindet, denselben Audit-Status benötigen.

Die Kompromisse:

• Kein automatisches Failover, sondern ein getesteter Wiederherstellungsprozess. Wenn ein Anbieter einen schwerwiegenden Ausfall hat, leitet Upsun den Datenverkehr nicht automatisch um. Stattdessen stellt dein Team dieselbe Konfiguration bei einem neuen Anbieter oder in einer neuen Region wieder bereit, stellt Daten aus backups oder Klonen wieder her und führt die üblichen Umstellungsschritte durch. Ein aktives Live-Failover ist teuer in der Umsetzung und schwer gut zu betreiben, daher löst für die meisten Unternehmen eine schnelle, konsistente Wiederherstellung das eigentliche Problem ohnehin besser.

Wo sich das Portabilitätsmodell von Upsun am meisten auszahlt: beim zuvor in diesem Artikel angesprochenen Problem der Zersplitterung. Wenn dein Unternehmen heute mehrere Anwendungen bei verschiedenen Anbietern betreibt, jede mit ihrer eigenen Pipeline und ihrem eigenen Runbook, liegt der Wert nicht darin, dass eine App überall gleichzeitig läuft. Es geht um einheitliche Tools, einheitliche Sicherheitsstandards und einheitliche Prüfnachweise über diese Zersplitterung hinweg – ohne dass für jeden beteiligten Anbieter separate Konsolen und Prozesse abgeglichen werden müssen.

Die Wahl zwischen Fly.io, Render und Upsun

Entscheide dich für Fly.io, wenn deine Nutzer wirklich weltweit verteilt sind, Latenz eine oberste Produktanforderung ist und du bereit bist, im Gegenzug für diese performance mehr betriebliche Komplexität (Regionen, Maschinen, Volumina) in Kauf zu nehmen.

Entscheide dich für Render, wenn du einen einzigen, vorhersehbaren und reibungslosen Host für eine in sich geschlossene Anwendung suchst und keine regionenübergreifende Vernetzung oder Flexibilität bei den Anbietern benötigst. Es ist nach wie vor eine der einfachsten Möglichkeiten, vom Git-Push zu einem laufenden Dienst zu gelangen.

Entscheide dich für Upsun, wenn du mehrere Anwendungen verwaltest, aus Compliance- oder Beschaffungsgründen die Möglichkeit benötigst, bei einem bestimmten Cloud-Anbieter zu deployen, oder wenn du einheitliche Workflows, Sicherheitsstandards und Disaster Recovery über Umgebungen hinweg wünschst, die derzeit keines der oben genannten Merkmale gemeinsam haben.

Häufig gestellte Fragen (FAQs)

Bedeutet „Multi-Cloud“ immer, dass eine App gleichzeitig auf zwei clouds läuft? 
Nein. Dieses Aktiv-Aktiv-Modell ist nur ein eng gefasstes Muster und selten das richtige. Die meisten Unternehmen, die von einem Multi-Cloud-Problem sprechen, meinen eigentlich die Verwaltung mehrerer separater Anwendungen, die auf verschiedene Anbieter verteilt sind und jeweils ihren eigenen Betriebsaufwand mit sich bringen.

Was bedeutet „Cloud-Portabilität“? 
Cloud-Portabilität bedeutet, dass eine Anwendung zwischen Cloud-Anbietern wechseln kann, ohne neu geschrieben oder von Grund auf neu erstellt werden zu müssen. Upsun erreicht dies, indem die Anwendung in einer standardisierten Konfiguration definiert wird – und nicht mit anbieterspezifischen Tools wie handgeschriebenem Terraform oder CloudFormation. Diese Konfiguration funktioniert bei jedem unterstützten Anbieter auf die gleiche Weise, sodass die Wahl des Anbieters erst zum Zeitpunkt der Bereitstellung getroffen wird und nicht fest in der Anwendung verankert ist.

Kann Fly.io auf AWS oder Azure bereitgestellt werden? 
Nein. Fly.io läuft vollständig auf seiner eigenen Infrastruktur. Seine Multi-Region-Fähigkeit bezieht sich auf die geografische Verteilung innerhalb des Fly-Netzwerks, nicht auf die Wahl des Anbieters.

Unterstützt Render Multi-Region-Bereitstellungen? 
Nur auf der Ebene einzelner Dienste, und diese Regionen teilen sich kein privates Netzwerk. Es gibt kein integriertes regionenübergreifendes Routing oder Failover.

Bietet Upsun ein automatisches Failover, wenn ein cloud-Anbieter ausfällt? 
Nein. Das Modell von Upsun basiert auf einer geplanten, vom Betreiber initiierten Wiederherstellung mithilfe portierbarer Konfigurationen, nicht auf automatisiertem Failover. Da die Anwendung bereits in einer versionsverwalteten Konfiguration definiert ist, bedeutet die Wiederherstellung bei einem anderen Anbieter oder in einer anderen Region, dieselbe Konfiguration erneut bereitzustellen und einen getesteten Prozess auszuführen – und nicht, die Infrastruktur unter Zeitdruck von Grund auf neu aufzubauen.

Bedeutet die Nutzung mehrerer Anbieter mit Upsun, dass man mehrere Tool-Sätze verwalten muss? 
Nein. Der gleiche Git-gesteuerte Workflow, die gleiche Build-Pipeline und die gleichen Service-Definitionen gelten unabhängig davon, bei welchem Anbieter ein bestimmtes Projekt bereitgestellt wird. Ein Team kann beispielsweise eine Anwendung auf AWS und eine andere auf Google Cloud ausführen, um unterschiedliche Anforderungen an den Datenaufbewahrungsort zu erfüllen, ohne für jede Plattform separate Bereitstellungsprozesse oder separates Plattform-Fachwissen pflegen zu müssen.

Welche Plattform eignet sich am besten für eine regulierte Branche mit Anforderungen an den Datenaufbewahrungsort? Upsun ist hier die beste Wahl unter den dreien, da es von Grund auf die Bereitstellung bei einem bestimmten Anbieter und in einer bestimmten Region unterstützt und Compliance-Zertifizierungen konsistent in jeder Umgebung anwendet.