Made Manifesto

VIII. Umarmung der Cloud

Oktober 16, 2017

Einige IT-Mitarbeiter trösten sich immer noch damit, dass sie blinkende Lichter in der Besenkammer sehen.

Aus diesem Grund läuft die Nutzung der Cloud immer noch den üblichen vertraglichen Vereinbarungen zuwider. Um ehrlich zu sein, haben die IT-Leute nicht ganz unrecht. Sie vertrauen Ihre Daten einem gesichtslosen Unternehmen an. Sie können nicht sehen, wo sie sind. Sie können nicht sicher sein, dass sie nicht an die CIA weitergegeben werden. Manchmal werden all diese schicken Abstraktionen undicht, und etwas geht schief. Und wenn das passiert, gibt es nichts mehr, was man mit dem Schraubenschlüssel angreifen könnte. Kontrollfreak ist ein Attribut, das bei einem SysAdmin besonders willkommen ist, und die Cloud nimmt ihm die Kontrolle.

Wenn wir davon sprechen, die Cloud voll und ganz zu nutzen, weiß der normale IT-Mitarbeiter oft nicht genau, was das bedeutet. Sie sind schon seit geraumer Zeit mit der Servervirtualisierung vertraut, können sich aber nicht mit dem Gedanken anfreunden, dass diese virtuellen Server flüchtige Klone sind. Wie die Figur Sam Bell in "Moon" könnte ihre Festplatte jederzeit gelöscht werden, und es sollte keine Rolle spielen, weil der nächste Klon immer bereit ist, herausgerollt zu werden. 

Jetzt haben die Container in unserer virtuellen Serverfarm Namen wie 050487d5cab85820e. Auf diese Weise ist es schwieriger, eine Verbindung herzustellen.

Die erste Regel beim Farmen ist, dass man den Tieren keine Namen gibt. Deshalb haben wir schon vor langer Zeit die Namensgebung für Server aufgegeben. Jetzt haben die Container in unserer virtuellen Serverfarm Namen wie 050487d5cab85820e. Auf diese Weise ist es schwieriger, sich zu binden.

Das ist es, was die vollständige Einbeziehung der Cloud bedeutet. Es geht nicht nur darum, ein paar virtuelle Server zu betreiben. Es bedeutet, horizontal skalierbare, zustandslose Anwendungen zu entwickeln, die als Teil eines orchestrierten Chors von Servern installiert, gebootet und gelöscht werden können. Es bedeutet, dass Sie Ihre statischen Assets außerhalb Ihrer Kernanwendung halten. Es bedeutet, sich auf On-Demand-Dienste für Datenbanken, Caches, Routing und Speicher zu verlassen. Irgendwo unter all dem gibt es Server, deren Namen Sie aber nie erfahren werden. Sie verschwinden in einem elektrischen Meer von "Infrastruktur". Bald wird es nur noch Code geben, und Dienste wie AWS Lambda und Google AppEngine treiben uns weiter in diese Richtung. Und das ist eine gute Sache.

Die Server verschwinden in einem Meer aus Infrastruktur.

Und manchmal geht es auch schief. Auch wenn Cloud-Anbieter von Redundanz und der Beseitigung einzelner Fehlerquellen sprechen, ist dies letztlich unmöglich. Nur die Naiven vertrauen darauf, dass die ausfallsicheren, in mehrere Zonen unterteilten und in Datenbankclustern untergebrachten verteilten Dienste wirklich fehlerfrei sind. Gerade die Systeme, die die Redundanz koordinieren, werden zu Single-Points-of-Failure. Es ist wie ein unveränderliches physikalisches Gesetz, dass die Beseitigung von architektonischen Fehlern andere, komplexere Fehler zur Folge hat.

Und doch. Wenn man die Betriebszeit des gesamten Systems betrachtet, die Vorteile der Bequemlichkeit abwägt und das der Infrastruktur zugrundeliegende Fachwissen in Betracht zieht - und das alles pro Prozessorzyklus - ist es immer noch besser, als sich auf den Server im Schrank zu verlassen. Außerdem hat der IT-Mitarbeiter, der alles kontrollieren will, in der Regel einen riesigen blinden Fleck, der den risikoreichsten einzelnen Fehlerpunkt im System abdeckt: Sich selbst.

Pflichtlektüre:

Nächster Monat: Cache First (Fragen später stellen)