Warum Compute noch kein JavaScript unterstützt

Mit unserer Serverless-Compute-Umgebung Compute möchten wir Entwicklern dabei helfen, mit den Sprachen, die sie kennen und lieben, lückenlos sichere und performante Apps und Nutzererlebnisse auf der Edge zu entwickeln. Es ist also kein Wunder, dass wir häufig gefragt werden, warum Compute kein JavaScript unterstützt.

Diese Frage ist durchaus berechtigt und wichtig, weil andere Serverless-Optionen JavaScript bereits unterstützen. Wir haben ja schon berichtet, wie wir neue Sprachen für Compute evaluieren, und darauf hingewiesen, dass man JavaScript noch nicht mit WebAssembly kompilieren kann, auf dem Compute beruht. Die gute Neuigkeit ist, dass wir derzeit AssemblyScript evaluieren, um diesen Bedarf zu erfüllen. Mit AssemblyScript (einer echten Untermenge von TypeScript, wobei TypeScript eine typisierte Obermenge von JavaScript ist) können Sie das JavaScript Programmiermodell und die JavaScript Syntax verwenden und gleichzeitig die Typsicherheit und die Performance-Vorteile von WebAssembly nutzen.

Eine Frage bleibt allerdings noch unbeantwortet: Warum haben wir nicht den Weg des geringsten Widerstands gewählt und eine Standardtechnologie wie V8 verwendet, die bereits JavaScript unterstützt? Warum haben wir uns für den viel schwierigeren Weg entschieden, unsere eigene Compiler Toolchain zu entwickeln?

Kaufen oder selbst entwickeln?

Fastly setzt bei Problemen seit jeher bei den Grundlagen an und scheut sich nicht, auch schwierige Projekte in Angriff zu nehmen, wenn sich daraus ein Nutzen für unsere Kunden ergibt. Die Entwicklung einer nutzerdefinierten Routing-Infrastruktur mag für ein damals einjähriges Startup-Unternehmen zunächst wie ein törichtes Unterfangen erscheinen. Die vorhandenen Netzwerklösungen zwangen uns aber zu einem Kompromiss zwischen Performance und Kontrolle. Nur, indem wir die Sache selbst in die Hand nahmen, konnten wir die Performance und Flexibilität, die wir für erforderlich hielten, erreichen – eine Entscheidung, die sich bis heute auszahlt.

Was bedeutet das für Compute?

Einen ähnlichen Kompromiss wie bei der Frage „Kaufen oder entwickeln?“ erzwingen bestehende Serverless-Technologien – in diesem Fall zwischen Performance und Sicherheit. Ein „Kaltstart” bei der ersten Ausführung einer Serverless-Funktion dauert viel länger als nachfolgende „Warmstarts”, bei denen bereits alles initialisiert wurde. Einige Technologien wirken diesem Problem entgegen, indem sie die Umgebung über viele Anfragen hinweg wiederverwenden, um die Kaltstartkosten über viele Funktionsaufrufe zu amortisieren. Dadurch wird allerdings aus einem Performance-Problem ein Sicherheitsproblem. Es gibt nämlich jede Menge Sicherheitslücken, die durch die Wiederverwendung von Umgebungen entstehen. Angreifer können zum Beispiel versuchen, auf „übrig gebliebene” Daten aus früheren Aufrufen zuzugreifen oder die Umgebung absichtlich zu „vergiften“, um nachfolgende Aufrufe zu beeinträchtigen.

Durch die Vermeidung von Kaltstartkosten könnten wir also eine Lösung schaffen, die sowohl performant als auch sicher ist. Und genau das haben wir getan. Die Startup-Zeiten von Compute liegen bei unter 35 Mikrosekundenundefined, sodass wir für jede einzelne Anfrage eine völlig saubere Betriebsumgebung bereitstellen können, ohne dass zwischen den Aufrufen Daten in der Umgebung verbleiben.

Die richtige Unterstützung für JavaScript

Wir wollen dieses Gleichgewicht halten und gleichzeitig Ihre bevorzugte Sprache unterstützen. Deshalb beabsichtigen wir, in naher Zukunft JavaScript mit AssemblyScript zu unterstützen, also bleiben Sie dran. Wir investieren weiterhin in die Erweiterung unseres Compute Angebots und sind gespannt, wie unsere Kunden das Potenzial von Compute nutzen werden – unabhängig von der Sprache, für die sie sich entscheiden.