Kolumne

EnterpriseTales: Cloud-Computing is someone else’s computer

Lars Kölpin

© S&S Media

Schon lange hören wir von Kunden immer wieder von der Absicht, in die Cloud zu wollen. So viele Befürworter hinter dem Geschäftsmodell stehen, so viele Kritiker stehen ihm gegenüber. Bei Vorfällen hört man dann immer öfter in scherzhaftem Ton, dass Cloud-Computing nur „someone else’s“ Computer sei. Doch ist das tatsächlich noch so? Steckt hinter Cloud-Computing wirklich nur der Computer von jemand anderem, oder hat sich das Geschäftsmodell in den letzten Jahren gewandelt?

Vom zentralen Team zum dezentralen Team

Früher war das Entwicklerdasein doch so einfach. Der Kunde bzw. die Fachabteilung hatte einen Wunsch, gab uns ein bisschen Zeit, den Wunsch umzusetzen, und ein paar Monate später sahen wir uns mit der fertigen Software wieder. Diese wurde an die Testabteilung übergeben. Nachdem sie nach einer mehrwöchigen Testphase abgenommen wurde, wurde die Software in Produktion genommen. Doch es hat sich etwas verändert. Unternehmen setzen in ihrer IT-Abteilung heutzutage vermehrt auf agile Methoden, Extreme Programming und praktizieren den „Continuous Process“ – um genau zu sein, also das permanente Integrieren von Veränderungen im Code sowie kleine Releasezyklen.

Als der Streaminggigant Netflix das Konzept der Microservices etablierte, gab es eine regelrechte Revolution. Unternehmen wollten keine große Software – genannt Monolith – mehr, sondern kleine, unabhängige Dienste, die gemeinsam eine Softwarelandschaft ergeben. Jeder dieser Dienste wird dabei von einem separaten Team betrieben, das einen reibungslosen Ablauf des jeweiligen Dienstes gewährleistet. Frei nach dem Motto: „You build it, you run it.“ Der Entwickler wandelt sich damit einhergehend in vielen Unternehmen immer mehr vom reinen Developer zu einem vollständigen Produktbetreiber eines Dienstes. Damit verbunden migrieren immer mehr Unternehmen ihre Infrastruktur in die Cloud. Doch warum ist das so?

Damit Software Werte für das Unternehmen generieren kann, müssen diese in irgendeiner Weise auf einem physikalischen Computer laufen. Das führt dazu, dass Unternehmen vor dem eigentlichen Release der Software in eine Infrastruktur investieren müssen, indem sie physikalische Rechner anschaffen und dafür sorgen, dass sie störungsfrei laufen. Software, die in Produktion betrieben wird, sollte der Erfahrung nach isoliert, also auf für die Software eigener oder virtualisierter Hardware, betrieben werden, damit ein System bei falscher Konfiguration andere Systeme nicht beeinflusst. Wird die Software von Endkonsumenten besser angenommen als erwartet und wird zu wenig in eine Infrastruktur investiert, muss trotzdem eine Verfügbarkeit sichergestellt werden. Wird im Gegensatz dazu das Produkt weniger gut angenommen, wurde für die bereitgestellte Infrastruktur unnötiges Geld ausgegeben. Die perfekte Investition für das Betreiben der Rechner ist deshalb kaum vorherzusagen. Wird die Software international verwendet, muss darüber hinaus eine gute Antwortzeit in den verschiedenen Regionen der Welt garantiert werden. Läuft der Speicher des Servers voll, muss er erweitert werden. Damit sichergestellt werden kann, dass keine Daten verloren gehen, darf das regelmäßige Erstellen eines Backups natürlich nicht fehlen. Die Kosten der Software bestehen also nicht nur aus der reinen Entwicklung, sondern beinhalten auch versteckte Kosten von Hardware, Monitoring und Wartung der Hardware. Das sind Kostenpunkte, die vor allem durch die vielen kleinen Teams und Dienste, die der Microservices-Ansatz mit sich bringt, multipliziert werden.

Cloud-Computing damals

Amazon erfuhr die Probleme im Rahmen des Weihnachtsgeschäfts am eigenen Leib und extrahierte 2006 die Amazon Web Services (AWS) und damit das Geschäftsmodell des Cloud-Computings. Mit dem Dienst war es erstmals möglich, Rechenpower im Minutentakt dynamisch zu mieten – und vor allem wieder zu kündigen. Die Hardware, auf der die Software läuft, die zu Stoßzeiten, wie beispielsweise zur Weihnachtszeit, mehr Rechenpower benötigte, konnte auf Knopfdruck oder sogar vollautomatisch skaliert werden. Infrastructure as a Service war geboren. Aber das Modell bringt Probleme mit sich. Zwar wird die Infrastruktur bereitgestellt, jegliche Software, die auf der Infrastruktur betrieben wird, wie beispielsweise das Betriebssystem und die auf dem System laufende Laufzeitumgebung, müssen jedoch selbst gepflegt werden. Das Administrieren und Konfigurieren der Systeme bleiben deshalb nicht aus. Neue Entwickler im Team müssen deshalb häufig zusätzlich zu dem gewählten Tech-Stack auch noch Fähigkeiten in der Administration von Linux-Systemen oder Ähnlichem lernen.

Es folgten deshalb kurze Zeit später die ersten Services, die statt reiner Hardware nun Hardware inklusive Laufzeitumgebung anboten. Dazu zählen z. B. Heroku oder der Dienst der Google Cloud Platform AppEngine, bei denen das reine Artefakt einer Software weltweit betrieben werden kann. Die Dienste bieten die Laufzeitumgebung in einer bestimmten Version für das Artefakt (im Fall von Java: JAR-Dateien) an. Das konkrete Betriebssystem, inklusive Sicherheitsupdates und Ähnlichem, wird komplett vom Anbieter verwaltet. Dabei wird ein tieferes Verständnis des Betriebssystems, wie beispielsweise Linux, nicht weiter benötigt. Die darunterliegende Hardware und deren Skalierung werden abstrahiert.

Auf die Spitze treibt Amazon das Konzept der verwalteten Hardware und Software mit dem Dienst Lambda und dem damit verbundenen Konzept von Function as a Service, bei dem einzelne Funktionen auf der Infrastruktur von Amazon hochgefahren, ausgeführt und dann direkt wieder runtergefahren werden. In Rechnung gestellt werden die reine Ausführungszeit sowie die Anzahl der Ausführungen. Als Auslöser dieser Funktionen dienen AWS interne Ereignisse oder externe Auslöser wie HTTP-Anfragen.

Die Herangehensweise, dass Server nicht mehr im eigenen Rechenzentrum betrieben, sondern (ggf. virtuell) angemietet werden, hat sich mittlerweile etabliert. Bei dem Blick darauf, was die internen Rechenzentren so tun, fiel allerdings schnell auf, dass es nicht nur das Betreiben von Servern war, sondern auch das Betreiben von Datenbanken. Daher war es eine gravierende Veränderung, dass bei den gängigen Anbietern Datenbanken wie PostgreSQL, MySQL oder Oracle mit wenigen Klicks erstellt und betrieben werden konnten – automatische Backups inklusive. Was gut für die nutzenden Unternehmen ist, stellt ein Problem für die Cloud-Anbieter dar. Sich vom Konkurrenten in diesem Bereich abzuheben, ist nur begrenzt möglich, weshalb die Anbieter das Angebot häufig um Eigenentwicklungen für ihre spezifischen Anwendungsfälle erweiterten. Ein solcher Dienst ist zum Beispiel DynamoDB, eine verwaltete NoSQL-Datenbank, die das Problem einer weltweit skalierbaren Datenhaltung löst, dafür aber mit Eigenheiten daherkommt.

Cloud-Computing heute

Durch die positive Annahme der spezifischen Dienste ist ein weiterer Trend zu beobachten: Neben dem Angebot von Infrastruktur und klassischen Anwendungen wie Datenbanken und Datenhaltung gibt es immer mehr Dienste, die ein Wissen für bestimmte Nischen abdecken.

Nimmt man als Beispiel dazu den Dienst Recognition von Amazon, so bietet dieser den Kunden Zugriff auf ein riesiges Machine-Learning-Netz, um Bilder und Videos zu analysieren, ohne sich tiefer mit dem Thema auskennen zu müssen. Mit Textract kann der Traum vom „paperless Office“ realisiert werden. Der Dienst kann gescannte Dokumente analysieren und auswerten, ohne dass ein Mensch dazu die Daten mühselig in ein Computersystem übertragen muss. Das Spannende: Theoretisch muss dabei nicht eine Zeile Code geschrieben werden.

Die wenigsten Applikationen kommen ohne Querschnittsfunktionen, wie z. B. eine Authentifizierung, aus. Ohne tieferes kryptografisches und mathematisches Verständnis ist es meist schwer möglich, eine wirklich sichere Benutzerverwaltung zu implementieren. Nicht selten werden deshalb mehrere Wochen zum Feinjustieren investiert, ohne einen wirklichen Mehrwert der Software für Unternehmen zu bieten. Durch das Einbinden der entsprechenden Dienste, wie beispielsweise Amazons Cognito, steht dem System im Gegensatz dazu mit wenig Code ein kompletter Authentifizierungsserver – inklusive granularer Rechteverwaltung für die eigenen Dienste des Cloud-Anbieters – zur Verfügung. Es ist also ein klarer Trend zu erkennen: Cloud-Computing wandelt sich immer mehr vom Anbieter reiner Infrastruktur zum Anbieter von Lösungen.

Das Kaufen von fertiger Software zur Integration in die eigene Systemlandschaft und damit verbundenem Wissen, das nicht der eigenen Kernkompetenz entspricht, ist keine neue Idee. In der Vergangenheit bedeutete das aber immer, dass solche Software im eigenen Rechenzentrum betrieben werden musste und sehr viel Aufwand in die Integration der heterogenen Teilsysteme geflossen ist. Die Kosten für diesen Integrationsaufwand sind häufig nicht abzuschätzen, obwohl sie eigentlich bei der Kalkulation auf die Anschaffungs- und Lizenzkosten der Drittanbieter aufgeschlagen werden müssten. Vor diesem Hintergrund ist es besonders interessant, dass der Fokus der Cloud-Anbieter in den vergangenen Jahren neben dem Anbieten der Dienste zunehmend auf deren wechselseitiger Integration liegt. Wer sich für einen Cloud-Anbieter entscheidet, kauft damit nicht nur spezifisches Wissen und Lösungen, sondern ein ganzes Ökosystem von integrierten Diensten ein.

Wo es vor einigen Jahren noch undenkbar war, Dienste, wie beispielsweise einen Dokumentenscanner oder Bilderkennung, außerhalb des eigenen Rechenzentrums zu betreiben, stehen diese heute mit einem einzigen Klick und ohne eine vorherige große monetäre Investition direkt zur Verfügung. Unternehmen erhalten Zugriff auf eine riesige Sammlung von Infrastruktur und Wissen der Giganten von Google und Amazon. Sie zahlen nur das, was sie wirklich brauchen, und müssen nicht einmal die darunterliegende Rechenpower betreiben.

Aber wie heißt es doch so schön: Es ist nicht alles Gold, was glänzt. Nicht zuletzt zeigen Vorfälle wie der bei Microsofts Azure, dass die Nutzung vollständig verwalteter Dienste nicht ganz ohne Risiken daherkommt. Dort wurden Anfang 2019 automatisiert Datensätze aus Datenbanken gelöscht und waren unwiederbringlich verloren. Durch das Einkaufen und Nutzen der Dienste und das damit verbundene Wissen verliert das eigene Unternehmen einerseits diese Kompetenzen, und erhöht andererseits zugleich die Abhängigkeit vom Anbieter. Weil ein Dienst selten allein daherkommt, und diese Dienste oft miteinander verzahnt bzw. sehr einfach mit anderen Diensten zu integrieren sind, kaufen sich Unternehmen häufig unbewusst in das Ökosystem der Cloud-Anbieter ein. Damit macht sich das eigene Unternehmen abhängig von dessen Preispolitik und Service Level Agreements. Auch deshalb entschied sich z. B. der Speicherdienst Dropbox in den letzten Jahren, die Daten aus dem Simple Storage Service von Amazon in ein eigenes Datenzentrum mit eigener Software zu migrieren.

Fazit

Also ist Cloud-Computing tatsächlich nur „someone else’s“ Computer? Meiner Meinung nach ist diese Aussage nicht ganz einfach zu beantworten. Im Allgemeinen muss zunächst zwischen Infrastruktur und angebotenen Diensten unterschieden werden. Betrachtet man den infrastrukturellen Aspekt, so ist Cloud-Computing nicht nur „someone else’s“ Computer, sondern eher „someone else’s globally distributed datacenter with engineers working 24/7 to ensure its availability“. Dennoch darf nicht vergessen werden: Es herrscht die Einschränkung, dass Kompetenzen abgegeben werden. Gibt es einen Vorfall im Datenzentrum, ist man selbst zunächst machtlos. Betrachtet man im Gegenzug den Wandel und setzt ein Unternehmen vermehrt auf die Dienste eines Anbieters, so kauft sich dieser eher „someone else’s knowledge“ und „someone else’s ecosystem“ ein. Und das ist als eine Chance und ein Risiko zugleich zu verstehen.

Geschrieben von
Lars Kölpin

Lars Kölpin ist Enterprise-Entwickler bei der OPEN KNOWLEDGE GmbH in Oldenburg. Zu seinen Leidenschaften gehören moderne Frontend-Technologien, vor allem im Zusammenspiel mit modernen Cloud-Architekturen.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: