Platform
Engineering

Das Problem

Ihre Entwicklerinnen und Entwickler sind gut. Sie könnten schneller liefern. Tun sie aber nicht, weil sie die halbe Woche damit verbringen, gegen die Infrastruktur anzukämpfen.

Deployments laufen manuell oder halbmanuell. Jemand klickt sich durch ein Jenkins-UI, führt ein Skript aus, das nur eine Person versteht, oder eröffnet ein Ticket und wartet, bis Ops es bearbeitet. Einen neuen Service aufzusetzen heißt, die Konfiguration eines anderen Services zu kopieren und zu hoffen, dass alle relevanten Werte angepasst wurden. Secrets liegen in einem geteilten Passwort-Manager – oder schlimmer, fest im Code. Umgebungen driften auseinander, weil niemand mehr weiß, was letzten Donnerstag in Staging geändert wurde.

Das liegt nicht daran, dass Ihr Team schlecht ist. Es liegt daran, dass nie Zeit war, die Infrastruktur zu bauen, die alles andere einfacher macht. Es gibt immer ein Feature, das raus muss, einen Bug, der zu fixen ist, eine Deadline, die zu halten ist. Platform-Arbeit wird auf "nächstes Quartal" verschoben.

Wir sind das Team, das die Plattform für nächstes Quartal jetzt baut.

Was wir bauen

Developer Platforms

Ein zentraler Ort, an dem Ihr Engineering-Team Umgebungen provisioniert, Services deployt, Logs einsieht, sieht was läuft und versteht, wie alles zusammenhängt. Kein Kubernetes-Dashboard, das niemand benutzt – eine Developer Experience, die tatsächlich auf die Bedürfnisse Ihres Teams zugeschnitten ist.

Das kann so schlank sein wie ein gut strukturiertes CLI mit einer Reihe von Templates, oder so umfassend wie ein vollwertiges Internal Developer Portal auf Basis von Backstage. Wir finden heraus, was Ihr Team wirklich braucht (in der Regel weniger, als Sie denken) und bauen genau das.

CI/CD-Pipelines

Automatisierte Build-, Test- und Deploy-Pipelines, die bei jedem Pull Request und jedem Merge laufen. Ihre Entwicklerinnen und Entwickler pushen Code, die Pipeline erledigt den Rest – Linting, Tests, Build, Deployment in die richtige Umgebung. Keine manuellen Schritte, keine "Kannst du das mal für mich deployen?"-Nachrichten in Slack.

Wir bauen sie schnell (niemand wartet gerne 20 Minuten auf eine Pipeline), zuverlässig (flaky Tests werden gefixt, nicht ignoriert) und nachvollziehbar (Ihr Team kann eine fehlgeschlagene Pipeline debuggen, ohne uns anzurufen).

GitOps-Workflows

Ihre Infrastruktur- und Anwendungskonfiguration liegt in Git. Änderungen laufen über Pull Requests. Deployments passieren automatisch beim Merge. Wenn etwas schiefgeht, sehen Sie genau, was sich geändert hat, und können es zurückrollen.

Das ist nicht nur ein nettes Konzept – es ist der Hebel mit dem größten Effekt auf die Deployment-Zuverlässigkeit. Wenn die Antwort auf "Was hat sich geändert?" immer "Schau ins Git-Log" lautet, wird Debugging dramatisch einfacher.

In der Regel setzen wir ArgoCD für Kubernetes-basiertes GitOps ein, passen uns aber an Ihr Setup an.

Secrets Management

Secrets, die automatisch rotiert werden, auf die Services beschränkt sind, die sie brauchen, und nie an Stellen liegen, an denen Menschen sie versehentlich leaken. Keine geteilten ".env"-Dateien mehr, keine Secrets in Slack-DMs, kein "Ich glaube, der API-Key liegt irgendwo in 1Password."

Wir setzen sauberes Secrets Management auf (üblicherweise eine Kombination aus Kubernetes-nativen Secrets, External Secret Operators und dem Vault Ihres Cloud-Providers) und integrieren es so in Ihre Deployment-Pipeline, dass Ihre Entwicklerinnen und Entwickler nicht darüber nachdenken müssen.

Environment Management

Konsistente, reproduzierbare Umgebungen, die in Development, Staging und Production gleich funktionieren. Eine neue Umgebung in Minuten hochziehen, nach Gebrauch wieder einstampfen. Kein "Bei mir läuft's aber" mehr und keine Staging-Umgebungen, die seit einem halben Jahr nicht aktualisiert wurden.

Wie wir vorgehen

Wir kommen nicht mit einem Blueprint und installieren ihn. Jedes Team ist anders – andere Größe, andere Skills, andere Pain Points, andere Veränderungsbereitschaft. Wir starten damit zu verstehen, wo Sie stehen und wo es wirklich wehtut.

Schritt 1: Den Ist-Zustand verstehen

Wir verbringen Zeit mit Ihren Engineers. Nicht nur mit dem Lead – mit den Leuten, die jeden Tag Code schreiben. Wir schauen zu, wie sie deployen, debuggen, neue Services aufsetzen, wo sie hängen bleiben. Wir sehen uns Ihre bestehenden Pipelines an, Ihre Infrastruktur, Ihr Monitoring, Ihre Incident-Historie.

Ziel ist es, die Engpässe zu finden, die am meisten Zeit kosten. Nicht die, die spektakulär klingen, wenn man sie behebt – sondern die, an denen Ihr Team tatsächlich jede Woche Stunden verliert.

Schritt 2: Die Plattform entwerfen

Auf Basis dessen, was wir vorfinden, entwerfen wir einen Zielzustand, der zur Größe und den Skills Ihres Teams passt. Wir schlagen keinem 10-köpfigen Engineering-Team eine Netflix-Plattform vor. Wir schlagen die kleinste Menge an Änderungen vor, die die größte Verbesserung bringt.

Das präsentieren wir als Roadmap mit klaren Phasen. Phase eins muss in Wochen lieferbar sein, nicht in Monaten, und sie muss sofort einen spürbaren Unterschied machen.

Schritt 3: Iterativ bauen

Wir bauen in Phasen, beginnend mit den Themen mit der größten Wirkung. Üblicherweise zuerst CI/CD und GitOps, weil sie jede Entwicklerin und jeden Entwickler bei jedem Deployment betreffen. Danach Secrets Management, Environment Tooling und Developer-Portal-Funktionen, sobald die Plattform reift.

Nach jeder Phase prüfen wir: Macht das Ihr Team tatsächlich schneller? Wird es genutzt? Was ist noch schmerzhaft? Die Plattform entwickelt sich auf Basis echten Feedbacks weiter, nicht auf Basis von Annahmen.

Schritt 4: Übergeben und befähigen

Die Plattform ist nur dann nützlich, wenn Ihr Team sie besitzt. Wir dokumentieren alles, wir pairen mit Ihren Engineers, und wir sorgen dafür, dass mindestens zwei bis drei Personen in Ihrem Team das Gebaute warten und erweitern können. Wir wollen nicht, dass Sie uns ewig brauchen – das ist für keine Seite eine gesunde Beziehung.

Wo Teams typischerweise stehen, wenn sie uns anrufen

Wir sehen ein paar wiederkehrende Muster:

"Wir deployen über SSH und Skripte."

Sie brauchen die Grundlagen: containerisierte Deployments, eine CI-Pipeline und ein sauberes Environment-Setup. Das ist üblicherweise ein Engagement von 4–6 Wochen, und der Unterschied ist Tag und Nacht.

"Wir haben CI/CD, aber es ist fragil und langsam."

Die Pipelines existieren, aber sie sind flaky, langsam, oder niemand vertraut ihnen. Entwicklerinnen und Entwickler arbeiten an ihnen vorbei, statt sich auf sie zu verlassen. Wir reparieren die Grundlagen – Caching, Parallelisierung, Test-Stabilität, Pipeline-Architektur – und machen daraus etwas, auf das sich das Team tatsächlich stützt.

"Wir haben Kubernetes, aber die Entwickler fassen es nicht an."

Sie haben in Kubernetes investiert, aber die Komplexität ist bei einer oder zwei Personen konzentriert. Alle anderen haben Angst zu deployen. Wir bauen die Abstraktionsschicht – Templates, Pipelines, ein Portal – die Kubernetes für Ihr gesamtes Team nutzbar macht, nicht nur für die Infrastruktur-Spezialisten.

"Wir wollen einen Golden Path."

Sie haben eine reife Engineering-Organisation und wollen eine opinionierte, self-service-fähige Developer Platform: einen neuen Service aus einem Template erstellen, ihn mit einem Befehl nach Staging deployen, per PR in Production promoten. Wir bauen die Plattform, die Templates und die Dokumentation, die das real macht.

Egal wo Sie starten – das Ziel ist immer dasselbe: Ihre Engineers verbringen ihre Zeit damit, Produkt zu bauen, statt mit der Infrastruktur zu ringen.

Die technische Seite

Für die Engineers unter den Lesenden – das ist unser üblicher Stack:

Container-Orchestrierung: Kubernetes. Wir betreiben es auf Managed Services (AKS, EKS, GKE) oder auf Bare Metal mit Talos Linux, je nach Anforderung.

GitOps: ArgoCD für das Application Delivery, mit Kustomize oder Helm zum Templating. Konfiguration liegt in Git, Deployments sind deklarativ, Drift wird automatisch reconciled.

CI/CD: GitHub Actions in den meisten Projekten. GitLab CI, wenn das Ihre Welt ist. Wir halten Pipelines modular und wiederverwendbar – Shared Workflows, kein kopiertes YAML über 30 Repos verteilt.

Secrets: External Secrets Operator angebunden an Ihren Cloud-Vault (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Secrets werden zur Laufzeit injiziert, nie in Images oder Konfigurationsdateien gebacken.

Developer Portal: Backstage, wenn die Teamgröße es rechtfertigt (üblicherweise ab 20 Entwicklerinnen und Entwicklern). Für kleinere Teams funktionieren ein gut dokumentierter Satz Templates, ein CLI-Tool und solide README-Dateien oft besser.

Monitoring & Observability: Wir stellen sicher, dass Ihre Plattform vom ersten Tag an observable ist. Prometheus für Metriken, Grafana für Dashboards, strukturiertes Logging mit zentralem Aggregationspunkt. Wir bauen kein Monitoring-System – wir sorgen dafür, dass Ihre Plattform bereit für eines ist.

Wenn Ihr Stack anders aussieht, ist das in Ordnung. Das sind unsere Defaults, nicht unsere Anforderungen. Wir arbeiten mit dem, was Sie haben, und migrieren dort hin, wo es sinnvoll ist.

Für wen das ist

Das passt gut, wenn:

• Ihre Entwicklerinnen und Entwickler mehr Zeit mit Deployment-Mechanik als mit Feature-Entwicklung verbringen
• Sie Kubernetes eingeführt haben, aber die Developer Experience drumherum noch holprig ist
• Ihre CI/CD-Pipeline von jemandem gebaut wurde, der das Unternehmen verlassen hat, und niemand sie vollständig versteht
• Sie von 5 auf 20 Engineers wachsen und die informellen Prozesse anfangen zu brechen
• Sie schneller werden wollen, ohne ein dediziertes Platform-Team einzustellen

Es passt weniger gut, wenn:

• Sie ein sehr frühes Team mit ein bis zwei Entwicklerinnen oder Entwicklern sind – Sie brauchen vermutlich noch keine Plattform, sondern nur gute Defaults. Die richten wir Ihnen in ein bis zwei Tagen ein.
• Sie Infrastruktur-Management brauchen, aber keine Verbesserungen der Developer Experience – das ist eher klassisches DevOps-Consulting, und während wir das auch können, ist es nicht unsere Kernstärke.