Platform Engineering
Internal Developer Platforms, die Ihre Engineers nutzen und Ihr Team besitzt
Wir bauen produktionsreife Plattformen auf Open Source: Self-Service-Provisioning, Golden Paths und Leitplanken, die durchsetzen. Betrieben auf Ihrer Infrastruktur, in Ihren Repositories, ab dem Tag der Übergabe durch Ihr Team betreibbar.
Das Problem
Ein Integrationsproblem, kein Auswahlproblem
Die Komponenten sind kostenlos und die Referenzarchitekturen sind öffentlich. Daran scheitern Plattforminitiativen nicht.
Sie scheitern an der Integration. Kubernetes, GitOps, ein Portal, Observability, Secrets, Policy, Identity und Templating sind einzeln jeweils überschaubar und zusammen ein sechs- bis zwölfmonatiges Engineering-Projekt, bevor eine einzige Entwicklerin sich irgendetwas selbst provisionieren kann. Sie scheitern am Betrieb, denn diesen Stack aktuell, sicher und upgegradet zu halten, ist eine dauerhafte Verpflichtung, die die meisten Organisationen mit einem Drittel der nötigen Kapazität besetzen. Und sie scheitern an der Akzeptanz, denn eine Plattform, die ohne die Entwicklerinnen und Entwickler gebaut wurde, die sie nutzen sollen, wird umgangen.
Das Symptombild ist immer gleich. Umgebungsanfragen dauern weiterhin Tage. Es gibt ein Portal, aber die eigentliche Arbeit läuft über Tickets. Das Plattformteam ist genau der Engpass, den es beseitigen sollte. Und die ehrliche Antwort auf die Frage, ob die Plattform funktioniert, lautet: Niemand misst es.
Was wir tun
Was wir bauen
Wir bauen Internal Developer Platforms von Anfang bis Ende, und wir bauen sie so, dass sie übergeben werden können.
Self-Service, der die echten Anfragen abdeckt
Kein Katalog für alles, sondern ein funktionierender Self-Service-Pfad für das, worauf Ihre Entwicklerinnen und Entwickler tatsächlich warten: eine Anwendungsumgebung, eine Datenbank, ein Message Broker, ein Namespace mit bereits korrekten Defaults. Bereitgestellt über eine Abstraktion, die Ihr Plattformteam ohne uns erweitern kann.
Golden Paths, die wirklich der schnellste Weg sind
Ein Golden Path funktioniert nur, wenn ihn zu gehen einfacher ist, als ihn zu umgehen. Wir bauen Pfade vom Repository-Template bis zum laufenden Produktions-Workload für Ihre tatsächlichen Anwendungsarchetypen, mit bereits im Pfad erfüllten Anforderungen an Compliance, Sicherheit und Observability, statt sie im Review nachträglich anzuflanschen.
Leitplanken, die durchsetzen
Policy as Code auf Infrastruktur- und Admission-Ebene. Die Regeln, auf die Ihre Security- und Compliance-Funktionen Wert legen, werden automatisch durchgesetzt. Das ist die einzige Art, wie sie im Maßstab halten, und es macht Konformität zu einer Eigenschaft der Plattform statt zu einem Prüfschritt.
Observability als Standard
Eine Entwicklerin kann Metriken, Logs und Traces ihres Dienstes sehen, ohne jemanden zu fragen. Das ist die eine Änderung, die operative Verantwortung am zuverlässigsten nach links verschiebt, und sie ist zugleich die, die die meisten Plattformen aufschieben.
Eine Plattform, die Ihr Team betreiben kann
Alles als Code, in Ihren Repositories, ab dem ersten Commit. Runbooks, geschrieben für Ihre Operatoren. Pairing statt Lieferung. Wir messen die Übergabe daran, ob Ihr Team ein Upgrade eigenständig durchführt, nicht daran, ob die Dokumentation existiert.
Unsere Angebote
Wie wir zusammenarbeiten
Plattformstrategie und Assessment
Ein belegbares Bild davon, wo Sie stehen, was die Reibung Sie kostet und was zuerst gebaut werden sollte.
Ergebnis
Eine bepreiste, priorisierte Roadmap, die Sie budgetieren können.
Plattform-Aufbau
Design und Umsetzung des Plattformfundaments: Control Plane, Provisioning, Golden Paths, Portal, Observability, Policy.
Ergebnis
Eine laufende, produktionsreife Plattform im Besitz Ihres Teams.
Developer-Portal-Enablement
Backstage oder Port, mit gefülltem Katalog, funktionierenden Software-Templates und den Integrationen, die es zum tatsächlichen Startpunkt für Entwickler machen.
Ergebnis
Ein Portal mit echter Nutzung statt eines Verzeichnisses, das niemand öffnet.
Golden Paths und Self-Service-Design
Pfad-Design für Ihre Anwendungsarchetypen, mit den dahinterliegenden Abstraktionen und Templates.
Ergebnis
Der Standardfall dauert Minuten und braucht kein Ticket.
Plattform-Adoption und Enablement
Onboarding Ihrer Produktteams, Messung der Nutzung und Aufbau der Fähigkeiten Ihres Plattformteams.
Ergebnis
Nutzung, die einzige Kennzahl, die nach dem Go-live zählt.
Plattformbetrieb
Day-2-Verantwortung mit vereinbartem Service Level, damit Ihre Engineers an der Developer Experience arbeiten statt an Upgrade-Zyklen.
Ergebnis
Eine Plattform, die aktuell bleibt, ohne Ihr Team zu binden.
Arbeitsweise
Wie wir arbeiten
Wir bauen mit Ihrem Team, nicht an seiner Stelle
Ihre Platform Engineers sind fest in den Aufbau eingebunden. Das ist eine Bedingung der Zusammenarbeit und kein Nice-to-have, denn eine Plattform, die Ihr Team erbt, ist eine Plattform, die Ihr Team ablehnt.
Wir starten bei Ihren Entwicklerinnen und Entwicklern
Die erste Arbeit besteht darin zu verstehen, worauf Ihre Engineers tatsächlich warten, und nicht, was eine Referenzarchitektur ihnen unterstellt. Die relevante Reibung ist spezifisch für Ihre Organisation, und sie liegt meist nicht dort, wo die Führung sie vermutet.
Wir messen
Baseline davor, Messung danach: Durchlaufzeit, Deployment-Frequenz, Provisioning-Dauer, Self-Service-Abdeckung und Nutzung. Eine Plattforminitiative ohne Baseline kann ihren Wert nicht belegen und verliert im zweiten Budgetzyklus ihre Finanzierung.
Wir wählen langweilig, standardisiert, offen
Wir nutzen die Komponenten mit den stärksten Ökosystemen und den klarsten Ausstiegswegen. Wo ein kommerzielles Produkt wirklich gewinnt, sagen wir das. Wo eine Open-Source-Komponente gewinnt, setzen wir sie ein und helfen, sie zu pflegen, wenn es für Sie relevant ist.
Jedes Architekturdokument benennt den Ausstiegsweg für jede Komponente. Wenn eine Komponente dadurch schlecht aussieht, ist das eine nützliche Information zur Designzeit.
Was Sie erhalten
Was Sie erhalten
Plattformarchitektur mit dokumentierten Komponentenentscheidungen, verworfenen Alternativen und Ausstiegswegen
Die laufende Plattform, auf Ihrer Infrastruktur, über Ihre Umgebungen hinweg
Die gesamte Konfiguration als Code in Ihren Repositories, ab dem ersten Commit
Golden Paths durchgängig dokumentiert
Self-Service-Abstraktionen, die Ihr Team erweitern kann
Betriebs-Runbook: Routinebetrieb, Upgrades, Fehlerbilder, Eskalation
Dokumentation für Entwicklerinnen und Entwickler
Baseline- und Nachher-Metriken
Ein Adoptionsplan mit Reihenfolge und den zu beobachtenden Kennzahlen
Wo das im Stack sitzt
Teil eines größeren Bildes
Platform Engineering ist die Methode, aber sie erbt Randbedingungen von unten und ermöglicht Workloads darüber. Eine Plattform, die ohne Blick darauf gebaut wird, wo sie laufen soll, erzeugt ein Souveränitätsproblem, das Sie erst bei einer Migration entdecken. Eine Plattform, die ohne Pfad für KI-Workloads gebaut wird, erzeugt eine Schattenplattform, sobald Ihr erster KI-Anwendungsfall in Produktion geht.
Wir bauen Plattformen, die beides berücksichtigen.
Angebotspakete
Starten Sie mit einem definierten Schritt
3 Wochen
Platform Engineering Maturity Assessment
In drei Wochen wissen, was Ihre Developer-Plattform tatsächlich kostet, wo sie Ihre Engineers ausbremst und was zuerst zu beheben ist.
3 Wochen
Kubernetes Security Review
In drei Wochen zu einem priorisierten, belegten Bild davon, wie Ihre Kubernetes-Cluster tatsächlich dastehen – bewertet gegen anerkannte Benchmarks und gegen einen Angreifer, der bereits Fuß gefasst hat.
8 Wochen
IDP Foundation Sprint für eine produktionsreife Plattform
Eine funktionierende Internal Developer Platform in acht Wochen. Open Source, in Ihrer Umgebung betrieben, im Besitz Ihres Teams, ohne Lock-in.
FAQ
Fragen, die uns gestellt werden
Wir haben bereits ein Plattformteam. Was bringen Sie zusätzlich?
In der Regel Kapazität und Musterwissen, keinen Ersatz. Die meisten Plattformteams sind fachlich stark und personell unterversorgt, und sie lösen Probleme, die anderswo bereits gelöst wurden. Wir bringen die Referenzimplementierungen und die Integrationsarbeit, Ihr Team behält Kontext und Verantwortung. Wenn Ihr Team uns nicht dabeihaben will, funktioniert die Zusammenarbeit nicht, und das klären wir lieber früh.
Sollten wir bauen oder kaufen?
Das hängt davon ab, worauf Sie optimieren, und die ehrliche Antwort ist meist eine Mischung. Kommerzielle Produkte gewinnen bei der Zeit bis zum ersten Nutzen und auf der Portalebene. Open Source gewinnt bei Kontrolle, Kosten im Maßstab und Ausstieg. Unser Reifegrad-Assessment gibt Ihnen eine Empfehlung je Fähigkeit, und wir haben keinen Anreiz in die eine oder andere Richtung, weil wir nicht weiterverkaufen.
Wie lange dauert es, bis Entwickler etwas sehen?
Ein achtwöchiger Foundation-Sprint stellt einem Pilotteam bis Woche 6 einen funktionierenden Golden Path bereit. Die erste breite Nutzungswelle folgt typischerweise innerhalb eines Quartals. Wer organisationsweite Nutzung in acht Wochen verspricht, beschreibt eine Installation, keine Adoption.
Wir sind bereits auf Kubernetes. Ist das trotzdem relevant?
Kubernetes ist die Laufzeitumgebung, nicht die Plattform. Die meisten Organisationen, mit denen wir arbeiten, haben Kubernetes seit Jahren und lassen Entwickler weiterhin tagelang auf Umgebungen warten, weil die Ebenen Self-Service, Golden Path und Leitplanken nie gebaut wurden.
Was passiert, wenn wir den Betrieb wieder ins Haus holen wollen?
Sie übernehmen ihn. Alles liegt in Ihren Repositories, auf Open Source und Standardwerkzeugen, und es gibt nichts Proprietäres zu entflechten. Wir unterstützen den Übergang, und das steht im Vertrag und nicht nur auf einer Website.
Wo steht Ihre Plattform heute?
Ob Sie drei Jahre oder drei Wochen dabei sind, das erste nützliche Gespräch ist dasselbe: Worauf warten Ihre Entwicklerinnen und Entwickler tatsächlich, und was kostet Sie das.