Begriff

PCF (Pivotal Cloud Foundry)

Cloud Platform S4

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Bevor Kubernetes den Markt fraß, gab es Cloud Foundry. Es ist das ultimative PaaS für Enterprise-Firmen (Banken, Autohersteller). Du als Entwickler sagst: cf push meine-app. PCF nimmt deinen Code (Java, Go, Node). Es erkennt die Sprache. Es baut einen Container (Buildpack). Es startet ihn. Es macht Load Balancing, Logging, Scaling, Health Checks. Alles automatisch. Du siehst keine Server. Du siehst keine Dockerfiles. Es ist "Heroku für Unternehmen, die es selbst hosten wollen".

Merksatz: Eine kommerzielle Distribution der Open-Source-PaaS-Software Cloud Foundry (jetzt Teil von VMware Tanzu), die Entwicklern ermöglicht, Anwendungen deployed und skaliert zu betreiben, ohne sich um die zugrundeliegende Infrastruktur zu kümmern.

1. Buildpacks

PCF hat Buildpacks erfunden (Heroku auch). Kein Dockerfile schreiben müssen. Der Buildpack analysiert pom.xml -> "Ah, Java!" -> Lädt JDK, Maven, baut JAR. CNCF (Kubernetes) hat das Konzept jetzt übernommen ("Cloud Native Buildpacks").

2. BOSH

Das "Kubernetes unter Cloud Foundry". Ein Tool, das VMs managt. "Ich brauche 50 VMs für PCF". BOSH erstellt sie, installiert die Software, heilt sie bei Ausfall. BOSH ist extrem mächtig, aber berüchtigt komplex.

1. Diego: Der Container-Orchestrator

Während Kubernetes kubelet nutzt, nutzt PCF (und Cloud Foundry) die Diego-Architektur. Diego besteht aus dem "Auctioneer" (der entscheidet, welcher Node eine App bekommt) und "Cells" (den eigentlichen VM-Hosts). Der Clou: Diego ist extrem auf High Availability optimiert. Wenn eine Cell stirbt, erkennt die "BBS" (Bulletin Board System) den Soll-Zustand-Unterschied und triggert sofort eine neue Auktion. Im Gegensatz zu Kubernetes ist dieser Prozess sehr "Enterprise-ig" gekapselt und für den Admin fast unsichtbar.

2. Gorouter & UAA Consistency

Das Routing in PCF erfolgt über den Gorouter. Er ist die zentrale Anlaufstelle für alle Requests. Er registriert dynamisch alle neuen App-Instanzen über NATS (ein Messaging-System). Zusammen mit UAA (User Account and Authentication) bildet er ein Sicherheitsnetz: Jede Anfrage wird automatisch gegen JWT-Tokens geprüft, bevor sie überhaupt bei der App ankommt. In der Produktion erlaubt dies "Zero Trust" Architekturen, bei denen die App selbst gar nicht mehr wissen muss, wer der User ist – der PCF-Layer hat das bereits verifiziert.

3. Loggregator & Firehose

Logging in einer Umgebung mit 10.000 Containern ist schwer. PCF nutzt den Loggregator. Jeder Container schickt seine Logs an einen lokalen Agenten (Metron). Dieser bündelt sie und schickt sie an eine zentrale Firehose. Unternehmen nutzen "Nozzle"-Anwendungen, um diese Firehose anzuzapfen und die Daten in Splunk oder Datadog zu schaufeln. Das Geniale für Entwickler: cf logs my-app zeigt die Logs aller Instanzen gleichzeitig an, als wäre es ein einziger lokaler Prozess. Das ist das Level an Abstraktion, das PCF so wertvoll für große Teams macht.

Quick-Check

Lebt es noch?
Es heißt jetzt oft VMware Tanzu Application Service. Viele Old-School Enterprises nutzen es massiv. Aber der Trend geht klar zu Kubernetes (oder PCF auf Kubernetes).
Unterschied zu Kubernetes?
Kubernetes: "Hier ist ein Container, run it." (CaaS). PCF: "Hier ist Source Code, run it." (PaaS). PCF ist abstrakter (höher), Kubernetes ist flexibler (tiefer).
Warum Pivotal?
Pivotal war das Spinoff von EMC/VMware, das Agile/DevOps in die Enterprise-Welt brachte. Sie haben Spring Boot erfunden! PCF war ihre Plattform.