Orthevs Engineering Lab · PEL

Plattformen als Produkte entwerfen, bereitstellen und über ihren Lifecycle betreiben.

Das Platform Engineering Lab verbindet Blueprints, Golden Paths, Cluster, Add-ons, Self-Service, Reliability und Recovery in einer Control Plane für standardisierte, governed Plattformangebote.

Einsatzfelder ansehen 48 Factories erkunden

Dokumentiertes Zielbild · Concept / Architecture Baseline

Platform Product Lifecycle

InputOfferingBlueprintPolicies

Orthevs LabPELControl Plane

OutcomePlatformWorkspaceSLO Evidence

Health, Drift, Adoption, Kosten und Recovery fließen in das Angebot zurück

Auftrag und Anspruch

Self-Service ist nur dann ein Produkt, wenn Betrieb und Recovery mitgeliefert werden.

PEL behandelt Plattformen und Cluster als versionierte Angebote statt als einmalige Installationsprojekte. Ein Offering verbindet Blueprint, unterstützte Provider, Sicherheits- und Betriebsrichtlinien, SLOs, Quoten, Supportmodell und dokumentierte Lifecycle-Operationen.

Nutzer wählen einen Golden Path und beschreiben den gewünschten Zustand. PEL validiert Capabilities, erstellt einen Plan mit Kosten- und Policy-Prüfung, fordert Freigaben an und orchestriert isolierte Runner. Der beobachtete Zustand wird regelmäßig gegen die freigegebene Revision geprüft.

Kubernetes ist das erste priorisierte Zielsystem, aber nicht die fachliche Produktgrenze. PEL ersetzt weder Kubernetes noch Terraform, Ansible, Cluster API, Helm oder GitOps. Es integriert diese Werkzeuge hinter stabilen Domänen- und Operationsverträgen.

Capability-Landkarte

Zwölf Domänen strukturieren das Platform Engineering Lab.

Die Domänen ordnen Verantwortung und Lebenszyklen. Factories liefern darin klar abgegrenzte, versionierbare Fähigkeiten.

1 · CPF · PBF · PCF · TOF

Platform Strategy & Architecture

Plattformprodukte, Zielarchitekturen, Blueprints und technische Leitplanken definieren.

2 · CMF · IIF · IPF · NIF

Infrastructure & Resource Provisioning

Provider, Compute, Network, Storage und Ressourcenreservierungen kontrolliert bereitstellen.

3 · NCF · NLF · NPF · OIF

Operating Systems & Node Engineering

Node-Rollen, OS-Verträge, Bootstrap, Enrollment und Node-Lifecycle mit OSEL verbinden.

4 · CDF · CFF · CLPF · CUF

Cluster Engineering

Clusterdesign, Provisionierung, Flotten, Upgrades und Multi-Cluster-Lifecycle beherrschen.

5 · CAF · CNF · CSF · CRF

Cluster Foundation Services

Netzwerk, Storage, Runtime und Add-ons als kompatible Clustergrundlage verwalten.

6 · COF · GOF · RLF · WAF

Delivery, Configuration & Automation

GitOps, Konfiguration, Releases und Workflows als wiederholbare Delivery-Strecken kombinieren.

7 · DPF · EVF · GPF · WSF

Developer Experience & Self-Service

Portale, Golden Paths, Environments und Workspaces für sichere Selbstbedienung gestalten.

8 · DBSF · MSF · PSF · SPF

Platform Products & Shared Services

Datenbanken, Messaging, Registries, Secrets und weitere Services als standardisierte Angebote liefern.

9 · IRF · OBF · OMF · SLF

Reliability, Observability & Operations

SLOs, Telemetrie, Health, Kapazität, Diagnose und Operations über Plattformen zusammenführen.

10 · IAF · PSCF · POCF · SCSF

Security, Compliance & Governance

Policy, Supply Chain, Security Controls und Evidence in Design, Plan und Betrieb verankern.

11 · BAF · BCF · HAF · DRF

Resilience, Backup & Recovery

Backups, Restore, Disaster Recovery und Continuity als regelmäßig geprüfte Produktmerkmale behandeln.

12 · CFFO · DCF · DRCF · PLF

Lifecycle, Governance & Economics

Portfolio, Kosten, Quoten, Change, Drift und Decommissioning über den gesamten Lifecycle steuern.

Einsatzmöglichkeiten

PEL beginnt beim vollständigen Engineering-Problem.

Die Szenarien verbinden mehrere Factories zu einer belastbaren Strecke. Sie beschreiben das dokumentierte Zielbild, keine bereits zugesicherte Produktfunktion.

1Greenfield

Ein Kubernetes-Angebot als Golden Path bereitstellen

Ein Nutzer wählt ein Offering, parametrisiert den Blueprint und erhält vor der Ausführung Plan, Kosten und Policy-Ergebnisse. PEL provisioniert Infrastruktur, OS/Nodes, Cluster, Netzwerk, Storage, Add-ons, Security Baseline, Monitoring und Backup und schließt mit Acceptance- und Restore-Tests ab.

Ein Request statt Werkzeugkette
Policies in jeder Phase
Ready erst nach Betriebsprüfung

PBF → IPF → CLPF → CNF/CSF → CAF → OMF/BAF

2Brownfield

Bestehende Cluster schrittweise übernehmen

Read-only Discovery und Inventar bilden den Ausgangspunkt. PEL vergleicht Realität und freigegebenes Blueprint, klärt Ownership und wechselt bewusst von Observed Only über Partially Managed zu Fully Managed.

Keine erzwungene Sofortübernahme
Ownership pro Ressourcenbereich
Risiko- und Driftreport vor Mutation

DAF → TOF → DRCF → POCF → PLF

3Production Change

Cluster-Upgrades mit Stop- und Recovery-Gates

Supportmatrix, Preflight, Impact, Wartungsfenster, Backup und Restore-Readiness werden vorab geprüft. Control Plane und Worker folgen sicheren Batches; API, Nodes, Add-ons, Services und SLOs werden nach jedem Schritt verifiziert.

Plan und Approval
Batchweise Ausführung
Forward Recovery mit Evidence

CUF → WAF → BAF/DRF → OMF → SLF

4Platform Service

Gemeinsame Dienste als betreibbare Produkte anbieten

Datenbank-, Messaging-, Registry- oder Workspace-Angebote werden mit Serviceklassen, Quoten, Secrets, SLOs, Backup, Support und Decommissioning publiziert und über Self-Service konsumierbar gemacht.

Servicevertrag statt Einzelinstallation
SLO und Support Tier
Backup, Restore und Retirement

PSF → DPF → EVF → WSF → SLF → DCF

End-to-End-Lebenszyklus

Von der Anforderung bis zum kontrollierten nächsten Zustand.

PEL verbindet Produktdefinition und konkrete Plattforminstanz über einen failure-aware Lifecycle mit Desired und Observed State.

1
Design
Offering definieren
Zielgruppe, Support, Blueprint, SLOs, Policies, Quoten und Lifecycle festlegen.
2
Validate
Eingaben prüfen
Schema, Capabilities, Provider, Versionen und Abhängigkeiten validieren.
3
Plan
Change sichtbar machen
Diff, Kosten, Risiko, Kapazität und Policy-Ergebnisse vorab erzeugen.
4
Approve
Verantwortung bestätigen
Risikooperationen mit Wartungsfenster, Backup und Recovery-Pfad freigeben.
5
Provision
Basisressourcen erstellen
Infrastruktur, OS/Nodes und Cluster über Capability Contracts orchestrieren.
6
Configure
Plattform vervollständigen
Netzwerk, Storage, Runtime, Add-ons, Delivery und Shared Services konfigurieren.
7
Verify
Produktreife belegen
Health, Security, SLOs, Backup und Recovery vor Ready prüfen.
8
Operate
Service liefern
Workspaces, Telemetrie, Kapazität, Support und Kosten laufend steuern.
9
Update
Kontrolliert verändern
Releases, Cluster, Nodes und Add-ons mit Batches und Health Gates aktualisieren.
10
Recover
Wiederherstellbarkeit beweisen
Backups isoliert restoren und RPO, RTO sowie Integrität nachweisen.
11
Retire
Geordnet abbauen
Abhängigkeiten, Daten, Traffic, Credentials und Ressourcen kontrolliert behandeln.

Geschlossener Regelkreis

Health, Drift, Adoption, Kosten und Recovery fließen in das Angebot zurück. Erkenntnisse werden nicht nur dokumentiert, sondern fließen versioniert in den nächsten Engineering-Zyklus ein.

Referenzarchitektur

Control Plane, Execution Plane und Zielplattform besitzen getrennte Vertrauensgrenzen.

PEL plant und koordiniert; isolierte Runner führen mit minimalen Rechten aus; Provider und Cluster bleiben beobachtbare Zielsysteme.

Ebene 1 · Gemeinsame Plattformdienste

Orthevs Platform

IAM, Tenant, Secrets, Policy, Event Bus, Audit, Registry und Artifact Storage.

Ebene 2 · Platform Control Plane

PEL Core & API

Catalog, Desired/Observed State, Planning, Approvals, Workflow Engine und Operation Ledger.

Ebene 3 · Platform Capabilities

PEL Factory-Plugins

Provisioning, Cluster, Add-ons, Delivery, Self-Service, Reliability und Lifecycle.

Ebene 4 · Execution & Targets

Runner, Provider und Cluster

IaC-/Config-Runner, Cloud, Virtualisierung, Bare Metal, Kubernetes und Shared Services.

Declarative First

Ein typisierter Desired State führt, Observed State und Generation bleiben sichtbar.

Plan vor Apply

Diff, Kosten, Policy, Risiko und Approval sind Teil der Operation.

Reconcile mit Grenzen

Nicht jede Drift wird automatisch überschrieben; Ownership und Risiko entscheiden.

Failure-aware

Resume, Compensation und Forward Recovery ersetzen fiktive Atomtransaktionen.

Lab Core

Gemeinsame Verantwortungen halten die Factories integrierbar.

Der Lab-Core bündelt die fachlichen Querschnittsdienste; eine Factory ergänzt eine Capability, ohne diese Grundlagen parallel neu zu bauen.