Ihre erste App in STACKIT

Eine Cloud-Plattform wirkt auf den ersten Blick oft wie eine Liste von Services. PostgreSQL, Redis, Kubernetes, Container Registry, Terraform-Provider. Alles da, alles bekannt, alles klingt nach einem schnellen Start. Doch ob eine Plattform wirklich gut ist, zeigt sich nicht in der Feature-Liste, sondern in dem Moment, in dem Sie eine echte Anwendung darauf betreiben möchten.

Genau dort beginnt dieser Beitrag.

STACKIT tritt als europäische Cloud mit einem klaren Versprechen an: Infrastruktur aus Deutschland, DSGVO-Nähe, mehr digitale Souveränität. Das ist relevant, vor allem für Unternehmen mit hohen Compliance-Anforderungen. Für die Entscheidung, ob ich eine Anwendung dort hosten würde, reicht mir dieses Argument allein aber nicht aus. Datenhoheit ist wichtig, aber sie beantwortet nicht die praktischen Fragen, die im Alltag zählen.

Wie gut lässt sich Infrastruktur automatisieren? Wie reibungslos greifen die einzelnen Bausteine ineinander? Wo entstehen unerwartete Hürden? Welche Kosten fallen schon bei einer kleinen App an? Und fühlt sich die Plattform nach einem Werkzeug an, dem man produktive Last anvertrauen möchte?

Um genau das herauszufinden, habe ich eine einfache, aber vollständige Anwendung auf STACKIT aufgebaut: einen URL Shortener mit Node.js-Backend, PostgreSQL als Datenbank, Redis als Cache, Kubernetes als Laufzeitumgebung und einer öffentlichen URL. Klein genug, um verständlich zu bleiben. Realistisch genug, um die typischen Fragen einer produktiven App sichtbar zu machen.

In diesem Beitrag geht es deshalb nicht um eine Hochglanz-Tour durch ein Cloud-Portal. Es geht um den echten Weg von null bis zur laufenden Anwendung: Authentifizierung, Terraform, Managed Services, Kubernetes, Container Registry, Kosten, Qualität und die Stellen, an denen der Ablauf nicht ganz so glatt ist, wie man es sich wünschen würde.

Am Ende steht ein ehrliches Urteil entlang von drei Kriterien: Möglichkeiten, Kosten und Qualität. Was funktioniert gut? Wo ist STACKIT stark? Wo fehlt noch etwas? Und für welche Art von Anwendung lohnt sich der Einsatz wirklich?

Fangen wir dort an, wo viele beim ersten Versuch hängenbleiben: noch bevor die erste Ressource angelegt wird.

Die erste Hürde heißt Authentifizierung

Hier hängen viele beim ersten Versuch und in keinem Marketing-Text steht es besonders prominent: Bevor Terraform auch nur eine einzige Ressource anlegen kann, braucht es eine Identität, mit der es auf STACKIT zugreifen darf.

STACKIT nutzt dafür Service Accounts. Das sind technische Benutzerkonten, die getrennt von Ihrem persönlichen Account funktionieren. Genau solche Accounts verwendet man für Automatisierung: nicht eine Person klickt im Portal, sondern Terraform handelt im Namen dieses Service Accounts.

Der Weg dahin: Im Portal unter IAM → Service Accounts einen Account anlegen, das JSON-Key-File herunterladen. Das ist Ihr privater Schlüssel, den Sie niemals in Git committen sollten. Anschließend weisen Sie dem Account unter IAM → Access eine Rolle zu. Den Pfad zum Key exportieren Sie dann als Umgebungsvariable:

Genau diese Variable sucht der offizielle Terraform-Provider beim terraform apply automatisch. Ist sie korrekt gesetzt und hat der Service Account die passenden Rechte, kann Terraform mit STACKIT sprechen und Ressourcen anlegen.

Die Stolperfalle liegt genau an dieser Stelle: Wenn der Service Account fehlt, die Rolle nicht passt oder der Pfad zum Key-File falsch gesetzt ist, scheitert Terraform bereits vor der ersten Ressource. Die Fehlermeldungen wirken dann schnell kryptisch, vor allem wenn man STACKIT zum ersten Mal verwendet. Genau hier hatte ich als kompletter Neuling meinen ersten Frustmoment.

Die gute Nachricht: Sobald die Authentifizierung einmal sauber eingerichtet ist, verschwindet dieses Problem. Danach läuft sie im Hintergrund mit und wird im weiteren Deployment nicht mehr zum Thema.

Mein erster Fehler: Kubernetes für einen URL Shortener

Die App ist bewusst simpel: Sie geben eine lange URL ein, bekommen einen Short-Code zurück, und der Aufruf leitet weiter. Drei Schichten, wie bei fast jeder Produktiv-App:

• eine PostgreSQL für die Persistenz,
• ein Redis als Cache,
• ein Node.js-Backend für den HTTP-Verkehr.

Aber: Schauen Sie sich an, was dafür nötig war:

• Ein Node-Pool mit Autoscaling-Grenzen,
• ein Namespace,
• Deployments mit requests und limits, sowie
• eine Kubeconfig, die der Terraform-Provider sich erst ziehen muss.

Deshalb kam an einem bestimmten Punkt die ehrliche Frage auf: Brauche ich für einen Dienst, der im Kern nur einen Container ausführt, wirklich eine ganze Orchestrierungs-Maschinerie?

Die Antwort für mein Szenario lautet: nein. Das hier war Overkill.

Was ich eigentlich wollte, war ein simpler Service nach dem Muster „nimm diesen Container und führ ihn aus“, entspannt, ohne Cluster-Verwaltung.

Im Enterprise-Umfeld sieht die Rechnung anders aus: Dort amortisiert sich der K8s-Overhead über viele Dienste, Teams und Skalierungsanforderungen schnell. Für ein einzelnes, kleines Stück Software tut er das selten.

Und das ist nicht nur eine Komfort-Frage, sondern auch eine Kosten-Frage. Ein Cluster bedeutet mindestens einen dauerhaft laufenden Worker-Node, eine VM, die rund um die Uhr abgerechnet wird, egal ob mein Shortener zehn oder zehntausend Requests am Tag bekommt. Für eine Aufgabe, die ein schlanker, nutzungsbasierter Container-Dienst günstiger erledigen würde, zahlen Sie hier die Grundlast einer Orchestrierungs-Plattform mit.

Eine leichtgewichtige Alternative, eine reine Container-Runtime à la „Azure Container Instance“, fehlt bei STACKIT bislang. Und damit sind wir beim Muster, das sich durch den ganzen Plattform-Eindruck zieht und das ich ehrlich gut finde: Lieber eine kleinere Auswahl an Services, die sauber funktionieren, als ein riesiges Portfolio, das nirgends richtig abliefert. Genau das ist auch die Lücke, aber eine, die ich verschmerze, solange das Vorhandene solide ist.

Womit wir bei der nächsten Frage wären: Wie gut fühlt sich diese Plattform eigentlich an, wenn man wirklich damit arbeitet?

Wie es sich anfühlt, mit STACKIT wirklich zu arbeiten

Genau das ist für mich die entscheidende Frage, nicht, wo die Daten liegen, sondern wie reif das Werkzeug ist, das ich täglich in der Hand habe. Und hier hat STACKIT geliefert.

Dass man eine Cloud mit Terraform verwaltet, ist 2026 keine Errungenschaft, sondern die Erwartung. Die ehrliche Frage lautet: Wie gut ist der Provider? Und der offizielle STACKIT-Provider ist gepflegt, sauber und deckt die Ressourcen ab, die man wirklich braucht: Redis, Postgres, Cluster, Deployments, Secrets usw.

Genau hier scheitern andere Anbieter: halbfertige Provider, fehlende Ressourcen, veraltete Versionen. STACKIT verhält sich, wie man es von Terraform gewohnt ist.

Nichts Überraschendes, und genau das ist der Punkt. Der Provider bricht den normalen Terraform-Workflow an keiner Stelle, Sie müssen keine Eigenheiten lernen und bis auf eine Ausnahme (dazu komme ich gleich) keine Workarounds für fehlende Ressourcen bauen.

Dazu eine Dokumentation, die komplett überarbeitet wurden und mittlerweile richtig gut ist.

Mein Fazit an dieser Stelle: Die Plattform fühlt sich nicht wie ein Beta-Versprechen an, sondern wie ein Werkzeug, dem man eine Produktiv-Last anvertraut. Das ist der Grund, warum ich STACKIT nutzen würde.

Managed Services: Der Deal, den niemand thematisiert

Redis und Postgres habe ich beide als Managed Service genommen, nicht selbst betrieben. Der operative Gewinn ist real und unbestritten: kein OS-Patching, kein Replikations-Setup, keine eigene Backup-Mechanik. Genau dafür sind Managed Services da, und das ziehe ich hier auch nicht in Zweifel.

Aber, und das ist die Stelle, an der ich gegen die übliche Begeisterung argumentiere: Jeder Managed Service ist auch eine stille Abhängigkeit. Auch dann, wenn das darunterliegende Produkt Open Source ist, wie Redis oder Postgres. Sie leasen nicht nur die Funktion, Sie leasen die Art, wie sie betrieben, konfiguriert und angebunden wird.

Deshalb der Worst Case, den man durchdenken sollte: Was, wenn ein Managed Service irgendwann nicht mehr ins Gefüge Ihrer Plattform passt, wenn Sie ihn etwa selbst in Kubernetes betreiben möchten oder müssen? Dann richten Sie im Zweifel Architektur und Plattform neu aus.

Das ist kein Argument gegen Managed Services. Es ist ein Argument dafür, die Entscheidung als das zu behandeln, was sie ist: eine Trade-off-Analyse. Vorteile auf der einen Seite, Lock-in und Kontrollverlust auf der anderen. Wer nur die Vorteile sieht, hat die halbe Rechnung gemacht.

Für diesen Stack? Eindeutig die richtige Wahl. Für Ihren? Rechnen Sie nach. Und apropos rechnen, genau das ist der nächste Punkt, der bei „erste App“-Tutorials fast immer fehlt.

Die ehrlichen Kanten und warum ich sie verschmerze

Nicht alles war reibungslos, und ich will nichts schönreden.

Die Container Registry ist noch Beta. Es gibt schlicht keine Terraform-Ressource, um ein Registry-Projekt programmatisch anzulegen. Das ist genau die Art Lücke, die einen aus dem „alles in einem apply“-Flow reißt.

Aber der Workaround ist sauber. Man legt das Registry-Projekt einmalig im Portal an und automatisiert Build und Push danach über den null-Provider, der beliebige Shell-Befehle in den Terraform-Graphen einhängt:

triggers sorgt sogar für ein simples Build-Caching: Ändert sich der Image-Tag nicht, überspringt Terraform den Schritt. Das Ergebnis: docker build und docker push laufen im selben Durchlauf wie der Rest der Infrastruktur. Dass die Registry Beta ist und noch kein Terraform hat, ist blöd, klar. Aber vertretbar. Es gibt einen Workaround, und er hält den gesamten Ablauf stabil.

Der Einstieg hatte Reibung. Als ich komplett neu bei STACKIT war, gab es durchaus Frustmomente. Sobald man aber ein bisschen herumgespielt hat, verschwinden die, danach lief es rund. Das ist ein Onboarding-Thema, kein Plattform-Thema.

Die Bereitstellungsgeschwindigkeit ist okay: Das initiale Setup dauert bis zu 10 Minuten, getrieben vor allem von dem Kubernetes-Cluster, das ein paar Minuten zum Initialisieren braucht. Nicht blitzschnell, aber für einmaliges Provisioning völlig in Ordnung.

Unterm Strich: Das sind die Kanten einer Plattform, die noch wächst, keine, die im Alltag wirklich weh tun. Genau deshalb komme ich beim Fazit wieder auf denselben Punkt zurück.

Selbst ausprobieren: In unter 15 Minuten zur eigenen Instanz

Der komplette Code liegt offen auf GitHub, Sie können den ganzen Stack selbst hochziehen. Lokal läuft er sogar ohne STACKIT-Account:

Für das Deployment in die Cloud brauchen Sie drei Vorbereitungen, und ja, das sind genau die zwei Stolperfallen von oben:

1. Service Account im Portal mit der Rolle project.owner anlegen und Key-JSON herunterladen.
2. Container Registry anlegen, einmalig im Portal, dafür gibt es keine Terraform-Ressource, und einloggen:

3. Auth-Variable setzen:

Danach ist der Rest ein einziger Durchlauf:

Terraform baut und pusht die Docker-Images, provisioniert SKE, PostgreSQL Flex und Redis und deployt Backend und Frontend ins Cluster.

Bei Interesse: Den ganzen Weg habe ich auch als YouTube-Video aufgenommen.

Fazit

Wenn Sie nur eine Sache mitnehmen: Bewerten Sie STACKIT nicht an der Souveränitäts-Folie, sondern an Möglichkeiten, Kosten und Qualität.

Datenhoheit ist ein netter Bonus, kein Kaufgrund. Entscheidend ist, dass die Plattform solide ist: ein gepflegter Terraform-Provider, eine überarbeitete Doku, ein Infrastruktur-Modell, das Abhängigkeiten selbst auflöst, statt Sie Skripte schreiben zu lassen.

Dazu die drei größeren Urteile in Kurzform:

• Möglichkeiten: Das Vorhandene ist solide, aber für eine kleine App war Kubernetes Overkill, und eine leichtgewichtige Container-Runtime fehlt noch. Lieber wenige Services, die abliefern, als viele, die es nicht tun.
• Kosten: Größter Posten bei einer kleinen App ist die Cluster-Grundlast, die sollten Sie bewusst einplanen.
• Qualität: Provider, Dokumentation und das IaC-Zusammenspiel fühlen sich produktionsreif an. Managed Services sind dabei ein Trade-off, kein Free Lunch wie bei allen Providern, riesiger operativer Gewinn, aber Lock-in inklusive, auch bei Open-Source-Produkten.

Die Realität hat meine Erwartung dort übertroffen, wo ich es am wenigsten erwartet hatte: bei der schlichten Reife. Nicht, dass sich alles mit Terraform verwalten lässt, das setze ich voraus, sondern wie sauber der Provider die Ressourcen abdeckt und wie gut die überarbeitete Dokumentation inzwischen ist. Und selbst das eine Beta-Loch, die Registry, lässt sich mit dem null-Provider sauber stopfen, statt den ganzen Ablauf zu sprengen.

Hinweise: 

Den vollständigen Code samt Terraform-Modulen finden Sie in diesem GitHub Repository. Wenn Sie es selbst durchspielen, prüfen Sie vor dem Produktiveinsatz mindestens diese vier Punkte:

• ACLs weg von 0.0.0.0/0,
• Postgres auf replicas = 2 für Failover,
• Images mit Git-SHA statt latest taggen und
• terraform apply in eine CI/CD-Pipeline ziehen statt vom Laptop.

Hier finden Sie weitere Informationen zu STACKIT.

Interessieren Sie sich für weitere Hintergründe oder Serverless Architekturen, dann vereinbaren Sie mit Florian Lenz einen Termin. Er begleitet Sie gerne als strategischer Partner von der Beratung und Analyse über die Konzeption und Architektur bis in die operative Umsetzung.

Wollen Sie Florian Lenz unterstützen oder über STACKIT diskutieren? Dann teilen Sie den Beitrag gerne in Ihrem Netzwerk. 

Florian Lenz hat zwei weitere Beiträge im t2informatik Blog veröffentlicht: