Von einem All-In-One-Ansatz zu einer Multi-Cloud-Strategie

Die Quelldateien der Website verwaltete ich früher in einem Git Repository bei AWS CodeCommit. Eine CI/CD-Pipeline auf Basis von AWS CodePipeline erzeugte aus den Quelldateien mit Hilfe von Hugo die Website und speicherte bzw. aktualisierte diese in einem Amazon S3 Bucket.

Amazon CloudFront, ein Content Delivery Network, nutzte diesen Amazon S3 Bucket als Ursprungsserver und stellte die Website global online zum Abruf zur Verfügung. Amazon Route 53 sorgte für die Erreichbarkeit der Website unter ihrem vorgesehenen Domain Namen und AWS Certificate Manager für eine Verschlüsselung des Datenverkehrs mit TLS.

Diese Architektur funktionierte technisch einwandfrei und zufriedenstellend. Sie gewährleistete eine hohe Verfügbarkeit. Änderungen an den Quelldateien in CodeCommit lösten automatisch die Erstellung und Veröffentlichung der aktualisierten Website aus, was den Entwicklungsprozess beschleunigte und Fehler reduzierte. Da insbesondere durch den statischen Charakter der Website keine Server administriert werden mussten, war der Wartungsaufwand gering.

Amazon S3 und CloudFront sind für kleine bis mittlere Websites sehr kosteneffizient. Allerdings können die Kosten bei starkem Datenverkehr ansteigen, besonders für die CloudFront-Datentransfers und HTTPS-Verbindungen. Das gilt insbesondere, wenn sehr viele Assets bereitgestellt werden, also beispielsweise Bilder und Videos.

Wenn man dynamische Inhalte oder interaktive Funktionen benötigt, die auf serverseitigen Anwendungen und Datenbanken basieren, ist es bei diesem Ansatz fast unumgänglich, das alles auf Basis von Diensten von Amazon Web Services umzusetzen. Das ist zwar relativ komfortabel, preislich befindet man sich hier aber im Premium-Segment, und das ist ein Luxus, den sich mein kleines Unternehmen nicht leisten möchte.

Gerade beim Datentransfer kann AWS sehr teuer werden, was eine Multi-Cloud-Lösung sehr teuer machen kann, auch wenn diese technologisch prinzipiell machbar ist. Durch hohe Kosten für den Datentransfer entsteht wirtschaftlich ein starker Vendor Lock-In, ein starker wirtschaftlicher Anreiz, vor allem Dienste von AWS zu nutzen und damit also eine starke Abhängigkeit von AWS und somit von der Strategie von AWS.

Das Content Delivery Network von Amazon CloudFront habe ich daher durch Cloudflare Cache/CDN ersetzt, das sehr leistungsfähig und vergleichsweise kostengünstig ist und das aufgrund von Preispolitik und Technologie sehr offen für eine Multi-Cloud-Strategie ist, was die Abhängigkeit von einem einzelnen Cloud Anbieter reduziert.

Amazon Route 53 habe ich teilweise durch Cloudflare DNS ersetzt und verwende nun beide Dienste. Für die Verschlüsselung des Datenverkehrs verwende ich teilweise Cloudflare SSL/TLS und teilweise Let’s Encrypt. Unabhängig davon verwende ich weiterhin einige andere Dienste von Amazon Web Services.

Die Website, einige serverseitigen Anwendungen und PostgreSQL Datenbanken habe ich in einen Kubernetes Cluster migriert. Eine Zeitlang hatte ich die Linode Kubernetes Engine von Akamai als Managed Service verwendet, bin dann aber nach langer Evaluation von Kubernetes-Distributionen und -Diensten dazu übergegangen, selbst einen Kubernetes Cluster auf Basis von K3S in der Hetzner Cloud zu installieren und zu betreiben. Der aktuelle Tech Stack (nur) der Website ist in diesem Beitrag beschrieben.

Durch die Nutzung mehrerer Cloud-Anbieter vermeide ich, wirtschaftlich und technologisch zu stark von einem einzigen Anbieter abhängig zu werden. Dies erhöht meine Flexibilität und ermöglicht es, durch eine gezielte Nutzung der preislich günstigsten Angebote Kosten zu sparen. Da jeder Cloud-Anbieter andere Stärken hat, kann ich so außerdem das Beste aus den verschiedenen Angeboten nutzen. Hinzu kommt, dass ich einen hohen Anreiz habe, immer wieder Dienste von Cloud Providern zu evaluieren, wodurch ich Wissen erwerbe, das ich in die Beratung einfließen lassen kann.

Ein solcher Ansatz wird nicht für jedes Unternehmen sinnvoll sein. Die Wahl der richtigen Cloud-Strategie hängt stark davon ab, welche IT-Strategie und welches IT-Personal ein Unternehmen hat. Die Kosten alleine für die Cloud sollte man nicht isoliert betrachten, weil das eine sehr unvollständige Sicht auf die gesamten IT-Kosten bedeuten würde.

Über ein erfolgreiches Projekt zur Migration von Anwendungen und Infrastruktur in Richtung der Cloud zu Amazon Web Services berichte ich in dem Beitrag Migration von Anwendungen einer Versicherung zu Amazon Web Services (AWS).