Die Cloud, der unkündbare Subunternehmer

«Die Cloud» ist nicht nur Server. «In die Cloud gehen» kann auch bedeuten, einen ewigen Dienstleistungsvertrag abzuschliessen, schreibt Bert Hubert. Hier unsere deutsche Übersetzung.

Bert Hubert ist ein niederländischer Internetpionier und hat in der Vergangenheit Aufsichts- und Beratungsaufgaben für verschiedene niederländische Regierungsorganisationen übernommen. Er schreibt Artikel, mit denen er ein Fundament für solide Regierungsentscheidungen rund um Technologie und Innovationen schaffen will. Also fast ein bisschen wie DNIP ;-).

Dieser Artikel ist Teil einer Hubert’schen Serie, «die Cloud» und ihre Implikationen zu erklären. Im hier übersetzten Artikel geht er darauf ein, dass «in die Cloud gehen zwei ganz unterschiedliche Bedeutungen haben kann, nämlich die selbstbestimmte Nutzung von Rechenleistung & Co; aber eben auch das Eingehen einer permanenten Verbindung mit dem Cloud-Provider, der man sich im schlimmsten Falle völlig ausliefert. Neben geschichtlichen und technischen Hintergründen gibt Bert Hubert auch Tipps, wie man den Unterschied zwischen den beiden erkennen und ein unbewusstes, schleichendes Verlieren der Kontrolle vermeiden kann.

Der Artikel ist in weiten Teilen aus Sicht einer IT-Firma («wir», «Entwickler») geschrieben, welche die Cloud («Provider») nutzen möchte.

Die in diesem Artikel benannten Cloudprovider sind nur exemplarisch zu sehen. Auch andere Provider setzen ähnliche Techniken ein. Die Verkürzung geschieht nur im Interesse der Lesbarkeit.

Der Artikel ergänzt unsere eigene Cloudserie («Die Cloud» gibt es nicht, Wo genau geht es in die Cloud? Ein Wegweiser durch den Dschungel, Die Cloud als Spielball der Winde) um einen wichtigen Punkt, den wir an dieser Stelle sowieso erläutern wollten. Sowohl was Inhalt als auch Timing angeht, passte er gerade wie die Faust aufs Auge. Wir empfehlen Laien die ersten Teile der Serie zu lesen, da dieser Artikel ein wenig Grundwissen voraussetzt. Leute, die des Englischen mächtig sind, empfehlen wir stattdessen den Einführungsartikel von Bert Hubert, «The (European) cloud ladder: from virtual server to MS 365».

Die DNIP-Redaktion

In aller Kürze

«In die Cloud gehen» kann heissen, dass man Dienste oder Server mietet, die es von der Stange gibt. Damit hat man dann auch kaum Lock-in. Dieselben Worte, «in die Cloud gehen», können aber auch bedeuten, dass man das operative Geschäft der eigenen Firma so eng an einen spezifischen Cloudprovider bindet, dass dessen proprietären Dienste nachher – quasi für immer – Teil der eigenen Geschäftsprozesse werden. Deshalb ist es wichtig, sich klar zu sein, für welche Variante der Cloud man sich entscheidet.

Etwas weniger kurz

Software wurde früher auf Servern «aus Blech» installiert, dann auf virtuellen Servern, dann auf gemieteten virtuellen Servern. Jetzt gerade nehmen wir den – wie es aussieht – nächsten logischen Schritt: Wir lassen uns ein auf den «Lock-in in die Cloud», indem Firmen und andere Organisationen ihre IT-Dienste nicht mehr länger nur auf Servern aufbauen, sondern immer stärker auf mächtigen, aber eben nicht standardisierten, proprietären Clouddiensten von Dritten. Das ist aber nicht nur ein einfacher nächster Schritt, es ist ein fundamentaler Paradigmenwechsel.

Nachdem wir nämlich diesen Schritt gegangen sind, ist das einmalige geistige Eigentum des Cloudproviders ein integraler Teil der Software und Services, die ein Betreiber anbietet. Diese spezifischen Clouddienste sind nicht standardisiert oder austauschbar. Sie sind nicht einfach nur Datenbaken. Sie sind nicht einfach eine Art des Stromnetzes oder der Wasserversorgung, bei der man einfach den Anbieter wechseln kann. Wenn sie so verwendet wird, hört die Cloud auf, die einfach ersetzbare Hardware zu sein. Die Dienste des Entwicklers sind dann eng verflochten mit der spezifischen Cloud-Software, die der Entwickler dann immer mitmieten muss. Die Cloud wird damit zum ewigen Subunternehmer.

Der Vorteil davon ist, dass zur Erstellung der Software spezialisiertere Entwickler genutzt werden können, die sich nicht auch noch Spezialisten für Server, Speicher, Datenbanken oder diese kniffligen Internet-Feinheiten sein müssen, dank denen Nutzer:innen sich sicher beim Dienst anmelden und einloggen können. Viele dieser spezialisierten Cloud-Bausteine erlauben es dem Entwickler auch, schneller ans Ziel zu kommen; vielleicht sogar auch sicherer.

«In die Cloud ziehen» kann ein weiser Entscheid sein. Aber nur, wenn dieser Schritt im vollen Bewusstsein dieses lebenswichtigen Unterschieds zwischen (a) mieten von Servern und Datenbanken (was die Unabhängigkeit grösstenteils wahrt) und (b) darüber hinauszugehen und geistiges Eigentum eines Dritten – des Cloud-Providers – auf ewig in seine eigene Lösung zu integrieren.

Neben dem Bild von der Cloud, in der man seine eigene Software laufen lässt, auf das wir uns in diesem Artikel beziehen, gibt es natürlich auch noch die Cloud als «Software-as-a-Service», kurz «SaaS». Das bekannteste Beispiel davon dürfte sicher Microsoft 365 sein, das eine komplette Software-Arbeitsumgebung für den Büroalltag im Abomodell bereitstellt. Durch die Nutzung von SaaS muss man sich so gut wie nicht mehr um den Softwarebetrieb kümmern. Sie behalten aber auch nur noch winzige Restautonomie über die zukünftige Entwicklung oder wohin ihre Daten fliessen.

Clevere Entwickler werden ihre Nutzung von schwer zu ersetzenden Clouddiensten einzuschränken versuchen. Dazu gibt es zwei Varianten:

1. die Anzahl von Abhängigkeiten reduzieren oder
2. sicherstellen, dass solche Services auch als Software verfügbar sind, die auf anderen Servern bzw. Clouds laufengelassen werden könnte (und sicherstellen, dass die Software auch dort läuft).

Dies bedeutet Arbeit jetzt; diese wird sich aber später ungemein auszahlen.

Nicht vergessen sollte man dabei auch geopolitische Überlegungen. Es kann höchst ungelegen kommen, wenn unersetzliche Dienste von Drittprovidern – die Schlüsselfunktionen in der eigenen Software abdecken – nur noch aus einer in Auflösung befindlichen Demokratie jenseits des Ozeans erhältlich sind, hinter Handelsschranken.

Diese Cloud-Entscheidung sind zugegeben alles andere als einfach zu fällen. Gefällt werden sie aber oft ad-hoc, weit unten in der Verantwortungshierarchie einer Organisation, an Orten, an denen Geopolitik und Langzeitstrategie kaum diskutiert werden. Auch die ­– vor allem in Regierungsorganisationen gelebte –gegensätzliche Strategie: «Azure/Cloud, ausser …», lässt die nötige feingranulare Orientierungshilfe vermissen.

Die Unternehmensführung sollte ein eifriges Interesse an diesen schwierigen Entscheidungen entwickeln, damit die Entwickler bei den guten Cloud-Eigenschaften aus dem Vollen schöpfen können und gleichzeitig das Potenzial für zukünftige peinliche Momente oder Krisen vermindert werden kann.

Die ausführliche Geschichte

Von den 1970ern bis in die 2000er wurden Software-basierende Angebote wie folgt betrieben:

Der Softwarestack zu jeder Zeit bestand aus dem selbst geschriebenen Code (dem Dreieck), welcher auf Frameworks («Programmiergerüst») und Software-Bibliotheken aufsetze, die von uns, dem Entwickler der Gesamtsoftware, auf unbestimmte Zeit lizenziert («gekauft») wurden. Damit hatten wir enorme Kontrolle über das, was passierte. Diese kombinierte Software wiederum lief auf Datenbanken und Services, welche wir auch selbst betrieben.

Auch wenn es Firmen wie IBM gab, die einem dabei unterstützten: Irgendwie musste ein Team zusammengestellt werden, welches sich um alles kümmern konnte, von den Transistoren bis zum Programmcode, der die Logik des Services beinhaltete. Bis heute ist es möglich, so zu arbeiten und die grössten Serviceanbieter machen das auch. Ein bekanntes Beispiel ist der Streamingdienst Netflix, der mittels Hardware, die Netflix gehört, gewaltige Mengen von Video verteilt und das alles mit minimalem Platzverbrauch in den genutzten Rechenzentren. Netflix wäre schlicht nicht so profitabel, wenn sie nicht die ganze Kontrolle über ihren Stack hätten.

Server und die Rechnerräume sind mühsam

So schön sie auch sind, physische Server bringen Ärger. Auch die Rechenzentren (neudeutsch «Data Center») dafür sind eigenständige Projekte. Da ist es in vielen Fällen nichts als vernünftig, diesen Aufwand an jemand anderen zu delegieren und Server schlicht zu mieten. Aber schon das kommt mit einem Datenschutzrisiko. Mit dem richtigen Partner und den passenden Datenschutzgesetzen kann Folgendes aber eine gute Idee sein:

Das grüne Rechteck «Software» ist immer noch vollständig uns. Mit diesem Schritt konnten wir das Kümmern um die Server abgeben, es hat unsere Arbeitsweise ansonsten nicht wirklich verändert. Eine mögliche Änderung könnte die dynamischere Nutzung von Servern sein, beispielsweise mittels Containern. Damit könnte auch die zur Verfügung stehende Gesamtrechenleistung besser ausgenutzt werden.

Die Cloud-Level 1 bis 3 (und Container) sind in meinem Vorgängerartikel erklärt.

Nutzung einiger Cloud-Services

Als nächsten Schritt könnten wir uns dafür entscheiden, einige der vom Cloudprovider fixfertig angebotenen Services zu nutzen. Objektspeicher, Datenbanken, Webhosting, Key-Value-Speicher; die Auswahl ist riesig. Damit müssten wir uns nicht mehr selbst darum kümmern. Und wir hätten jemanden, dem wir die Schuld in die Schuhe schieben könnten, wenn etwas nicht funktioniert.

Die Schlüsselerkenntnis hier: Die Software ist immer noch vollständig in unserer Hand. Ein Umzug zu einem anderen Provider wäre immer noch möglich, solange er diese mehr-oder-weniger Standardangebote auch bietet.

Im Gegenzug brauchen wir keine Entwickler mehr, die sich auch in der Datenbankadministration auskennen und sind trotzdem produktiv.

Herauszufinden, welche der Services «mehr oder weniger Standard» sind, ist allerdings nicht ganz einfach. Und wenn wir hier ein paar ungeschickte Entscheidungen treffen, sind wir sehr rasch beim nächsten, markant anderen Cloud-Level.

Die Cloud als Softwareprovider

Nun geht es ab in eine ganz andere Welt. Eigentlich ist es ein heilloses Durcheinander, dass alle diese Stufe mit dem gleichen Namen «Cloud» vermarktet werden. Denn in diesem Schritt wird unser Cloudprovider auch ein Softwareprovider, bezahlt nach Aufwand.

In dieser Grafik ist erstmals der Cloudprovider auch in das bisher heilige grüne «unsere Software»-Rechteck eingedrungen. Unsere Entwickler nutzen jetzt wesentliche Dienste des Cloudproviders welche essenzielle Services bieten. Diese Services sind nicht mehr «mehr oder weniger Standard», wie Datenbanken oder Rechenleistung. Diese Services können anderswo Pendants haben, aber sie verhalten sich anders. Ein Wechsel ist nicht «plug-and-play». Und in gewissem Masse werden einige dieser Dritt-Dienste zum Rückgrat unseres Produkts.

Der Cloudprovider ist jetzt nicht mehr nur Unterauftragnehmer, ihr habt jetzt eine gemeinsame Firma. Mit dem kleinen Unterschied, dass der Provider die Preise und Bedingungen diktieren kann, unter denen ihr zusammenarbeitet. Und weil viele heutige Entwickler mit den Technologien eines spezifischen Cloudproviders quasi verheiratet sind, wird es für sie auch schwierig, bei einer Migration anderswohin eine Hilfe zu sein.

Dieser Zustand ist offensichtlich nicht wirklich wünschenswert, ausser für einige Aktivitäten am Rand des Produkts, die man einfach ersetzen könnte.

In der Pharmabranche oder der chemischen Industrie ganz allgemein haben Firmen gelernt, sich nicht von einem einzelnen Hersteller abhängig zu machen. Sie strengen sich bis zum Äussersten an, um Abhängigkeiten von einzelnen Herstellern oder auch nur einzelnen Lieferwegen auszumerzen. Auch in der IT-Industrie gab es früher diese Sorgen, die dann zu exotischen Konstrukten wie dem Intel 80286 von AMD führten. Grosskunden forderten einen Zweitlieferanten – und bekamen ihn.

Unter dem Deckmantel der «Cloud als Standardprodukt» kleben wir uns an spezifische Provider, ohne zu realisieren, dass diese nicht wirklich Standardprodukte liefern.

Eingesperrt in die Cloud? Gibt es einen besseren Ausdruck dafür?

Vielen Experten ist der gewaltige Unterschied an Abhängigkeit zwischen (a) Standard-Clouddiensten, bei denen man eine breite Auswahl hat (Server, Speicher, Datenbank) und (b) dem nächsten Schritt, sich nämlich an eine spezifische Cloud zu binden und dafür zusätzliche schlüsselfertige Dienste nutzen zu können.

Trotzdem scheint es keinen Namen für diese zweite Nutzung von Clouddiensten zu geben. Ich habe früher «fully cloud native» dafür genutzt; der Ausdruck wird aber heute in einer Vielzahl von unterschiedlichen Bedeutungen eingesetzt. Andere nutzen dafür «Platform as a Service» (PaaS), aber auch diese Definition scheint nicht sinnvoll, wenn man die Definitionen von AWS, Microsoft und Google dazu sieht.

Wenn es einen eingängigen Namen gäbe, könnte dieser bei besseren Entscheidungen helfen: Mieten wir Server oder gehen wir eine Lock-in mit der Cloud ein?

Intermezzo: Mit den richtigen Fertigkeiten schafft man es locker in die Cloud und wieder heraus

Wenn wir genügend clevere Software-Architekten und sowas wie Full-Stack-Entwickler haben, dann können wir nicht nur diese totale Abhängigkeit von Anfang an vermeiden; nein, wir könnten auch rasch wieder aus einem Lock-in herausmigrieren, sollte sich unser Provider beginnen, problematisch zu werden.

In vielen Fällen gehen Firmen aber eben genau deshalb «all in» bzw. «Lock-in» weil sie solche cleveren Leute nicht mehr haben oder weil sie diese am Laufmeter verheizen. Mit den richtigen Leuten ist das also kein echtes Risiko, aber wir müssen dann auch sicherstellen, dass diese Leute bei uns bleiben. Wenn wir uns aber entscheiden, alles outzusourcen, wird das aber sehr schwierig.

Eine funktionierende Lösung aus einem Providerumfeld sauber herauszulösen, um sie dann anderswo wieder einzubauen ist eine schweisstreibende und traumatische Arbeit. Ganz besonders, wenn der Provider eben nicht nur Strom und Rechenleistung bietet, sondern auch eine Unzahl an raffinierten und extrem spezialisierten Diensten. Dazu braucht es viele fähige Leute, die sich mit mehreren Clouds auskennen – oder sogar wissen, wie das ganz ohne Cloud funktionieren würde. Aber diese Leute sind meist über alle Berge bevor die Probleme aus dem Lock-in sich – auch für das Management sichtbar – klar genug abzeichnen.

Die Erfahrung zeigt, dass Firmen sich unheimlich schwertun, ihre Mitarbeiter:innen umzuschulen, wenn die Zeit dafür gekommen ist. Geschäftsleitung und mittleres Management haben bis dahin ihre Fähigkeiten (und Interesse) für technisches Management verloren. Und die Personalabteilung kann gute nicht mehr von schlechten Techniker:innen unterscheiden. Und für die Top-Geeks – die man ja jetzt so dringend bräuchte – hat das Arbeitsumfeld bis dann auch jegliche Attraktivität verloren.

Eine Firma, die ich kenne, hat vollkommen vergessen, dass Entwickler für ihre Arbeit «richtige» Computer brauchen. Stattdessen bekommen die Entwickler jetzt verriegelte Arbeitsplatzrechner, perfekt für Excel und Word. Aber sie können darauf keine Entwicklungsumgebung installieren oder einen Compiler nutzen. Die Firma glaubt, Softwareentwickler könnten auch Software entwickeln auf Rechnern, denen die Software fehlt, um darauf zu entwickeln.

Unabhängig davon ist das «zurückholen» von Software auf Infrastruktur unter eigenen Kontrolle mit Arbeit verbunden.

Eine verbreitete Meinung ist, dass Entwickler sich auf Multi-Cloud-Betrieb ausrichten sollten, weil damit der Lock-in zu einer spezifischen Cloud vermieden werden kann. Die meisten Organisationen, die sich für eine spezifische Cloud entscheiden, machen das aber genau deshalb, weil ihnen das fachliche Können fehlt für den komplexen Multi-Cloud-Betrieb fehlt. Es ist einfacher, die Cloud-Abhängigkeiten einzuschränken als sich mittels Multi-Cloud-Strategie dagegen abzusichern.

Ausgewogenheit

Es sollte klare Regeln geben, welche Clouddienste die Entwickler für den produktiven Einsatz nutzen dürfen. Heute fehlen diese Regeln mehrheitlich, weshalb individuelle Entscheidungen ad hoc und in den falschen Gremien getroffen werden. Die Cloudarchitekten werden oft an der Geschwindigkeit gemessen, mit der sie und ihre Entwicklerteams zu einer Lösung kommen. Späte Nebenwirkungen, egal wie teuer sie potenziell zu stehen kommen, stehen deshalb natürlicherweise auf ihrer Prioritätenliste nicht weit oben. Wir sollten von Softwareentwicklern auch nicht erwarten, dass sie geopolitische Überlegungen fernab ihrer eigentlichen Aufgabe dauernd im Blick behalten.

Trotzdem gibt es scheinbar bisher kaum Firmenspitzen, die solche Regeln zuhanden der Entwicklungsabteilungen ausgearbeitet hat. Ebenfalls fehlen praktische Erkenntnisse, wie gut solche Regeln funktionieren. Meist sehen wir gar keine Policy oder dann Gemeinplätze wie «nutze AWS, ausser es gibt einen guten Grund dagegen».

Die Entscheidung zur Nutzung spezifischer Clouddienste sollte folgende Punkte berücksichtigen:

• Ist der Service auch als Software verfügbar, so dass wir sie auch selbst betreiben (oder betreiben lassen) könnten?
• Können wir unsere Software so gestalten, dass wir zu äquivalenten Diensten wechseln könnten, auch wenn die Schnittstellen (APIs) oder Semantik eine andere ist?
• Gräbt sich der Clouddienst tief in die Wirkungsweise unserer Software ein? Beispielsweise,kontrolliert der Cloudprovider die Identitäten unserer Nutzer:innen? Sind unsere Kund:innen(-Konten) überhaupt noch unsere Kund:innen?
• Können wir unsere Daten auch wieder aus dem Clouddienst herausholen? Oder müssen dazu zuerst alle Nutzer:innen ihre Passwörter ändern oder sonst irgendwie aktiv an der Migration mitarbeiten?
• Brauchen wir diesen Dienst wirklich? Vielleicht kann das auch unsere Datenbank schon von sich aus?

Falls solche feingranularen Governance-Regeln zu schwierig umzusetzen sind, bleibt immer noch die Wahl, keine Clouddienste ausser Rechenleistung, Containern und Datenbanken zu nutzen. Entwickler müssten dann Lösungen für jede ihrer Anforderungen suchen und diese selbst auf Cloudservern zum Laufen bringen. Dies ist initial Mehrarbeit, aber zahlt sich wahrscheinlich langfristig mehrfach aus.

Es gibt zwei Optionen: Die Firmenleitung erarbeitet einen praktikableren Regelsatz oder die Entwickler bekommen mehr Aufgaben. In beiden Fällen können die langfristigen Vorteile massiv sein.

… weil die Welt nicht einfacher wird

Server können überall gemietet werden. Einem Lieferanten Zugriff zu den eigenen Daten zu geben, klingt immer gefährlich. Egal, ob diese Daten nun privat, geheimen oder beispielsweise Gesundheitsdaten sind. Bis vor kurzem galt die Übergabe deiner innersten Geheimnisse an Microsoft, Google oder Amazon als vernünftige Strategie, ganz besonders, wenn genügend Geld investiert wurde in die Erstellung einer Datenschutzfolgeabschätzung oder eines ähnlichen Dokuments. Diese Dokumente hätten jedoch schon immer in Betracht ziehen sollen, dass die Cloudprovider aus einem Land kommen, das sich entschied, dass unser Kontinent bzw. die EU «very nasty» sei.

Einen Lieferanten auszuwählen, von dem man nicht kurzfristig wegkommt und der aus einem Land stammt, welches zunehmend instabil wird, ist wahrscheinlich nicht die beste Idee.

Zusammenfassung

«In die Cloud gehen» kann vieles bedeuten. Das heisst auch, dass «in die Cloud gehen» für sich alleine noch keine vollständige Entscheidung sein kann. Wenn es bedeutet, «wir werden Server dynamisch mieten», dann ist das die harmlose Variante. Dieselben vier Worte können aber auch bedeuten, dass man Google zum ewigen Subunternehmer erhebt, der nun den Zugang zu unseren Kunden kontrolliert, für immer. In diesem Fall ist «in die Cloud gehen» gleichbedeutend damit, die Selbstbestimmung über unsere Zukunft abzugeben.

Dass beide Entscheidungen mit denselben Worten bezeichnet werden ist verwirrend. Und natürlich haben die Cloudprovider keinen Anreiz uns auf die Nase zu binden, bei welchen ihrer Dienste wir eine (unlösbare) Bindung eingehen. Die Preismodelle und Gratisangebote für Einsteiger der Hyperscaler scheinen sogar absichtlich so designt, dass ihre Kunden möglichst rasch in möglichst unlösbare Beziehungen eingewoben werden.

Mit einer gesunden Dosis Aufmerksamkeit und einer weisen Auswahl können wir viele Vorteile aus der Cloud ziehen. Weil aber die meisten potenziellen Probleme erst weit in der Zukunft liegen, tun sich Firmen schwer, rechtzeitig und vorausschauend qualitativ hochwertige Regeln aufzustellen. Denn diese Entscheide kosten heute Geld.

Im Zweifel ist eine einfache Faustregel, nur Clouddienste zu nutzen die fast identisch von vielen Providern angeboten werden.

Auf jeden Fall muss sichergestellt sein, dass eine Entscheidung, die nach «wir werden einfach ersetzbare Server mieten» nicht schleichend ausartet in «wir haben Google als ewigen Partner ins Boot geholt und die besitzen nun unsere Kundendaten».

Übersetzung und leichte Adaptation: Marcel Waldvogel