Zum Inhalt springen

Platform Engineering: Entwicklerplattformen, die skalieren

Entwirf interne Entwicklerplattformen, die Infrastruktur abstrahieren, Self-Service bieten, kognitive Last senken und Delivery beschleunigen.

4 Min. Lesezeit
Architektur einer internen Entwicklerplattform mit Self-Service-Portal, Plattform-APIs und Infrastruktur-Abstraktionen

DevOps versprach: „Du baust es, du betreibst es." In der Praxis bedeutet das, dass jedes Anwendungsteam Expertise in Kubernetes, Terraform, CI/CD-Pipelines, Observability und Security-Scans braucht. Platform Engineering bietet eine andere Antwort: eine kuratierte Self-Service-Plattform aufbauen, die die Komplexität der Infrastruktur übernimmt, damit sich Anwendungsteams auf die Wertschöpfung fürs Geschäft konzentrieren können.

Der entscheidende Unterschied ist, dass Plattformteams Produkte für Entwickler bauen, keine Tickets für Entwickler.

Die Plattform als Produkt

Die Plattform als Produkt zu behandeln bedeutet, die eigenen Nutzer (die Entwickler), ihre zu erledigenden Aufgaben zu verstehen und zu messen, ob die Plattform ihren Workflow tatsächlich verbessert.

tstypescript
interface PlatformCapability {
  name: string;
  selfService: boolean;
  currentState: "manual" | "semi-automated" | "fully-automated";
  developerFriction: "high" | "medium" | "low";
  usage: number; // requests per week
}
 
const platformCapabilities: PlatformCapability[] = [
  {
    name: "Create new service",
    selfService: false,
    currentState: "manual",
    developerFriction: "high",
    usage: 5,
  },
  {
    name: "Deploy to production",
    selfService: true,
    currentState: "fully-automated",
    developerFriction: "low",
    usage: 200,
  },
  {
    name: "Provision database",
    selfService: false,
    currentState: "manual",
    developerFriction: "high",
    usage: 8,
  },
  {
    name: "Add monitoring dashboard",
    selfService: false,
    currentState: "semi-automated",
    developerFriction: "medium",
    usage: 15,
  },
  {
    name: "Rotate secrets",
    selfService: true,
    currentState: "fully-automated",
    developerFriction: "low",
    usage: 30,
  },
];
 
// Prioritize by friction × frequency
function prioritizeCapabilities(
  capabilities: PlatformCapability[]
): PlatformCapability[] {
  const frictionScore = { high: 3, medium: 2, low: 1 };
 
  return [...capabilities].sort((a, b) => {
    const scoreA = frictionScore[a.developerFriction] * a.usage;
    const scoreB = frictionScore[b.developerFriction] * b.usage;
    return scoreB - scoreA;
  });
}

Service-Templates und Golden Paths

Das wirkungsvollste Plattform-Feature ist das Service-Scaffolding. Statt tagelang von bestehenden Services zu kopieren, einzufügen und die Konfiguration zu reparieren, erhalten Entwickler in wenigen Minuten einen produktionsreifen Service.

tstypescript
// ❌ The copy-paste-and-pray approach
// 1. Clone existing service repo
// 2. Rename everything (miss some references)
// 3. Update CI/CD config (copy wrong secrets)
// 4. Modify Kubernetes manifests (break resource limits)
// 5. Change database config (point to wrong cluster)
// 6. Spend 3 days debugging why deployment fails
tstypescript
// ✅ Platform-provided service templates
interface ServiceTemplate {
  name: string;
  language: string;
  includes: string[];
  parameters: TemplateParameter[];
}
 
interface TemplateParameter {
  name: string;
  description: string;
  type: "string" | "select" | "boolean";
  options?: string[];
  defaultValue?: string;
  required: boolean;
}
 
const templates: ServiceTemplate[] = [
  {
    name: "Node.js API Service",
    language: "typescript",
    includes: [
      "Express server with health checks",
      "OpenTelemetry instrumentation",
      "Structured logging (pino)",
      "Dockerfile with multi-stage build",
      "Kubernetes manifests (deployment, service, HPA)",
      "CI/CD pipeline (build, test, deploy)",
      "Grafana dashboard template",
      "Alert rules for SLOs",
      "README with runbook links",
    ],
    parameters: [
      {
        name: "serviceName",
        description: "Name of the service (lowercase, hyphens)",
        type: "string",
        required: true,
      },
      {
        name: "team",
        description: "Owning team",
        type: "select",
        options: ["payments", "catalog", "identity", "notifications"],
        required: true,
      },
      {
        name: "database",
        description: "Database type",
        type: "select",
        options: ["postgresql", "none"],
        defaultValue: "postgresql",
        required: false,
      },
      {
        name: "messageQueue",
        description: "Include message queue consumer",
        type: "boolean",
        defaultValue: "false",
        required: false,
      },
    ],
  },
];

Der Golden Path ist nicht verpflichtend – er ist einfach die bequemste Option. Teams können davon abweichen, wenn sie gute Gründe haben, aber der Standardweg ist so gut ausgebaut, dass die meisten Teams ihn bevorzugen.

Die Platform-API-Schicht

Eine Platform-API bietet programmatischen Zugriff auf Infrastrukturoperationen. Das ermöglicht sowohl das Self-Service-Portal als auch automatisierte Workflows.

tstypescript
interface PlatformAPI {
  services: {
    create(config: ServiceConfig): Promise<ServiceInstance>;
    deploy(serviceId: string, version: string): Promise<Deployment>;
    scale(serviceId: string, replicas: number): Promise<void>;
    getStatus(serviceId: string): Promise<ServiceStatus>;
  };
  databases: {
    provision(config: DatabaseConfig): Promise<DatabaseInstance>;
    createBackup(dbId: string): Promise<BackupInfo>;
    restoreBackup(dbId: string, backupId: string): Promise<void>;
  };
  secrets: {
    set(key: string, value: string, scope: string): Promise<void>;
    rotate(key: string): Promise<void>;
    listScopes(): Promise<string[]>;
  };
  observability: {
    createDashboard(config: DashboardConfig): Promise<string>;
    createAlert(config: AlertConfig): Promise<string>;
  };
}
 
interface ServiceConfig {
  name: string;
  team: string;
  template: string;
  environment: "dev" | "staging" | "production";
  resources: {
    cpu: string;
    memory: string;
    replicas: number;
  };
}
 
interface ServiceStatus {
  name: string;
  environment: string;
  currentVersion: string;
  replicas: { desired: number; ready: number };
  health: "healthy" | "degraded" | "unhealthy";
  lastDeployment: {
    version: string;
    timestamp: Date;
    status: "success" | "failed" | "rolling-back";
  };
}

Metriken zur Developer Experience

Der Erfolg der Plattform bemisst sich an der Produktivität der Entwickler, nicht an Infrastrukturmetriken. Verfolge, wie lange gängige Workflows dauern und wo Entwickler ins Stocken geraten.

tstypescript
interface DeveloperExperienceMetrics {
  timeToFirstDeploy: number;        // minutes: new service → production
  deploymentFrequency: number;      // deploys per team per week
  leadTimeForChanges: number;       // minutes: commit → production
  ticketsToInfraTeam: number;       // per team per month
  platformAdoptionRate: number;     // % of services using golden paths
  developerSatisfaction: number;    // quarterly survey, 1-5
}
 
function assessPlatformMaturity(
  metrics: DeveloperExperienceMetrics
): { level: string; nextSteps: string[] } {
  const nextSteps: string[] = [];
 
  if (metrics.timeToFirstDeploy > 480) {
    nextSteps.push(
      `Time to first deploy is ${metrics.timeToFirstDeploy} min. ` +
      "Target: under 60 min via service templates."
    );
  }
 
  if (metrics.ticketsToInfraTeam > 10) {
    nextSteps.push(
      `${metrics.ticketsToInfraTeam} infra tickets/month per team. ` +
      "Identify top ticket categories and build self-service for them."
    );
  }
 
  if (metrics.platformAdoptionRate < 0.7) {
    nextSteps.push(
      `Only ${(metrics.platformAdoptionRate * 100).toFixed(0)}% adoption. ` +
      "Interview non-adopters to understand gaps."
    );
  }
 
  if (metrics.developerSatisfaction < 3.5) {
    nextSteps.push(
      `Satisfaction at ${metrics.developerSatisfaction}/5. ` +
      "Run developer experience interviews for qualitative feedback."
    );
  }
 
  const level =
    nextSteps.length === 0
      ? "mature"
      : nextSteps.length <= 2
        ? "growing"
        : "foundational";
 
  return { level, nextSteps };
}

Anti-Patterns von Plattformteams vermeiden

Plattformteams scheitern, wenn sie einen internen Cloud-Provider bauen statt eines meinungsstarken Workflows.

tstypescript
interface PlatformAntiPattern {
  pattern: string;
  symptom: string;
  fix: string;
}
 
const antiPatterns: PlatformAntiPattern[] = [
  {
    pattern: "Building AWS-on-AWS",
    symptom: "Platform exposes raw Terraform/Kubernetes primitives to developers",
    fix: "Abstract to workflow-level operations: 'deploy my service' not 'create an ingress'",
  },
  {
    pattern: "Ticket-driven platform",
    symptom: "Developers file tickets and wait for platform team to act",
    fix: "Build self-service APIs and UIs; platform team builds tools, not fulfills requests",
  },
  {
    pattern: "Mandatory adoption without value",
    symptom: "Teams forced to use platform tools that make their workflow worse",
    fix: "Make the platform the easiest path, not the required path",
  },
  {
    pattern: "Building without user research",
    symptom: "Platform features nobody asked for, missing features everyone needs",
    fix: "Embed with application teams; watch them work; fix their actual pain points",
  },
  {
    pattern: "No documentation or onboarding",
    symptom: "Only platform team members can use the platform effectively",
    fix: "Write getting-started guides, record walkthroughs, staff office hours",
  },
];

Die wichtigsten Erkenntnisse

Platform Engineering ist erfolgreich, wenn du die Plattform als Produkt behandelst und die Entwicklerteams als deine Nutzer. Miss zunächst, wo Entwickler Zeit mit lästigen Aufgaben verlieren – Services bereitstellen, Deployment-Pipelines debuggen, Observability verdrahten – und baue zuerst Self-Service-Automatisierung für die Workflows mit der größten Reibung und Häufigkeit. Stelle Golden-Path-Templates bereit, die Teams einen produktionsreifen Startpunkt mit integrierter Observability, CI/CD und Security geben. Biete eine Platform-API an, die sowohl Self-Service-UIs als auch automatisierte Workflows antreibt. Miss den Erfolg anhand von Developer-Experience-Metriken: Zeit bis zum ersten Deployment, Anzahl der Infrastruktur-Tickets und Entwicklerzufriedenheit. Das Plattformteam, das die wenigsten Features ausliefert, aber den meisten Entwickler-Ballast beseitigt, ist das erfolgreichste.

Wilfredo Rujel

Wilfredo Rujel

Full-Stack-Softwareentwickler

Diesen Beitrag teilenX