Risiko vs. Belohnung: Ein Leitfaden zum Verständnis von Softwarecontainern

Diejenigen von uns, die alt genug sind, können sich an einen Tag erinnern, als Software hauptsächlich über physische Medien geliefert wurde. Die Verbreitung von Breitbandinternet und Smartphones hat uns in das Zeitalter der Webdienste geführt – Software, die in der Cloud gehostet wird und auf die Benutzer-Clients wie Browser und Apps zugreifen.

Vor nicht allzu langer Zeit wurden Webanwendungen direkt auf physischen Maschinen in privaten Rechenzentren ausgeführt. Zur Vereinfachung der Verwaltung waren diese Anwendungen normalerweise monolithisch – ein einziger großer Server enthielt den gesamten Back-End-Code und die gesamte Datenbank. Jetzt haben Webhosting-Dienste wie Amazon und die Verbreitung der Hypervisor-Technologie all das geändert. Dank Amazon Web Services (AWS) und Tools wie VirtualBox ist es einfach geworden, ein ganzes Betriebssystem in einer einzigen Datei zu verpacken.

Mithilfe von Diensten wie EC2 ist es einfach geworden, Maschinen-Images zu paketieren und Sätze virtueller Server aneinander zu reihen. Dann kam das Microservices-Paradigma – ein Ansatz zur Softwarearchitektur, bei dem große monolithische Anwendungen in kleinere fokussierte Dienste aufgeteilt werden, die eine Sache gut machen. Im Allgemeinen ermöglicht dieser Ansatz eine einfachere Skalierung und Funktionsentwicklung, da Engpässe schneller gefunden und Systemänderungen leichter isoliert werden können.

Haustiere zu Nutztieren

Auf dem Höhepunkt dieses Trends wurde ich Infrastrukturingenieur. Ich erinnere mich, dass ich meine erste Produktionsumgebung in Amazon mit einer Reihe von Bash-Skripten aufgebaut habe. Die Kellner waren wie Haustiere für mich. Ich habe jedem von ihnen niedliche Namen gegeben. Ich habe sie sorgfältig überwacht. Ich habe schnell auf Warnungen reagiert und sie gesund gehalten. Ich behandelte diese Fälle mit Liebe und Zuneigung, weil es schmerzhaft war, sie zu ersetzen – ähnlich wie ein geliebtes Haustier.

Dann kam Chef, ein Konfigurationsmanagement-Tool, und fast sofort wurde mein Leben einfacher. Mit Tools wie Chef und Puppet können Sie den größten Teil des manuellen Aufwands beseitigen, der mit der Verwaltung eines Cloud-Systems verbunden ist. Sie können das Konstrukt „Umgebungen“ verwenden, um Entwicklungs-, Staging- und Produktionsserver zu trennen. Sie können seine „Datentaschen“ und „Rollen“ verwenden, um Konfigurationsparameter zu definieren und Änderungssätze zu pushen. Jetzt hatten alle meine „Haustier“-Server die Gehorsamsschule abgeschlossen.

Dann kam 2013 Docker und eine neue Ära begann: das Zeitalter der Software als Vieh (Entschuldigung an alle Veganer im Publikum). Das Container-Paradigma ist eines der Orchestrierung, nicht des Konfigurationsmanagements. Tools wie Kubernetes, Docker Compose und Marathon konzentrieren sich darauf, vordefinierte Images zu verschieben, anstatt Konfigurationswerte auf laufenden Instanzen anzupassen. Infrastruktur ist unveränderlich; Wenn ein Container kaputt geht, versuchen wir nicht, ihn zu reparieren – wir schießen ihm in den Kopf und ersetzen ihn. Wir kümmern uns mehr um die Gesundheit der Herde als um einzelne Tiere. Wir geben unseren Servern keine niedlichen Namen mehr.

Die Belohnungen

Container machen vieles einfacher. Sie lassen Unternehmen sich mehr auf ihre eigene Spezialsoße konzentrieren. Tech-Teams müssen sich weniger um die Infrastruktur- und Konfigurationsverwaltung kümmern und sich stattdessen hauptsächlich um App-Code kümmern. Unternehmen können noch einen Schritt weiter gehen und Managed Services für Dinge wie MySQL, Cassandra, Kafka oder Redis nutzen, um sich überhaupt nicht mit der Datenschicht auseinandersetzen zu müssen. Es gibt mehrere Startups, die auch „Plug-and-Play“-Dienste für maschinelles Lernen anbieten, damit Unternehmen anspruchsvolle Analysen durchführen können, ohne sich um die Infrastruktur kümmern zu müssen. Diese Trends haben zum serverlosen Modell geführt – einem Softwarearchitekturansatz, der es Teams ermöglicht, Software zu veröffentlichen, ohne eine einzelne VM oder einen einzelnen Container zu verwalten. AWS-Services wie S3, Lambda, Kinesis und Dynamo machen dies möglich. Um die Analogie zu erweitern, sind wir von Haustieren zu Vieh zu einer Art Tierdienst auf Abruf übergegangen.

All das ist sehr cool. Es ist verrückt, dass wir in einer Zeit leben, in der ein Zwölfjähriger mit ein paar Klicks ein ausgeklügeltes Softwaresystem hochfahren kann. Wir sollten uns daran erinnern, dass dies vor nicht allzu langer Zeit unmöglich war. Noch vor wenigen US-Präsidenten waren physische Medien der Standard, und nur große Unternehmen hatten die Mittel, Software herzustellen und zu vertreiben. Fehlerbehebungen waren ein Luxus. Jetzt kann dieser Zwölfjährige ein AWS-Konto erstellen und seine Software der ganzen Welt zur Verfügung stellen. Wenn es einen Fehler gibt, wird ihn jemand auf Slack nerven, und in wenigen Minuten ist ein Fix für alle Benutzer verfügbar.

Die Risiken

Sehr, sehr cool, aber nicht ohne seinen Preis – die Abhängigkeit von Cloud-Anbietern wie Amazon bedeutet die Abhängigkeit von großen Konzernen und proprietären Technologien. Wenn Richard Stallman und Edward Snowden Sie nicht wegen solcher Dinge beunruhigt haben, sollte das jüngste Debakel mit Facebook sicherlich dazu geführt haben.

Eine stärkere Abstraktion weg von der Hardware birgt auch die Gefahr von weniger Transparenz und Kontrolle. Wenn in einem System mit Hunderten von Containern etwas kaputt geht, müssen wir hoffen, dass der Fehler irgendwo auftaucht, wo wir ihn erkennen können. Wenn das Problem beim Hostbetriebssystem oder der zugrunde liegenden Hardware liegt, ist es möglicherweise schwer zu bestimmen. Ein Ausfall, der mit VMs in 20 Minuten hätte behoben werden können, kann mit Containern Stunden oder Tage dauern, wenn Sie nicht über die richtige Instrumentierung verfügen.

Es sind nicht nur Ausfälle, um die wir uns Sorgen machen müssen, wenn es um Dinge wie Docker geht. Es gibt auch das Problem der Sicherheit. Unabhängig davon, welche Containerplattform wir verwenden, müssen wir darauf vertrauen, dass es keine Hintertüren oder nicht offengelegten Sicherheitslücken gibt. Auch die Nutzung von Open-Source-Plattformen ist keine Garantie für Sicherheit. Wenn wir uns für Teile unseres Systems auf Container-Images von Drittanbietern verlassen, sind wir möglicherweise angreifbar.

Einpacken

Das Nutztierparadigma ist aus mehreren Gründen attraktiv, aber es ist nicht ohne Schattenseiten. Bevor die Containerisierung des gesamten Stacks überstürzt wird, müssen Technikteams darüber nachdenken, ob dies die richtige Wahl ist oder nicht, und sicherstellen, dass sie die negativen Auswirkungen mindern können.

Ich persönlich arbeite sehr gerne mit Containern. Ich bin gespannt, wohin sich die Dinge in den nächsten zehn Jahren entwickeln werden, wenn neue Plattformen und Paradigmen entstehen. Als ehemaliger Sicherheitsberater bin ich jedoch vorsichtig genug, um zu wissen, dass alles seinen Preis hat. Es liegt an den Ingenieuren, wachsam zu bleiben, um sicherzustellen, dass wir unsere Autonomie als Benutzer und Entwickler nicht aufgeben. Selbst der einfachste CD/CI-Workflow der Welt wäre die Kosten nicht wert.