In der Welt der Cloud-Services ist eine Migration oft ein gewaltiges Unterfangen, insbesondere wenn eine Infrastruktur mit Anbieter-spezifischen Services aufgebaut und gewachsen ist. Jede Plattform hat ihre Eigenheiten und spezifischen Dienstleistungen, die tief in Anwendungen integriert sein können. Beim sogenannten Vendor Lock-in kann ein Kunde einen genutzten Service oder ein verwendetes Produkt nicht ohne Weiteres durch eine gleichwertige Lösung eines anderen Anbieters austauschen. Das macht den Umzug von einem zum anderen Cloud-Anbieter oft zu einer sehr zeitintensiven Aufgabe, da das Produkt zuerst so umgebaut werden muss, damit es auch auf anderen Plattformen funktionsfähig wird. Bei agsolutions verfolgen wir grundsätzlich den Ansatz, Anbieter-spezifische Services so gut wie möglich zu vermeiden, um einem Vendor Lock-In aus dem Weg zu gehen.
Vor Kurzem haben wir den Wechsel von AWS (Amazon Web Services) zu Exoscale für eine von uns entwickelte Healthcare-Software durchgeführt und dabei wertvolle Einblicke und praktische Erfahrungen gesammelt. Da wir von AWS-spezifischen Cloud-Services für unsere Anwendung Abstand genommen haben, hat sich die Migration von Grund auf als weniger komplex erwiesen. In diesem Artikel teile ich diese Erfahrungen und gehe auf die Herausforderungen, Prozesse und Überlegungen ein, die für eine erfolgreiche Migration erforderlich sind.
Warum von AWS zu Exoscale wechseln?
AWS ist als globaler Cloud-Gigant bekannt und bietet eine breite Palette an Dienstleistungen, allerdings auch mit einem relativ hohen Preis- und Komplexitätsniveau, das für manche KMUs oft überdimensioniert ist. Exoscale hingegen ist ein europäischer Anbieter, der sich auf Datenschutz, Einfachheit und Kosteneffizienz konzentriert. Der Wechsel zu Exoscale kann sich also für Organisationen lohnen, die eine schlankere und DSGVO-konforme Cloud-Infrastruktur suchen.
Daten bleiben in Österreich
Exoscale bietet neben seiner europäischen Ausrichtung auch spezifische Rechenzentren in Österreich, was für lokale Unternehmen und Organisationen erhebliche Vorteile bringt. Die Verfügbarkeit österreichischer Zonen ermöglicht eine Cloud-Infrastruktur, die nahe an der eigenen Organisation liegt und so niedrige Latenzen und hohe Datenverfügbarkeit gewährleistet. Besonders im Hinblick auf die DSGVO ist Exoscale durch die lokal begrenzte Datenhaltung eine attraktive Wahl, da die Einhaltung von Datenschutzstandards und Compliance-Richtlinien einfacher umgesetzt werden kann.
eCard Anbindung
Darüber hinaus unterstützt Exoscale die Anbindung an das österreichische eCard-Netz, was für Einrichtungen im Gesundheitsbereich entscheidend ist. Durch diese nahtlose Anbindung wird u.a. eine sichere und effiziente Kommunikation mit den Cloud-Services der Sozialversicherung ermöglicht, was den Datenaustausch im Gesundheitswesen erleichtert und beschleunigt.
Persönlicher Support
Ein weiterer Vorteil von Exoscale ist der persönliche Support, der Unternehmen direkt zur Seite steht. Statt auf anonyme Support-Tickets und wechselnde Ansprechpartner zurückgreifen zu müssen, bietet Exoscale engagierte Experten, die speziell mit den Anforderungen der Kunden vertraut sind. Dies vereinfacht den Lösungsprozess erheblich, da bei technischen Fragen oder Herausforderungen eine direkte Unterstützung zur Verfügung steht.
Auswahl der Exoscale-Dienste
Welche AWS-Services nutzen wir und welche Alternativen gibt es bei Exoscale? Die Healtcare-Anwendung setzte auf einige, teils AWS-spezifische Dienste. Exoscale bietet zwar nicht die gleiche Bandbreite an Diensten, aber wir konnten alternative und sogar bessere Lösungen finden:
Beanstalk zu Kubernetes
AWS Elastic Beanstalk wurde vor der Migration verwendet, um automatisiert ganze Umgebungen für die Anwendung bereitzustellen. Dabei wurden von Beanstalk EC2-Instanzen, Load-Balancer, Netzwerke, SSL-Zertifikate uvm. verwaltet.
Wir haben uns dazu entschieden Beanstalk mit Kubernetes abzulösen. Jedoch ist der Betrieb von Kubernetes kein einfaches Unterfangen, weshalb wir auf Exoscale SKS setzen, einen vollständig verwalteten Kubernetes-Dienst. Mit SKS können Unternehmen Kubernetes-Cluster einfach aufsetzen, ohne sich um die zugrunde liegende Infrastruktur oder die komplexe Verwaltung von Kubernetes selbst kümmern zu müssen.
Container Registry
Wir benötigten keine Container Registry mit AWS-Beanstalk, da die Anwendung direkt aus dem Code heraus gebaut und bereitgestellt wurde. Um Docker Images für Kubernetes bereitzustellen, verwenden wir die verwaltete Container Registry aus dem Exoscale Marketplace.
RDS zu DBaaS
Die Ablöse von Amazon RDS for PostgreSQL gestaltete sich relativ einfach, da Exoscale einen verwalteten Datenbankservice DBaaS - Managed PostgreSQL bietet.
S3-Storage
Exoscale bietet einen S3-kompatiblen Object Storage, sodass die Migration unserer S3-Daten im Großen und Ganzen problemlos verlief.
DNS und Load Balancing
Anstelle von Route 53 setzen wir auf Exoscale DNS und nutzen von Exoscale verwaltete Load-Balancing-Services, die sich nahtlos in die neue Infrastruktur einfügen.
SES & SNS
Wir verwenden Amazons SES - Simple Email Service und SNS - Simple Notification Service für den Versand von Mails bzw. SMS. Durch die Umstellung auf Exoscale hat sich hier keine Veränderung ergeben. Diese zwei AWS-Services sind weiterhin in Betrieb, da Exoscale (und meiner Meinung nach auch andere Anbieter) keine gleichwertigen Dienste zur Verfügung stellen. Es werden keine personenbezogenen oder sensiblen Daten via Mail oder SMS versendet, daher haben wir uns dazu entschieden, die Services weiterhin zu verwenden.
Monitoring
Für das Monitoring unserer hybriden Cloud-Umgebung, die sowohl AWS-Dienste (SNS und SES) als auch Exoscale umfasst, setzen wir auf Datadog. Diese Lösung bietet eine zentrale Plattform, die nahtlos AWS- und Exoscale-Komponenten integriert und detaillierte Metriken, Logs und Alerts bereitstellt. Datadog vereinfacht das Monitoring hybrider Umgebungen, erleichtert die Fehlerbehebung und unterstützt uns bei der Performance-Optimierung. Es ist festzuhalten, dass zu Datadog keine personenbezogenen oder sensiblen Daten übertragen werden.
Eine Alternative wäre eine Monitoring-Lösung im eigenen Kubernetes-Cluster zu implementieren, die zum Beispiel auf OpenTelemetry, Prometheus, Loki, Tempo und Grafana basiert. Dieser Ansatz erfordert jedoch den Betrieb und die Wartung dieser Tools in Eigenregie. Die Entscheidung für Datadog – oder alternativ Dynatrace bzw. Grafana Cloud – ermöglicht eine schnellere Implementierung und ist weniger wartungsintensiv.
Zero Downtime
Die Migration der PostgreSQL-Datenbank von AWS RDS zu Exoscale ohne Downtime ist durch Logical Replication möglich. Dabei werden Änderungen in der Quell-Datenbank in Echtzeit auf die neue Exoscale PostgreSQL-Instanz repliziert. Sobald alle Daten synchronisiert sind, kann zum Zeitpunkt des Umstiegs ein geplanter, schneller Umschaltvorgang erfolgen, wodurch eine praktisch unterbrechungsfreie Migration möglich wird. Es werden keine zusätzlichen Tools für die Einrichtung der Replikation benötigt, Exoscale DBaaS bietet diesen Service standardmäßig an und dieser kann jederzeit aktiviert werden.
Etwas schwieriger gestaltet sich die Replikation der S3-Daten. Hier kann z.B. ein Cronjob in Kubernetes angelegt werden, der alle paar
Sekunden mithilfe von rclone die Buckets synchronisiert.
Von Klick-Konfiguration zu Code: IaC mit Pulumi
Da die AWS-Infrastruktur ursprünglich über die Console-UI erstellt wurde, fehlte es an Struktur und einer klaren Versionskontrolle. Die Migration zu Exoscale haben wir daher als Gelegenheit genutzt, Infrastructure as Code (IaC) mit Pulumi einzuführen. Mit Pulumi können wir die gesamte Infrastruktur – von Netzwerkressourcen bis hin zu Datenbanken – als Code definieren und verwalten, was Transparenz, Wiederholbarkeit und Nachvollziehbarkeit in unsere Umgebung bringt. Pulumi erlaubt uns zudem, in Sprachen wie TypeScript zu arbeiten, was die Integration in bestehende Entwicklungs-Workflows erleichtert. So behalten wir den Überblick über alle Ressourcen, können Änderungen automatisieren und haben einen robusten, versionierten Code, der die Infrastruktur optimal dokumentiert.
Herausforderungen und Lessons Learned
Eine Migration in dieser Größenordnung bringt immer Herausforderungen mit sich, und hier sind einige der wichtigsten Learnings:
- Planung ist das A und O: Eine detaillierte Migrationsplanung half dabei, unerwartete Probleme zu minimieren und Downtime zu vermeiden.
- Backups: Neue Backups und Disaster-Recovery-Strategien wurden mithilfe von Kubernetes Cronjobs entwickelt, da Exoscale derzeit keine verwalteten Backup-Lösungen (wie z.B. AWS Backup) für S3-Daten bietet.
- S3 Bucket Lifecyle Policy: Exoscale SOS unterstützt mit heutigem Stand keine automatisierte Bucket Lifecycle Policy. Diese Funktionalität musste manuell mit Kubernetes Cronjobs nachgebildet werden.
- Verschlüsselung: Objekte in Exoscale SOS werden standardmäßig unverschlüsselt abgelegt. Als Lösung haben wir Client-seitige Verschlüsselung in die Anwendung eingebaut, d.h. Objekte werden in unserer Anwendung verschlüsselt, bevor sie zu SOS übertragen werden.
Fazit
Die Migration einer kompletten Service-Landschaft von AWS zu Exoscale war eine Herausforderung, aber die Vorteile machen den Aufwand wert: niedrigere Kosten, europäische Datenschutzstandards und Serverstandort Österreich. Jede Cloud-Migration bringt Risiken und Lernprozesse mit sich, doch mit einer sorgfältigen Planung und Tests konnten wir die Migration erfolgreich abschließen und betreiben die Anwendungen jetzt stabil auf Exoscale.
Für Unternehmen, die auf der Suche nach einer kosteneffizienten, datenschutzfreundlichen Alternative zu AWS sind, könnte Exoscale eine hervorragende Wahl darstellen. Wenn Sie Unterstützung oder Beratung für Ihre Cloud-Projekte suchen, stehen wir Ihnen gerne zur Seite – zögern Sie nicht, uns zu kontaktieren!