floci ist ein Tool, das vier Cloud-Emulatoren auf dem eigenen Rechner laufen laesst. AWS, Azure, GCP und OCI bekommen je ein eigenes Programm, einen eigenen Port und eine eigene native Binaerdatei unter MIT-Lizenz, und die vier haengen nicht voneinander ab. Man startet also eine davon oder alle gleichzeitig.

Kein Cloud-Konto, kein auth token, keine Funktionssperren, keine Telemetrie; was Docker laufen laesst, traegt es, und Windows, macOS und Linux nutzen dieselben Teile. Version 2.4 kam mit mehr als fuenfhundert Aenderungen, fast alle in der Tiefe der Dienstabdeckung.

Vier Clouds, vier Programme, vier Ports

Die Zuordnung ist schlicht. Das Hauptprogramm antwortet fuer AWS auf 4566, die Azure-Fassung auf 4577, die GCP-Fassung auf 4588, die OCI-Fassung auf 4599. Ein Container, ein Port, ein Protokollsatz je Cloud, und die Daten laufen nicht durcheinander. Wer mehrere Clouds zugleich anfasst, hat damit mehr als mit einer Funktionsliste: ein Testskript tauscht den endpoint und laeuft auf einer anderen Cloud weiter, ohne virtuelle Maschine und Konto pro Cloud.

Der Name kommt von einer Wolkenform, die wie Popcorn aussieht, cirrocumulus floccus. Er passt zum Anspruch: eine Cloud auf den Schreibtisch zu holen ist nicht das Ziel, wohl aber ihre Schnittstelle, damit Code zuerst im Kleinen laeuft.

Die Sekunden, die eine native Binaerdatei spart

Gebaut wird mit Quarkus Native auf der Mandrel-Ausgabe von GraalVM, ausgeliefert wird also Maschinencode statt eines Pakets in einer JVM. Die angegebenen Zahlen sind 24 Millisekunden bis zum Kaltstart, 13 MiB im Leerlauf und ein Abbild von etwa 90 MB. Wer Code schreibt, liest daraus nur schnell. Fuer eine Pipeline bedeutet es etwas anderes: eine frische Umgebung pro Aufgabe, danach abgeraeumt, und das ist nur vernuenftig, wenn der Start billig genug fuer zwanzig parallele Aufgaben ist.

Der uebliche Weg in dieser Werkzeugklasse ist ein vollstaendiger Dienstprozess im Container, Sekunden bis Dutzende Sekunden Start, einige hundert MB im Speicher, und sobald die parallele Matrix kommt, wird um Speicher gestritten und auf Zeitlimits gewartet. Native Kompilierung drueckt beide Zahlen. Der Preis ist ein langer Build und zusaetzliche Reflexionskonfiguration fuer manche Abhaengigkeiten, der uebliche Handel jeder Vorabkompilierung.

Protokolltreue auf echten Engines

Emulatoren scheitern meist am Anschein: gleiche Datenstrukturen, gleiche Statuscodes, anderes Verhalten, lokal alles gruen, in der ersten Stunde im Betrieb kaputt. floci antwortet nicht mit Attrappen, sondern gibt die schweren Datendienste an echte Engines. Jeder Lambda-Aufruf laeuft in einem echten Docker-Container mit den Laufzeitvariablen von Node.js, Python, Java und Go wie in der Cloud. RDS startet echtes PostgreSQL, MySQL oder MariaDB mit vollem Lebenszyklus und Schnappschusswiederherstellung, ueber JDBC-Verkehr und IAM-Datenbankauthentifizierung. ElastiCache ist ein echter Redis-Container mit floci davor als SigV4-Proxy, MSK sitzt auf Redpanda, Athena-Abfragen landen in einem DuckDB-Sidecar, und EC2 RunInstances zieht Container mit SSH-Schluesselinjektion, UserData-Ausfuehrung und beiden Generationen des IMDS-Metadatendienstes hoch.

Zwei Details auf der Protokollebene verdienen einen eigenen Absatz. IAM ist keine Zierde: Lambda, RDS, ECS, EC2, MSK, ECR und OpenSearch pruefen vollstaendig SigV4, ein Fehler in der Politik scheitert also lokal statt im Betrieb. Das Projekt pflegt 1925 eigene Kompatibilitaetstests fuer das AWS SDK und meldet, dass alle bestehen. Das ist eine Selbstauskunft und kein Test durch Dritte, reicht aber fuer die Frage, ob diese Umgebung die vorhandene ersetzen kann.

Eine Konsole, vier Laufzeiten

Es gibt auch eine grafische Oberflaeche, und ihr Aufbau ist durchdachter als es aussieht. Die Oberflaeche im Browser ist mit React und Vite gebaut, hoert auf 4500 und nimmt nur Anfragen an, die mit /api beginnen. Dahinter hoert eine Cloud-Proxy-API aus Bun und Hono auf 4501 und verteilt nach Cloud an vier Adapter, AWS, Azure, GCP und OCI. Die Adapter uebersetzen in das Protokoll der jeweiligen Laufzeit und landen auf den Ports von 4566 bis 4599. Ein Satz aus der Dokumentation nennt die Arbeitsteilung: die Oberflaeche kennt die Cloud nicht, der Proxy die Umsetzung nicht, der Adapter uebersetzt, die Laufzeit fuehrt aus.

Der Vorteil ist, dass Oberflaeche und Cloud getrennt bleiben. Eine neue Cloud braucht einen Adapter und eine Dienstbeschreibung, die Konsole aendert sich nicht. Im Betrieb nennt die Startseite die Zahl der verfuegbaren Dienste und Ressourcen der laufenden Instanz, der Wolkenwechsel ist ein Knopf oben rechts, und die Speicherseite zeigt Name, Typ, Cloud und Anlagezeitpunkt des Buckets, Anlegen und Loeschen in derselben Zeile. Die gezeigte Azure-Instanz meldet 9 of 28 services available, die Abdeckung folgt also der Reife der jeweiligen Cloud und behandelt nicht alle vier gleich.

Wohin 2.4 die Kraft gesteckt hat

Version 2.4 erschien am 31. Oktober. Nach dem automatisch erzeugten Changelog enthaelt sie 210 neue Funktionen, 10 Leistungsverbesserungen und 294 Fehlerbehebungen, zusammen 514 Eintraege. Wohin sie gingen, ist auf einen Blick sichtbar: EC2 nimmt 62, CloudFormation 59, DynamoDB 40 und Lambda Web 22. Die CloudFormation-Runde fuellt konkrete Ressourcentypen, EC2-Praefixlisten, WAFv2-IP-Sets, SES-Mail-Identitaeten und Empfangsregeln, Route53-Recordsaetze, Redshift-Ereignisabonnements und Rollenzuordnungen fuer RDS-Cluster.

Einzeln gelesen sind diese Eintraege trocken. Zusammen sagen sie eines: Infrastrukturcode soll lokal laufen. Ein Terraform-, OpenTofu- oder CloudFormation-Template gegen eine echte Cloud zu probieren kostet Geld und Zeit, lokal kostet es einen Neustart. Der Rhythmus folgt dieser Nutzung, mit einer stabilen Fassung am 15. und einer am Monatsende, dazwischen nightly-Tags auf dem Hauptzweig, sodass eine Korrektur am naechsten Tag da ist.

Was man vor dem Start wissen sollte

Ungleiche Abdeckung ist die erste Realitaet. AWS ist die Hauptlinie mit Diensten in den Hunderten, Azure, GCP und OCI sind sichtbar kleiner, und in der Konsole stehen noch Eintraege mit coming soon. Erst die Dienstliste der Cloud lesen, die zaehlt, und nicht annehmen, alle vier seien gleich tief.

Docker wird ebenfalls gebraucht. Jeder Dienst mit echter Engine braucht eine Container-Laufzeit, ohne diese Schicht auf dem Rechner fehlt die Faehigkeit einfach. Der Zustand ist zudem standardmaessig wegwerfbar: stoppen, starten, und es steht eine saubere Cloud da. Fuer Tests ist das ein Vorteil, fuer alle mit einem langfristigen lokalen Datenbestand ein Nachteil, also zuerst die Speichereinstellungen lesen.

Es ist auch kein Lastgenerator. Es haelt das Protokollverhalten, nicht den Durchsatz. Die angegebene Lambda-Zahl ist 289 Anfragen pro Sekunde, genug zum Pruefen einer Funktion und ohne Aussage als Kapazitaetsmass.

Die tiefere Einschaetzung ist, dass eine lokale Cloud nicht die Rechnung spart. Sie zieht die Schleife aus aendern, laufen und schauen auf Dutzende Sekunden zusammen und gibt einem Codierassistenten einen Ort, an dem er ohne Folgen Dinge kaputt machen darf. Vier Emulatoren, eine Konsole und ein Satz nativer Binaerdateien sind Abwaegungen um diese Schleife, weshalb Protokoll und Engines die feine Arbeit sind und die Abdeckung die grobe.

Eine Cloud auf den eigenen Rechner zu holen geht nicht. Ihre Schnittstellen dorthin zu holen schon. floci nimmt den zweiten Weg: es verspricht nicht, die echte Umgebung zu ersetzen, nur dass jeder Versuch ausserhalb der Rechnung stattfindet.