Die schöne neue Welt der Clouddienste. Einfach die gewünschten Maschinen und Services initialisieren. Fertig. Dann noch etwas Fachlogik on top und schon kann man die lästige In-House-IT abschalten oder gar den NoOps-Zustand erreichen, der einem vollständigen Verzicht auf ein dediziertes Betriebsteam entspricht.

„Sie zahlen lediglich für die genutzten (…) Ressourcen, die Sie verwenden, und müssen dabei keine langfristigen Verträge eingehen (…).“ – Zitat eines Cloud Providers. So flexibel und unabhängig war die eigene (sogenannte On-Premises) Infrastruktur nie. Es musste Hardware beschafft, Software gekauft und installiert werden. Systemadministratoren waren meist auf einzelne Komponenten spezialisiert und permanent mit Aufsetzen, Betrieb und Instandhaltung von Lösungen beschäftig. Dazu begab man sich in die Abhängigkeit von Softwarehäusern. Ein enges und auf Dauer teures IT-Korsett. All diese Probleme sollen nun durch Clouddienste gelöst sein. Aber ein gutes, altes Sprichwort sagt: Wo Licht ist, ist auch Schatten. Und auch in diesem Fall ist man gut beraten, die Versprechen und Services einiger Cloud-Anbieter zu hinterfragen, was im folgenden Beitrag angestoßen wird.

Eine klassische On-Premises-IT lässt sich in drei große Kostenbereiche teilen:

• Betrieb (Administration)
• Infrastruktur (Anschaffung und Wartung)
• Lizenzen (Anschaffung und Wartung).

Ist eine Cloudlösung in diesen Bereichen wirklich immer billiger als On-Premises? Ob sie zusätzlich auch noch besser oder schlechter ist, könnte vielfältig diskutiert werden und soll in der weiteren Betrachtung eine untergeordnete Rolle spielen, da sich diese Frage jedes Unternehmen individuell beantworten muss.

Um was geht es aber im Kern beim Cloud-Computing? Heute werden in diesem Kontext zwei Dinge miteinander vermischt, deren separate Betrachtung jedoch essenziell ist, nämlich Managed Service und Cloud-Computing. Die beiden Begriffe werden mittlerweile fast synonym verwendet. Aber genau hier ist eine Differenzierung nötig, um zu vermeiden vom Regen in die Traufe zu geraten. Um die Begrifflichkeiten besser zu verorten, hilft ein Blick auf die folgende Abbildung. Dabei wird klar, dass sich die Welt der Cloud bzw. der hier möglichen Servicemodelle in mindestens drei unterschiedliche Varianten unterteilen lässt (IaaS, PaaS und SaaS).

Ein klassisches Cloud-Computing-Konzept kommt dabei dem sogenannten IaaS wohl am nächsten und reduziert sich auf drei entscheidende Dinge:

• Netzwerk,
• Storage und
• Computing.

Die Grundidee einer solchen Cloud-Strategie sollte dabei eigentlich sein, Teile der IT-Infrastruktur zu flexibilisieren. Also technische IT-Ressourcen nur dann und in dem Umfang zu verwenden und zu bezahlen, wie man sie auch wirklich braucht. Flexibilisierung führt so automatisch zu verbesserter Kosteneffizienz, da ungenutzte Ressourcen auch nicht bezahlt werden müssen. Was aber ganz wichtig ist: Mit – zum Beispiel – der richtigen IaaS-Cloud-Strategie kann eine relativ geringe Abhängigkeit von Cloudprovidern erreicht werden, da die fachliche Administration und der technische Applikationsbetrieb immer noch beim Kunden des Providers liegen. Demnach spart man sich aber auch nur einen Teil der entstehenden Aufwände beziehungsweise Kosten.

Zusätzliche Managed Services wie beispielsweise Datenbanken oder Applikationsschichten können diese Kosten weiter senken. Tendenziell „bezahlt“ man solche Leistungen jedoch mit einer höheren Abhängigkeit vom Cloud Provider. Je mehr spezifische Services eines Anbieters genutzt werden, umso höher ist die Wahrscheinlichkeit, dass man sich in einen nachhaltigen Vendor Lock-in begibt. Ist der Pfad erst einmal eingeschlagen, wird die oben skizzierte Flexibilisierung der IT sukzessive ausgehöhlt. Am Ende des Weges mag es eine stark reduzierte On-Premises-Infrastruktur und nur noch einen kleineren Teil des IT-Teams geben, aber dafür klebt man nun am Fliegenfänger des Cloud-Serviceproviders. Was ursprünglich mal die Flexibilität und Effizienz erhöhen sollte, führt so nicht selten zu einem neuen Problem – einem erheblichen und potenziell auch sehr teuren Vendor Lock-in.

Das Geschäftsmodell der großen Cloud-Anbieter ist in erster Linie eine Einbahnstraße: Rein in die Cloud – dafür gibt es reichlich Migrationshilfen und Tools. Der Weg raus kann sich da schon deutlich schwerer gestalten. In Kombination mit hohen Datenvolumen und der gefeierten Vertragsflexibilität bildet sich an dieser Stelle sogar ein nicht zu unterschätzendes Risiko. Was passiert, wenn der Cloud-Anbieter seine Services und Preise plötzlich zuungunsten des Kunden ändert? Oder im Extremfall sogar einfach einen ganzen Service mit kurzer Frist vollständig einstellt?

Neben den zwei Blöcken Betrieb und Infrastruktur dürfen aber auch die Kosten für Lizenzen nicht außer Acht gelassen werden. Dieser Punkt unterscheidet sich von den ersten beiden Kategorien (wir lassen Betriebssystemlizenzen mal außer Acht, da diese in den Cloud-Computing-Kosten in der Regel schon enthalten sind) und lässt sich auf die Frage reduzieren: Open Source versus Closed Source. Das hat auf den ersten Blick nichts mit der Frage Cloud oder On-Premises zu tun. Am Beispiel einer Oracle-Datenbank im Vergleich zu PostgreSQL wird die Herausforderung in der Cloud aber deutlicher. Verlässt man sich auf eine bewährte OracleDB auch als Cloudservice, liegt man schnell bei einer signifikanten Lizenz-/Subskriptionsgebühr im Jahr (je nach Infrastruktur). Am teuren Tropf des Herstellers hängt man also auch in der Cloud. Eine unabhängige Open-Source-Alternative wie PostgreSQL gäbe es kostenfrei, jedoch erfordert der Datenbankbetrieb eines Open-Source-Produktes auf Enterprise-Level auch eine Menge Know-how. Das dafür notwendige und qualifizierte Personal ist nicht grade im Überfluss verfügbar. Somit steht den Einsparungen einer reinen Open-Source-Strategie auch die Herausforderung gegenüber, dass entsprechend qualifizierte Personal zu finden und zu bezahlen. Eine Hybridlösung wie eine Subskription von EDB (EnterpriseDB) auf PostgreSQL-Basis könnte diese Einstiegshürde deutlich verringern, gleichwohl man sich auch hier in die Abhängigkeit eines Lösungsanbieters begibt, da dieser Sourcecode nicht offen verfügbar ist. Erwirbt man Lizenz-Subskriptionen direkt von einem Cloud-Anbieter, kann die Abhängigkeit sich sogar noch verstärken, da man meist an die bereitgestellte Infrastruktur gebunden ist. Es ist eben auch in der Cloud nicht leicht, Geld zu sparen und dennoch flexibel und leistungsfähig zu bleiben.

Am Ende geht es bei einer Entscheidung gegen oder für die Cloud immer um das Spannungsfeld aus Kosten im Verhältnis zum Nutzen. Der Nutzen ist dabei stets individuell zu betrachten und kann von daher sehr unterschiedlich bewertet werden. Große Unternehmen sind gut beraten, den Einsatz containerbasierter Lösungen und frei verfügbarer Technologien zu prüfen. Durch intelligente Lösungen auf solchen Konzepten kann tatsächlich die Unabhängigkeit vom Cloudprovider beibehalten werden. Aber auch hier ist darauf zu achten, nicht leichtfertig die aus der Open-Source-Community adaptierten und häufig angepassten Container-Orchestrierungstools einzelner Cloud-Anbieter zu verwenden. Ziel sollte sein, die unternehmenseigene Administrationsschicht der Container in jeder Cloud lauffähig zu halten. Im besten Fall kann diese Administrationsschicht eine Multi-Cloud-Infrastruktur unterstützen. Wenn man Abhängigkeiten vermeiden möchte, gilt dieser Punkt übrigens auch für alle anderen Open-Source-Projekte, die als Service vom Cloudprovider direkt angeboten werden (Achtung: Hier ist nicht immer genau das drin, was draufsteht – lesen Sie die Packungsbeilage!).

Ungeachtet dessen muss vor allem für kleine und mittelständige Unternehmen eine reine Cloud-Strategie nicht von Nachteil sein. Ganz im Gegenteil: Die Investition in eine eigene und nach heutigen Maßstäben leistungsfähige On-Premises-IT kann da im Verhältnis zum Cloudservice signifikant höher sein. Eine mangelnde Unabhängigkeit kann durchaus durch die Vielzahl und Qualität von Cloudservices überkompensiert werden.

Kleiner Ausblick nach diesem groben Überblick: Der nächste Beitrag wird sich etwas detaillierter mit dem Thema Multi-Cloud-Lösungen beschäftigen und wie man mit deren Hilfe Abhängigkeiten oder gar Vendor Lock-ins verhindern kann.