Was deine Infrastruktur wirklich ausführt, wenn du SST benutzt

Jedes Infrastrukturwerkzeug ist eine Wette darauf, in welcher Ebene du denken willst. Terraform wettet, dass du Ressourcen beschreiben willst. CloudFormation wettet, dass du AWS’ Vokabular akzeptierst und dafür AWS’ Garantien bekommst. SST wettet, dass du lieber eine Anwendung beschreibst und die Ressourcen daraus folgen lässt.

Interessant an SST ist nicht die Wette, sondern was darunter liegt. In v3 hat sich die Antwort geändert, und die neue führt mitten durch Terraform.

Die Kette, ohne Umschweife

SST v2 übersetzte deine Konfiguration in AWS-CDK-Konstrukte, die in ein CloudFormation-Template übersetzt wurden, das AWS dann ausführte. Drei Übersetzungen zwischen dem, was du geschrieben hast, und dem, was lief.

SST v3, vom Projekt Ion genannt, hat CDK und CloudFormation entfernt und Pulumi an ihre Stelle gesetzt. Pulumi wiederum schreibt die meisten seiner Provider nicht selbst, sondern erzeugt sie über eine Brücke aus Terraform-Providern. Pulumi sagt das unmissverständlich: SST „leverages Pulumi behind the scenes for its providers and deployment engine while also bridging Terraform providers through Pulumi.“

Wenn eine sst.config.ts also einen S3-Bucket anlegt, geht das Schema, gegen das validiert wird, auf denselben Terraform-AWS-Provider zurück, den du bei handgeschriebenem HCL benutzen würdest. Nicht auf einen ähnlichen. Auf denselben, verpackt.

Das ist der Teil, der zählt, wenn du Terraform-Erfahrung hast, und der Teil, den kaum jemand ausspricht: dein Wissen überträgt sich. Argumentnamen, Defaults, die sperrigen Ecken einer Ressource, die du dir mühsam angeeignet hast. Sie überleben den Wechsel, weil der Provider ihn überlebt hat.

Was SST dir tatsächlich bringt

Drei Dinge, und es lohnt sich, sie zu trennen, weil das Marketing sie verschwimmen lässt.

• Eine Konfiguration für Infrastruktur und Anwendung. Eine einzige sst.config.ts beschreibt den Bucket, die Funktion, die daraus liest, und das Frontend, das die Funktion aufruft. In Terraform beschreibst du Bucket und Funktion; die Anwendung damit zu verdrahten ist ein separates Problem, das du mit Variablen, Outputs und einem Deployment-Skript löst.
• Breite ohne neue Syntax. SSTs Dokumentation nennt über 150 unterstützte Provider, von AWS, Azure und GCP bis zu Cloudflare, Stripe, Vercel und Auth0. Diese Zahl ist eine direkte Folge der Brücke. SST hat nicht 150 Integrationen geschrieben, sondern ein Ökosystem geerbt.
• Kein CloudFormation. Als Gründe für den Abschied werden die AWS-Zentriertheit von CDK und CloudFormation genannt sowie, dass das Zwischen-Template „often obscured the underlying logic and made it much more difficult to diagnose and resolve problems“. Wer je eine CloudFormation-Rollback-Meldung gelesen hat, erkennt die Beschwerde wieder. Das Template, das du debuggst, ist nicht der Code, den du geschrieben hast.

Was du aufgibst

Wähle ein Werkzeug danach, was es dich kostet, nicht nur danach, was es dir spart.

Eine zusätzliche Abstraktion im kritischen Pfad. Du hast eine Schicht über den Terraform-Providern gewonnen. Geht etwas kaputt, debuggst du jetzt in drei Vokabularen: SST-Komponenten, Pulumi-Ressourcen und der Provider darunter. Die CloudFormation-Undurchsichtigkeit, vor der SST geflohen ist, ist weniger verschwunden als umgezogen.

Der State gehört wieder dir. CloudFormation hielt ihn auf AWS-Seite, was einschränkend war und zugleich eine Sache weniger, die man verlieren kann. Pulumi-basierter State ist eine Datei in deiner Verantwortung, mit allen Fragen zu Locking und Backup, die daraus folgen. Wer Terraform in Größe betrieben hat, hatte die Diskussion über Remote State schon, und ich habe darüber geschrieben, was es kostet, wenn ein Team sie nie führt: ein State File für alles ist das Anti-Pattern, das irgendwann die Seite umlegt.

Ein kleinerer Arbeitsmarkt. Terraform und HCL sind einer. SST ist ein kleinerer. Das spricht nicht dagegen, aber dafür, die Entscheidung schriftlich zu begründen.

Wo die Grenze verläuft

Die nützliche Frage ist nicht, welches Werkzeug besser ist, sondern für welche Ebene dein Team die Verantwortung tragen will.

Existiert deine Infrastruktur, um eine Anwendung zu bedienen, und sind die Leute, die sie schreiben, dieselben, die sie deployen, dann entfernt SST einen Übersetzungsschritt, der sich nie verdient hat. Die eine Konfiguration ist keine Bequemlichkeit, sondern eine Korrektheitseigenschaft: Funktion und Bucket können nicht auseinanderlaufen, weil sie gemeinsam deklariert sind.

Bedient deine Infrastruktur viele Anwendungen, oder übergibt ein Plattformteam Umgebungen an Produktteams, arbeitet dieselbe Kopplung gegen dich. Dann soll der Bucket ein Leben unabhängig von dem haben, der ihn nutzt. Terraforms Trennung von Ressource und Konsument ist der Zweck, nicht eine Lästigkeit, die man wegabstrahiert.

Die Kette zu kennen lohnt sich in beiden Fällen. Wenn ein SST-Deployment an einem Argument scheitert, von dem du nie gehört hast, steht die Antwort drei Schichten tiefer in der Terraform-Provider-Dokumentation. Seltsames Erbe für ein Werkzeug. Aber ein sehr brauchbares.

Next

Die Kurzfassung:

• SST v3 läuft auf Pulumi, und Pulumi erzeugt seine Provider aus denen von Terraform. Das Schema, gegen das validiert wird, ist in beiden Fällen dasselbe.
• Terraform-Erfahrung überträgt sich. Argumentnamen, Defaults und die sperrigen Ecken überleben den Wechsel, weil der Provider ihn überlebt.
• Du tauschst CloudFormations Undurchsichtigkeit gegen ein drittes Vokabular beim Debuggen, und das State File gehört wieder dir.
• Eine Anwendung, ein Team: SST entfernt einen Übersetzungsschritt. Viele Konsumenten hinter einem Plattformteam: halte die Ressource unabhängig von dem, der sie nutzt.

Ungeklärt ist für mich, was aus dem Argument der einen Konfiguration wird, sobald ein zweites Team denselben Bucket braucht. Ab da geht es nicht mehr um Syntax, sondern um Zuständigkeit, und das beantwortet dir keine Vergleichstabelle.