Port, Humanitec oder selbst bauen?

“Sollen wir Humanitec, Port, oder etwas Eigenes bauen?” Es gibt keine allgemeingültige Antwort auf diese Frage. Aber es gibt Faktoren, die sie deutlich machen — und der wichtigste steht ganz am Anfang.

Zuerst: Was ist das eigentliche Problem? Internal Developer Platforms sollen die kognitive Last für Infrastrukturentscheidungen senken. “Wie deploye ich meinen Service?” “Wie bekomme ich eine Datenbank?” “Wo sind meine Logs?” Wenn Entwickler diese Fragen ohne Platform-Team-Ticket beantworten können, funktioniert die IDP. Welche Fragen das bei euch konkret sind, entscheidet die Tool-Wahl mehr als jedes Feature-Sheet — ein Portal löst Sichtbarkeitsprobleme, ein Orchestrator löst Provisionierungsprobleme. Das sind verschiedene Baustellen.

Port: das konfigurierbare Portal

Port ist ein metadata-getriebenes Developer-Portal. Das Datenmodell sind Blueprints: Du definierst Entitätstypen (Service, Cluster, Datenbank, Team) und ihre Beziehungen, und Integrationen befüllen den Katalog aus GitHub, Kubernetes, Datadog, PagerDuty und so weiter. Darauf setzt du Self-Service-Actions (“neuen Service anlegen”, “Staging-Umgebung anfordern”), die im Hintergrund eure eigene Automatisierung triggern — typischerweise einen GitHub-Actions-Workflow oder eine Pipeline, die ihr sowieso schon habt. Dazu kommen Scorecards: Regeln wie “jeder Production-Service hat einen Owner, ein Runbook und Readiness Probes”, deren Erfüllungsgrad pro Service sichtbar ist.

Die ehrliche Einordnung: Port ist fast ein Low-Code-Baukasten für Portale. Die Flexibilität ist real, aber sie bedeutet auch, dass ihr das Datenmodell entwerft, die Actions baut und die Backends dafür betreibt. Port zeigt an und stößt an — provisioniert wird woanders. Wer glaubt, mit dem Kauf sei die Plattform fertig, kauft ein leeres Regal.

Humanitec: der opinionierte Orchestrator

Humanitec greift tiefer in den Deployment-Pfad ein. Entwickler beschreiben ihren Workload mit Score, einer workload-zentrierten Spezifikation: “mein Service braucht eine PostgreSQL-Datenbank und einen DNS-Namen” — ohne festzulegen, wie das in AWS oder GCP umgesetzt wird. Der Platform Orchestrator löst diese Abhängigkeiten zur Deploy-Zeit über Resource Definitions auf, die das Platform-Team pflegt: In Dev wird daraus ein Container mit Postgres, in Prod eine RDS-Instanz mit den richtigen Subnetzen und Backups.

Das ist konzeptionell sauber und nimmt App-Teams echte Entscheidungen ab. Der Preis: Humanitec sitzt mitten im Deployment-Weg. Eure bestehenden Helm-Charts, GitOps-Flows und Pipelines müssen sich dem Modell anpassen, nicht umgekehrt — die Migration ist ein Projekt, kein Wochenende. Und ihr holt euch eine externe Abhängigkeit an eine Stelle, an der ein Ausfall bedeutet, dass niemand mehr deployen kann. Das kann man verantworten, aber man sollte es bewusst tun.

Backstage und Eigenbau: volle Kontrolle, voller Preis

Backstage gibt dir Software-Katalog, Templates und TechDocs als Open-Source-Framework — und überlässt dir alles andere. Plugins schreiben oder anpassen heißt React und TypeScript, das Datenmodell pflegen heißt YAML-Disziplin in jedem Repo, und der laufende Betrieb ist ein eigenes Produkt mit eigenem Backlog. Realistisch bindet ein ernsthaftes Backstage-Setup dauerhaft ein bis zwei Engineers, nicht einmalig. Warum viele Backstage-Einführungen trotz guter Technik an der Adoption scheitern, haben wir in Backstage: Software Catalog Adoption aufgeschrieben.

Richtig ist Eigenbau für Organisationen mit Workflows, die kein Produkt abbildet, und mit der Teamgröße, das zu tragen. Falsch ist er für Teams, die “wir bauen das selbst” auf die Anfangsinvestition runterrechnen und die Wartung vergessen.

Wie man die Entscheidung strukturiert

Ein paar Orientierungslinien, die sich in der Praxis bewährt haben:

• Unter etwa zehn Engineers im Plattformbereich ist Build-it-yourself riskant — die Kapazität, ein IDP-Produkt zu entwickeln und zu warten, fehlt schlicht. SaaS kaufen, Energie in Golden Paths stecken.
• Ist das Problem Sichtbarkeit und Self-Service-Einstieg (wer owned was, wie lege ich einen Service an), passt ein Portal wie Port oder Backstage.
• Ist das Problem Infrastruktur-Provisionierung (Teams warten Tage auf Datenbanken und Umgebungen), braucht ihr Orchestrierung — Humanitec, oder Kubernetes-native mit Crossplane Compositions als Plattform-API und einem dünnen Portal davor.
• Vendor-Lock-in ehrlich bewerten: Bei Port verliert ihr im Exit-Fall ein Frontend, eure Automatisierung bleibt. Bei Humanitec verliert ihr den Deployment-Mechanismus selbst.

Im Interview ist diese Frage übrigens ein Klassiker für System-Design-Runden — und die erwartete Antwort ist nie ein Produktname, sondern eine Abwägung entlang von Teamgröße, Problemtyp und Betriebsverantwortung. Wie man so ein Gespräch aufbaut, zeigt System Design: Internal Developer Platform.

Keine der Optionen macht das Wichtigste für euch: mit Entwicklern reden, verstehen, wo sie tatsächlich Zeit verlieren, und nach drei Monaten messen, ob das Tool genutzt wird. Die beste Plattform ist die, die Adoption findet — alle drei Wege können dahin führen, und alle drei können scheitern. Einen strukturierten Vergleich der Optionen findest du im Lernpfad IDP-Alternativen.