Das FLAME-Muster: Ein neuer Ansatz für die elastische Skalierung von Anwendungen
- Serverless/FaaS (Function as a Service) bietet zwar die Vorteile elastischer Skalierung und nutzungsbasierter Abrechnung, führt in der Praxis jedoch zu mehr Komplexität.
- Wenn sich bestehender App-Code in Funktionen kapseln und in temporären App-Kopien ausführen ließe, wäre automatische Skalierung möglich.
- Das FLAME-Muster (Fleeting Lambda Application for Modular Execution) behandelt die gesamte Anwendung wie eine Lambda und führt modulare Teile auf kurzlebiger Infrastruktur aus.
Das FLAME-Muster
- Das FLAME-Muster zielt auf feingranulare, nachfragebasierte elastische Skalierung bestimmter Teile des App-Codes ab, ohne Server verwalten zu müssen.
- Bestehende Anwendungen müssen weder neu geschrieben noch teilweise in einer proprietären Runtime umgesetzt werden.
- Die Elixir-Bibliothek
flameimplementiert das FLAME-Muster und enthält einen Fly.io-Backend-Adapter, kann aber in jeder Cloud genutzt werden, die eine API zum Ausführen von App-Code bereitstellt.
FLAME-Backends
- Auf der Fly.io-Infrastruktur kann
FLAME.FlyBackendeine neue Machine booten und sie in etwa 3 Sekunden mit dem übergeordneten Job verbinden. - FLAME bringt standardmäßig
LocalBackendundFlyBackendmit, aber jeder Host, der eine API zum Provisionieren von Servern und zum Ausführen von App-Code bietet, kann als FLAME-Backend fungieren. - Da Fly.io Anwendungen als Docker-Image paketiert und ausführt, muss lediglich eine neue Machine mit demselben Image gestartet werden.
Elixir außerhalb von FLAME
- Elixir eignet sich sehr gut für das FLAME-Modell, weil es Funktionen wie Prozessüberwachung und verteiltes Messaging gewissermaßen kostenlos mitbringt.
- Wenn eine Sprache über vernünftige Grundbausteine für Nebenläufigkeit verfügt, kann dieses Muster genutzt werden.
- Es gibt auch Beispiele dafür, wie sich das FLAME-Muster in JavaScript-Anwendungen umsetzen lässt, indem modulare Ausführung in neue Dateien ausgelagert und dort ausgeführt wird.
Zu Background-Job-Prozessoren
- FLAME funktioniert gut innerhalb von Background-Job-Prozessoren, ist aber ein anderes Problem als die Skalierung des Worker-Pools durch die Job-Bibliothek.
- Es ist wichtig, Jobs zur Sicherstellung von Dauerhaftigkeit von elastischer Ausführung zu trennen.
Pooling für elastische Skalierung
- Mit der Elixir-Implementierung von FLAME lassen sich Runner für elastische Pools definieren, wodurch FLAME-Server mit Skalierung auf null und einer maximalen Nebenläufigkeitsgrenze elastisch skaliert werden können.
Prozessplatzierung
- In Elixir werden zustandsbehaftete Anwendungsteile rund um den Prozess-Primitive aufgebaut und funktionieren gut, wenn sie in
FLAME.calloderFLAME.castgekapselt sind.
Remote-Monitoring
- Wenn der Parent einen Runner hochfährt, sollte der Runner bei fehlender Arbeit sein eigenes Idling verwalten und sich sicher beenden, wenn die Verbindung zum Parent-Node unterbrochen wird.
Meinung von GN⁺
Das Wichtigste an diesem Artikel ist, dass das FLAME-Muster die elastische Skalierung von Anwendungen vereinfachen kann, indem es die Komplexität klassischer Serverless-/FaaS-Ansätze reduziert. Das Muster ermöglicht Entwicklerinnen und Entwicklern, nur die benötigten Teile schnell zu skalieren, ohne bestehenden Code grundlegend ändern zu müssen. Damit kann es für viele Software Engineers, die Cloud-Infrastruktur nutzen, eine attraktive Lösung sein. Besonders in Sprachen wie Elixir kann das FLAME-Muster ein starkes Werkzeug sein, und da auch Umsetzungen in anderen Sprachen untersucht werden, ist ein Einsatz in vielfältigen Entwicklungsumgebungen zu erwarten.
1 Kommentare
Hacker-News-Kommentare
Dieser Beitrag zeigt die Schmerzen und die Komplexität serverloser FaaS-Architekturen gut auf, die man erlebt, wenn man 4 Jahre lang eine Anwendung mit mehr als 100 Lambda-Funktionen betreibt.
Als Autor des Beitrags hoffe ich, bei Menschen Interesse zu wecken, die das FLAME-Muster in anderen Sprachen wie JavaScript oder Go umsetzen möchten, und ich bin bereit, Fragen zu beantworten.
Der Dienst PiCloud nutzte ein Modell, bei dem Jobs transparent an Worker weitergereicht wurden, was darauf hindeutet, dass sich ein ähnlicher Ansatz auch in anderen Sprachen als Elixir anwenden lässt.
Mit FLAME kann man bestehenden App-Code in eine Funktion kapseln und in einer temporären Kopie der App ausführen, was dem Forken eines Prozesses in einer serverlosen Umgebung ähnelt.
Windmill.dev betrachtet Abstraktionseinheiten auf Quellcodeebene, parst Hauptfunktionen und Importe, extrahiert Argumente und Abhängigkeiten und führt den Code in der gewünschten Runtime aus.
Mit FLAME erhält man eine gute lokale Entwicklungserfahrung für serverlose Umgebungen, da Entwicklungs- und Test-Runner auf einem lokalen Backend laufen.
Jedes Mal, wenn man
Flame.callverwendet, wird ein neuer App-Prozess gestartet und der Ausführungskontext kopiert; das ist zwar eine einfache Lösung für Skalierung, erfordert aber Überlegungen zur zusätzlichen Latenz bei der App-Startzeit und zum Speicherverbrauch.Zusammen mit Kritik an der Großschreibung in der Hacker-News-Überschrift wird die Hoffnung geäußert, dass nicht die serverlosen Prinzipien, sondern die Lage des Unternehmens serverless.com überdacht wird.
Inngest.com bietet einen ähnlichen Ansatz, um bestehenden Code als serverlose Funktionen zu nutzen, verwaltet den Zustand des Codes extern und betont die Bedeutung von Monitoring und Observability.
Wenn man ein System namens "Long Lambda" bauen würde, sodass Lambdas länger als 15 Minuten laufen könnten, ließe sich jede Aufgabe in Lambdas abwickeln, mit der Möglichkeit, lokal auszuführen und zu debuggen.
Diese Zusammenfassung vermittelt die Hauptinhalte der einzelnen Kommentare prägnant und ist so geschrieben, dass auch Softwareingenieure auf Junior-Niveau sie leicht verstehen können. Erklärungen, die Hintergrundwissen erfordern würden, wurden auf ein Minimum reduziert, und der Ton bleibt neutral und beim Thema.