Hyperscaler oder Hylascaler? Wie aus simplen Services teure Plattform-Abhängigkeiten werden.

Cloud-Infrastruktur hat ihre Berechtigung. Skalierbarkeit, Automatisierung, Globalisierung von IT-Ressourcen sind längst Standard. Technisch liefern die großen Plattformanbieter — AWS, Google Cloud, Azure — ohne Zweifel stabile Basistechnologie.

Aber das Problem fängt dort an, wo Kunden glauben, sie würden sich nur Infrastruktur einkaufen. In Wahrheit kaufen sie Geschäftsmodelle. Mit unserer Enterprise Cloud und Private Cloud bieten wir Alternativen, die Ihnen die volle Kontrolle über Ihre Infrastruktur zurückgeben.

Der Vergleich: Cloud verkauft wie ein Hyla-Staubsauger

Der Hyperscaler verkauft nicht das, was der Kunde eigentlich braucht. Der Kunde will einen Staubsauger. Der Hyperscaler verkauft das gesamte Ökosystem drumherum: Wasserfiltersystem, Luftbefeuchter, Allergiker-Zertifikate, Lifetime-Servicevertrag, Schulungsprogramme, Service-Inspektionen.

Am Anfang klingt das alles sinnvoll. Am Ende hängt der Kunde an einem System, das teuer, komplex und kaum mehr austauschbar ist.

Genau so läuft es in der Cloud.

Das einfache Beispiel: AWS SQS vs. Redis

Eine Applikation braucht Messaging. Kein Rocket Science. Kurze Queues, Messages rein, Messages raus, acknowledge, fertig. Redis Streams könnte das locker stemmen: minimaler Overhead, stabil, performant, einfach zu betreiben.

Aber der Hyperscaler bietet SQS. Klingt sauber, klingt schlank, klingt managed. Und plötzlich steckt man mitten in einem komplettem Service-Ökosystem: Visibility Timeouts, Dead Letter Queues, Redrive Policies, IAM-Rollen, API-Quotas, komplexes Pricing pro 1M Requests, Traffic-Kosten, Multi-Region-Replication, Vendor-spezifische SDKs, Monitoring-Integrationen.

Was als “Managed Service” verkauft wird, ist längst kein einfacher Queue mehr. Es ist eine vollständige Plattformabhängigkeit. Jeder zusätzliche Service, der angedockt wird, zementiert die Architektur weiter ins AWS-Modell.

Technisch hätte Redis diesen Anwendungsfall innerhalb von Minuten gelöst. Transparent, selbst betreibbar, ohne Plattformbindung, ohne versteckte Zusatzkosten. Aber die Entscheidung für SQS ist bequem. Und genau darauf ist das Verkaufsmodell der Hyperscaler gebaut.

Zweites Beispiel: Amazon RDS vs. PostgreSQL / MariaDB

Datenbanken sind ein noch klareres Beispiel. Fast jede Anwendung braucht eine relationale Datenbank. PostgreSQL, MariaDB, MySQL — alle seit Jahren stabil, erprobt, performant, open-source-basiert, von unzähligen Providern betreibbar.

Stattdessen greifen viele blind zu Amazon RDS. Wieder: klingt komfortabel, managed, hochverfügbar, skalierbar. Und wieder greift das gleiche Muster: Parametergruppen, Backup-Policies, Lizenzmodelle, IOPS-Pricing, Storage-Tiers, Multi-AZ Failover, Monitoring-Abhängigkeiten, proprietäre API-Erweiterungen.

Was technisch ein Standardprodukt ist, wird durch das Betriebsmodell in einen Vendor-Lock-in gezogen, aus dem es später sehr teuer wird auszubrechen. Jeder Admin, der RDS einmal produktiv migrieren musste, weiß, wie tief diese Abhängigkeiten greifen.

Der zentrale Punkt: Es geht nicht um die Technologie

Technisch liefern AWS & Co. solide Plattformen. Aber das Geschäftsmodell der Hyperscaler basiert nicht auf Technologie — es basiert auf Plattformbindung.

Der Einstieg ist billig. Der Exit ist teuer. Die API ist bequem. Die Architektur wird unflexibel. Der Betrieb ist komfortabel. Die Verantwortung wandert vollständig zum Provider.

Der Punkt ist nicht, dass man diese Services nicht nutzen sollte. Es geht darum, genau zu wissen, wann man sie braucht — und wann man sich durch reine Bequemlichkeit in einen Pfad manövriert, der die eigene Unabhängigkeit langfristig massiv einschränkt.

Cloud ist kein Infrastrukturthema. Cloud ist ein Geschäftsmodell.

Fazit: Kontrolle bleibt Architekturentscheidung

Die Frage ist nie, ob Redis gegen SQS gewinnt, oder ob PostgreSQL gegen RDS besser performt. Die Frage ist: Wer kontrolliert das System?

• Wer kann Recovery unabhängig fahren?
• Wer kann Migration realistisch planen?
• Wer bestimmt, wie Preise sich entwickeln?
• Wer kontrolliert API-Kompatibilität?

Mit unserer Enterprise Cloud und Kubernetes-Plattform bieten wir Ihnen die Möglichkeit, diese Kontrolle zu behalten. Hyperscaler verkaufen vollständige Geschäftsmodelle, keine Infrastruktur-Komponenten. Und wer als Softwareanbieter, SaaS-Betreiber oder Systemarchitekt nicht sauber trennt, wo er Plattformdienste braucht und wo nicht, wird diese Rechnung später teuer bezahlen.

Technisch lösen sich viele Probleme auch ohne Cloud-Paketangebote. Aber dann eben ohne den Staubsauger-Vertreter, der nebenbei noch den Lifetime-Wartungsvertrag unterschieben lässt.