# Platform Engineering [Platform Engineering](https://iits-consulting.de/de/services/cloud-devops/platform-engineering) ## Platform Engineering Die meisten internen Plattformen werden einmal gebaut und dann still und leise aufgegeben, weil sie als Infrastrukturprojekt konzipiert wurden statt als Produkt mit Nutzern. Unsere eigene Plattform haben wir als Produkt gebaut. KumoOps läuft über mehrere Clouds hinweg für Kunden, die monatlich dafür bezahlen. Das ist ein härterer Test, als ihn ein interner Rollout je sein kann. Ihre Plattform bauen wir nach demselben Prinzip. [Kontakt aufnehmen](https://iits-consulting.de/de/contact/index.md) [Kostenloser Cloud-Architektur-Workshop](https://iits-consulting.de/de/cloud-architecture-workshop/index.md) Unsere Technologiepartner ## Kunden die unseren Engineering Teams vertrauen: Deutsche Telekom Uniper GOLDBECK PwC Vattenfall Schwarz Gruppe Cornelsen Meridiam ## Was genau ist Platform Engineering? Eine Plattform ist die Gesamtheit der Standardvorgaben, die Entwickler erhalten, ohne danach fragen zu müssen: wie ein Service erstellt wird, wo er läuft, wie er in die Produktion gelangt, wer ihn sehen kann und was passiert, wenn er ausfällt. Platform Engineering ist die Disziplin, diese Standardvorgaben bewusst zu gestalten, sie als Produkt zu behandeln und Verantwortung dafür zu übernehmen, ob jemand sie tatsächlich nutzt. Der Maßstab ist nicht, wie viel die Plattform leisten kann. Er ist, wie viel ein Entwickler nicht mehr wissen muss. Jede Funktion, die Sie hinzufügen, nimmt ihm entweder Entscheidungen aus dem Alltag, oder erhöht die Last, die er ohnehin schon trägt. ### Self-Service – oder es ist nur eine Ticket-Queue mit besserem Branding Ein Team fordert eine Datenbank an und bekommt sie in Minuten: verschlüsselt, gesichert und der richtigen Kostenstelle zugeordnet. Was dafür alles nötig war, muss das Team nicht wissen. Diese Standardeinstellungen wurden einmal in Ruhe und mit Sorgfalt festgelegt, für alle. Der Test: Wenn die Nutzung der Plattform erfordert, die Plattform zu verstehen, sitzt die Abstraktion an der falschen Stelle. ### Plattformen wachsen. Sie werden nicht schlanker Jede Ausnahme wird zur dauerhaften Funktion, und bei jeder Migration läuft der alte Pfad neben dem neuen weiter. Nach drei Jahren verlangt die Plattform, die Entscheidungen reduzieren sollte, mehr davon als die Cloud darunter. Die kognitive Last ist lediglich umgezogen. Der Kern der Arbeit liegt deshalb in zwei Entscheidungen: was gar nicht erst gebaut wird und was zu einem festen Datum abgekündigt wird. ### Ihre Plattform hat neue Nutzer – und die lesen das Wiki nicht Coding-Agenten öffnen Pull Requests, provisionieren Infrastruktur und lösen Deployments aus. Sie kennen weder die Vorgeschichte noch den Ausfall, der zu einer Regel geführt hat, und wissen nicht, welcher Ihrer drei Deployment-Pfade der vorgesehene ist. Sie nutzen jede Schnittstelle, die sie erreichen, in einem Tempo, für das kein Review-Prozess ausgelegt ist. Damit werden Leitplanken selbst zur Schnittstelle. Was bisher eine Richtlinie war, an die sich die meisten gehalten haben, muss bei Agenten technisch durchgesetzt werden. Und der Golden Path muss der Weg sein, der sich am einfachsten aufrufen lässt. ### Wir machen das öffentlich Unsere Engineers publizieren auf platformengineering.org, unterrichten unseren eigenen Platform-Engineering-Kurs, halten Gastvorlesungen und nehmen an der PlatformCon teil. Wir sind ein zertifizierter Service-Provider mit mehr als zwölf zertifizierten Platform Engineers. Und wir betreiben KumoOps, unser eigenes Plattformprodukt, über mehrere Clouds hinweg für langfristige Kunden. Die kostspieligen Abstraktionsfehler haben wir auf unsere eigene Rechnung gemacht. ## Warum diese Plattform genutzt wird ### Weniger zu wissen, nicht mehr zu bedienen Wir messen, wie lange ein neuer Service vom Repository bis in die Produktion braucht und wie viele Standardeinstellungen Entwickler selbst vornehmen müssen, einmal zu Beginn und einmal bei der Übergabe. ### Eine Minimal Viable Platform, kein Zwei-Jahres-Programm Ein Golden Path, ein echtes Team, früh in Produktion, solange sich das Design noch günstig ändern lässt. ### Verantwortlichkeiten bewusst festgelegt Wer was behebt, legen wir schon im Design fest, lange vor dem ersten fehlgeschlagenen Upgrade. ### Leitplanken, die halten, wenn der Aufrufer kein Mensch ist Policy as Code und erzwungene Standardeinstellungen, damit ein Agent dieselbe Antwort erhält wie Ihr erfahrenster Engineer. ### Sie können aufhören und stattdessen unsere nutzen Wenn der Aufbau einer eigenen Plattform sich nicht lohnt, sagen wir das. KumoOps ist die Alternative – und wir verkaufen Ihnen lieber die richtige. [Projektanfrage](https://iits-consulting.de/de/contact/index.md) ## Prozessschritte ### Sprechen Sie mit den Entwicklern, nicht mit der Infrastruktur. Wir zählen die Entscheidungen zwischen Idee und Produktion, auch die, die falsch getroffen und später korrigiert wurden. Schritt 01 ### Definieren Sie die Minimum Viable Platform Das Kleinste, das einen echten Workflow verbessert, plus eine Baseline, damit der Mehrwert messbar statt diskutierbar ist. Schritt 02 ### Liefern Sie es an ein Team aus Produktion, echter Traffic, echter Support. Erste Nutzer finden in Wochen, was ein Design-Review ein Jahr lang übersieht. Schritt 03 ### Betreiben Sie es als Produkt Roadmap, Intake, Versionierung, Abkündigung. Danach übernimmt Ihr Team, oder KumoOps kümmert sich um den Betrieb. Schritt 04 ## Bereiche, in denen wir unterstützen ### Telekommunikation Hunderte interner Teams, bei denen sich ein einziger schlechter Standardwert schneller verbreitet, als ihn jemand korrigieren kann. ### Energie & Versorgung Aufgabentrennung als Plattform-Fähigkeit, sodass der geprüfte Weg und der schnelle Weg identisch sind. ### IT & Digitale Dienste Developer Experience als Wettbewerbsfaktor, denn Ihre Ingenieure sind das Produkt. ### Öffentlicher Sektor Eine Plattform für viele Organisationseinheiten, auf souveräner Infrastruktur, mit integrierten Nachweisen. iits-consulting helped us build a robust and flexible cloud on the OpenTelekomCloud. They possess strong cloud-native expertise and utilize modern technologies. The workshop was clear and practical, and the subsequent consulting guided us step by step. They provided highly experienced consultants who were genuinely committed to helping us and sought the best solutions for our challenges. We highly recommend iits-consulting for training, consulting, and a robust cloud solution. Karsten Brusch Senior Cloud Architect Cornelsen ## Womit wir arbeiten. Nichts davon ist exotisch, und das ist Absicht. Ihre Teams sollen alles nach unserem Einsatz selbst betreiben können, und passende Fachkräfte dafür sollten leicht zu finden sein. PLATFORM CORE - Kubernetes - Terraform - OpenTofu - Helm - Argo CD - Crossplane - Operators DEVELOPER CONTROL PLANE - Service Catalog - Gold Paths - Self-Service Provisioning - Scaffolding Templates - Portal - Agent-facing APIs GOVERNANCE & OPERATIONS - Kyverno - Keycloak - Vault - OpenTelemetry - Grafana - Kostenzuordnung pro Team ## Bauen Sie eine Plattform auf oder betreiben Sie die Infrastruktur aller? Zwei Wochen, Interviews mit Ihren Teams, ein abgestecktes MVP und eine ehrliche Antwort, ob Sie überhaupt eine bauen sollten. Unverbindlich. [Kontakt aufnehmen](https://iits-consulting.de/de/contact/index.md) [Unsere Arbeit ansehen](https://iits-consulting.de/de/our-work/index.md)