Mandantenfähige Container- und Clouddienste mit AWS Firecracker

Als AWS auf der re:invent 2014 das serverlose Zeitalter mit der Einführung von "Function-as-Code" (FaC) in Form des neuen Dienstes Lambda einleitete, kam dies einer Revolution gleich, nicht unähnlich der Situation mit der Einführung von selbstverwalteten virtuellen Servern in der Cloud im Jahr 2006 (Amazon EC2). Der primäre Entwicklungsfokus bei Lambda lag seinerzeit darin, Entwicklern eine sichere serverlose Nutzererfahrung zu bieten und von der Notwendigkeit einer eigenhändigen Verwaltung der Infrastruktur zu entkoppeln. Um den erforderlichen Isolationsgrad zu erreichen, verwendete AWS für Lambda anfangs dedizierte EC2-Instanzen für jeden Kunden. Der Ansatz erlaubt AWS zwar das Erreichuen der gesteckten Sicherheitsziele, zwingt aber auch zu Kompromissen in der Art und Weise, wie Lambda hinter den Kulissen verwaltet wird.

Die Geburtsstunde von Firecracker

Da anfangs nicht ganz klar war, wie Kunden Lambda einsetzen würden, lag der Fokus zunächst auf einer möglichst einzigartigen Nutzererfahrung. Das Lambda-Backend sollte erst mit der Zeit effizienter gestaltet werden. Spätestens seit 2018 ist aber klar, dass Lambda und Serverless von Kunden und Entwicklern enorm gut angenommen werden. Laut AWS verarbeitet Lambda heute jeden Monat Billionen von Funktionsausführungen für hunderttausende aktive Kunden. Darüber hinaus hat AWS 2018 die Vorteile von Serverless mit der Einführung von Fargate auf Container ausgeweitet. Seither führt Fargate jede Woche Millionen Container für AWS-Kunden aus. Da offenbar immer mehr Unternehmen serverless arbeiten, war es für AWS an der Zeit, das Effizienzproblem am Backend zu überdenken. Dabei stellten sich die AWS-Entwickler die Frage, wie eine virtuelle Maschine heute aussähe, wäre sie ausschließlich für das Bereitstellen von Containern beziehungsweise Funktionen ausgelegt.

Das Ergebnis ist Firecracker [1]. Das GitHub-Repository

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.