Verprobung IONOS Cloud – eine Alternative zu AWS und Co?

IONOS – Was ist das?

Durch den Zukauf des Plattform as a Service (PaaS) Providers ProfitBricks vor einigen Jahren hat die 1&1 AG die Marke IONOS Cloud aus der Taufe gehoben und damit den Grundstein gelegt, um über das klassische Domain- & Webhosting in den Cloud-Markt einzusteigen. Bausteine sind virtuelle Server, Speicher und Netzwerkkomponenten. Diese sind Basis für die Neuentwicklung von weiteren spezifischen Cloud-Services. Diese sind analog den Hyperscalern einem ständigen Wandel unterworfen, weswegen hinzugefügt werden muss, dass sich unsere Verprobung auf die jeweils zur Verfügung stehenden Services im Mai und Juni des Jahres 2022 beschränkt.

Welche Services gibt es bei IONOS?

Kern und zugleich Highlight der IONOS Plattform ist der Datacenter Designer (DCD), über den sich Infrastruktur visualisiert aufbauen lässt. Dieser erlaubt mittels simplen Drag-and-Drop das Aufbauen einer eigenen Umgebung und somit das Deployment von Komponenten wie Servern, Storage oder Loadbalancern sowie durch Verbindung zwischen diesen Komponenten das Ziehen von Netzwerk-Routen und die Konfiguration von Firewalls. Auch tiefergehende Konfigurationen wie Skalierung, IP-Assignment oder starten / stoppen von einzelnen VMs sind möglich. 

Wir haben beim Aufbau unserer eigenen Infrastruktur für unsere Beispielapplikation jedoch den DCD nicht genutzt, sondern die Nutzung des IONOS Terraform Providers vorgezogen. Eine vollautomatisierte Bereitstellung speziell für größere und komplexere Umgebungen wie wir sie häufig im Konzernumfeld vorfinden, wird durch manuelles Erstellen (“ClickOps”) schnell unübersichtlich, beziehungsweise kaum wartbar. Einer der Hauptgründe weswegen viele Unternehmen den Schritt in die Cloud zu Beginn wagen ist jedoch einen derartigen, in der alten Infrastruktur bestehenden Configuration Drift durch einen hohen Grad an Automatisierung abzubauen. Für kleinere Anwendungen oder Umgebungen insbesondere zum schnellen Aufbau einer DEV-Stage zur Vertestung kann der DCD jedoch vorteilhaft zum Einsatz kommen.

Zum Stand unserer Evaluation des Produktangebotes von IONOS standen neben dem DCD die im Folgenden beschriebenen Services zur Verfügung, welche wir verwendet beziehungsweise auf ihre Reife getestet haben. Wo verfügbar haben wir die jeweiligen Terraform Provider angefügt (siehe hierzu auch das Kapitel zu den weichen Bewertungsfaktoren).

Compute-Technologien

IONOS bietet als Grundlage für Compute ein Infrastructure as a Service (IaaS) Produkt genannt “Compute Engine”, welches klassischen VMs entspricht. Diese können mittels Terraform-Provider erstellt werden wie auch mit dem DCD. Hierbei kann zwischen verschiedenen CPU-Architekturen (AMD/Intel, je nach Standortverfügbarkeit) gewählt werden und für diese die Anzahl an Kernen sowie die Menge an RAM festgelegt werden. Zusätzlich kann dazugehöriger Blockspeicher sowohl als HDD als auch in einer SSD-Variante provisioniert werden. 

Aufbauend auf seinen eigenen VMs bietet IONOS mit “Managed Kubernetes” eine Container-Plattform an, welche auf der bekannten Open Source Version von Kubernetes aufsetzt (TF-Provider). Ähnlich wie bei den Hyperscalern muss ein eigener Node Pool konfiguriert werden sowie z.B. dessen Autoscaling oder IP Konfiguration (wenn gewünscht). Zur Integration in CI/CD Pipelines stellt IONOS eigene SDKs bereit.

Netzwerk Funktionalitäten

IONOS bietet zwei verschiedene Arten von Loadbalancern, einen Netzwerkloadbalancer (TF-Provider) sowie einen Applikationsloadbalancer (TF-Provider). Ebenso kann ein eigenes NAT-Gateway deployt werden (TF-Provider).

Funktionen wie ein VPN-Gateway vermissen wir allerdings bisher.

Datenbank und Storage Optionen

Zum Zeitpunkt unserer Verprobung gab es lediglich die Möglichkeit einen Postgres Cluster im Early Access als Managed Service zu konsumieren und mittels Terraform zu deployen. Ein eigenes SDK wurde von IONOS bereitgestellt, um gegen diese Datenbank dann zu implementieren. Seither wird aber auch eine Version der MongoDB als Vertreter der NoSQL Fraktion angeboten.

Als Storage Möglichkeit wird neben Block und SSD-Storage auch ein S3 Object-Storage angeboten. Dieser kann allerdings nicht über Terraform gemanaged werden, sondern muss wenn er für einen Kubernetes Cluster verwendet wird selbst konfiguriert werden, zum Beispiel über etwas wie https://min.io/  

Security Features

IONOS bietet die Möglichkeit mittels einem sehr rudimentären IAM, Zugriffe zu verwalten. Dieses ist allerdings nicht zu vergleichen mit den sehr feingranularen Möglichkeiten wie etwa bei Google Cloud oder AWS. 

Darüber hinaus gibt es keine Features, die wir an den Hyperscalern sehr schätzen, wie z.B. ein Managed Secret Store oder Key Management mit Bring-Your-Own-Key oder EKM Support. Wünscht man solche Funktionalitäten, muss man diese selbst einrichten und betreiben.

Nachtrag: Mittlerweile bietet IONOS auch zwei Produkte im Bereich Netzwerksecurity an. Nämlich eine Art WAF zum Schutz gegen DDoS Angriffe, genannt DDoS Protect, sowie Flow Logs, welche es ermöglichen Netzwerk Traffic zu überwachen. Beide Services sind (noch) nicht per Terraform konfigurierbar.

Pricing und Locations

IONOS nutzt analog den Hyperscalern eine nutzungsabhängige Abrechnung der jeweiligen Infrastruktur. Diese orientiert sich an der Nutzung der jeweiligen RAM und CPU. Beispielhaft hier für einen Kubernetes Cluster mit einer externen IP aus unserer Verprobung:

Auch wie die Hyperscaler bietet IONOS verschiedene Data Center Locations, in Deutschland zum Beispiel in Frankfurt und Berlin:

• Frankfurt am Main, Deutschland
• Berlin, Deutschland
• Logroño, Spanien
• London, UK
• Newark, USA
• Las Vegas, USA

Nachteilig ist hier anzumerken, dass – auch wie bei den Hyperscalern – nicht alle Services in allen Regionen angeboten werden. Bei dem eingeschränkten Angebot hätten wir dies schon erwartet. Ebenfalls gelten verschiedene SLAs für die Verfügbarkeit je Region.

Welche weichen Faktoren sprechen für eine Nutzung?

Infrastructure as Code Support

Wie aus den vorhergehenden Posts auf diesem Blog zu entnehmen ist, sind wir bei Senacor klare Verfechter eines Everything-as-Code Ansatzes und setzen dementsprechend in unseren Cloud-basierten Entwicklungsprojekten auf einen höchstmöglichen Grad an Automatisierung auch bei der Infrastruktur. Für Infrastructure-as-Code (IaC) und automatisierter Bereitstellung hat sich Terraform als Quasi-Standard etabliert. 

Terraform ermöglicht uns, Konfigurationsdateien, die in HCL (Hashicorp Configuration Language) geschrieben sind, in reale Infrastrukturkomponenten wie VMs, Datenbanken o.ä. zu verwandeln. Hauptsächlich wird dies für die großen drei Cloud-Anbieter wie AWS, Azure und Google Cloud Platform angeboten. Allerdings gibt es auch Support für kleinere Anbieter wie zum Beispiel auch IONOS. Terraform erlaubt state-driven Cloud-Platform-Provisioning. Es nutzt dazu eine Abstraktionsschicht (bekannt als Terraform-Provider und Terraform State), um so aus unserem HCL-Code Cloud-Provider-spezifische CRUD-API-Aufrufe abzusetzen und somit konsistent und deterministisch unsere Cloud-Infrastruktur zu erstellen, was uns eine Menge Arbeit und Stress abnimmt.

IONOS unterhält einen eigenen Terraform-Provider, der recht regelmäßig gewartet wird. Mittels diesem können die einzelnen Services von IONOS provisioniert und konfiguriert werden – analog der Bereitstellung bei den Hyperscalern. Auch an einen Updatepfad für die Legacy-Nutzer von ProfitBricks wurde gedacht.  Allerdings lässt die Qualität der Dokumentation manchmal zu wünschen übrig, zum Beispiel wurde ein Feld „storage_size“ als GB dokumentiert, aber am Ende wurde eigentlich ein Wert von MB erwartet. Grundsätzlich bleibt zu sagen, dass IONOS die Zeichen der Zeit verstanden hat und dementsprechend seine Provider aktualisiert und erweitert, jedoch wie das Gesamtangebot von IONOS ist auch der TF Provider noch sehr eingeschränkt im Vergleich mit den Hyperscalern. Auch ein verstärktes Community Involvement ist noch nicht zu beobachten.

Qualität der Dokumentation

Die Dokumentation von IONOS kann unter diesem Link gefunden werden, variiert in ihrer Qualität allerdings stark. Auch hier merkt man, dass die Plattform sich noch in einer Sturm- und Drang-Phase befindet und sich dementsprechend häufig etwas ändert und die Dokumentation im Zweifel nicht mehr aktuell ist oder sogar einzelne Links ins Leere und auf „404er“-Fehler laufen.

Grundsätzlich werden aber einzelne How-Tos und FAQs für die jeweils bereitgestellten Services angeboten. Diese spiegeln allerdings zumeist nur den Stand der darunter liegenden Open Source Produkte wieder.

Community Support

IONOS unterhält eine eigene Community, welche hier zu finden ist. Diese scheint allerdings veraltet, da die letzten Posts mit Fragen oder Tutorials aus dem Jahr 2018 stammen. Allem Anschein nach, wurde diese aus der Zeit von Profitbricks übernommen und nicht weitergepflegt. Auf Stackoverflow der wohl größten Community für Entwickler finden sich ca. 3-4 Fragen pro Monat mit 1-2 Antworten mit dem Tag IONOS. Selten haben diese mehr als 300 Views. Die Community ist also kaum überraschend sehr viel kleiner als bei den Hyperscalern.

Verprobung

Im Rahmen unserer Verprobung hat sich Michael Weilbächer für mehrere Tage daran gemacht eine kleine Beispielapplikation zu deployen. Dazu hat er neben mehreren VMs auch die dafür notwendige Datenbank sowie das Routing zwischen diesen Komponenten angelegt.

Dies war auch insofern erfolgreich, als dass wir unsere Beispielapplikation verfügbar machen konnten und tatsächlich nutzen. Hierbei konnten die meisten Komponenten über Terraform aufgebaut werden, wobei wir einmalig auch den Data Center Designer (DCD) genutzt hatten. Wichtig ist hier aber zu erwähnen, dass wir ein sehr simples Setup aufgebaut haben, aus einem Kubernetes Cluster mit externer IP und einer Postgres-Datenbank zur Persistenz.

Wie bereits bei den harten Faktoren angedeutet, muss hier allerdings viel selbst konfiguriert und eingestellt werden. Convenience Features, wie sie zum Beispiel Google mit ihrem Angebot eines Managed Kubernetes Clusters (GKE) bieten, fehlen.

Fazit / Ausblick

Zum Zeitpunkt unserer Verprobung zeigte sich IONOS noch sehr stark geprägt von der Übernahme von Profitbricks eher als PaaS-Anbieter denn als “richtige” Cloud – sieht man das Kriterium der Verfügbarkeit von Managed Services aus dem ersten Beitrag dieser Blogreihe als Hauptmerkmal für eine Cloud.

Viele Services die bei den großen Drei seit mehreren Jahren zum “Brot-und-Butter”-Geschäft gehören waren bei IONOS gerade im Aufbau (Managed PostgreSQL), oder vergleichsweise sehr rudimentär in ihrer Ausgestaltung (Managed Kubernetes), sodass viel eigenständige Arbeit in Aufbau, Konfiguration und Wartung zu stecken ist. Aufwände, welche einem die Hyperscaler in ihren ausgereifteren Lösungen bereits abnehmen. Insbesondere die fehlenden Features im Bereich Security (kein Secret Manager, fehlende Key Unterstützung für Verschlüsselungen) bedeuten, insbesondere für unsere Einsatzzwecke im Finanz- und Versicherungsbereich, einige Zusatzaufwände. 

Positiv ist hervorzuheben, dass IONOS gute Ansätze zeigt und stetig sein Portfolio – auch an Managed Services – erweitert. Neben der Möglichkeit der bereits erwähnten Managed Postgres gibt es mittlerweile auch eine managed Version der Mongo DB.  Mit der regelmäßigen Erweiterung seines eigenen Terraformproviders zeigt man auch hier, dass man die Zeichen der Zeit erkannt hat und der Community die Möglichkeit zum (voll) automatisierten Aufbau von Umgebungen geben will.

Abschließend bleibt zu sagen, dass IONOS sich in eine gute Richtung bewegt, für unsere Einsätze im Enterprise-Umfeld aber (noch) zu viele Funktionalitäten fehlen, die bei den Hyperscalern bereits out of the box verfügbar sind, so dass sich eine Migration nicht lohnt. Wir werden den Anbieter dennoch im Blick behalten und gegebenenfalls in einem Jahr wieder bewerten, wie er sich weiterentwickelt hat – das Potenzial für einen deutschen Cloud Anbieter ist auf jedenfall vorhanden.