Technologie ist einfach. Der menschliche Teil ist der Schwierige. Kommunikation und Terminologie wiederum sind Elemente dieses schwierigen Teils. In diesem Post soll es um den Begriff Platform im Kontext von Kubernetes gehen.
Wir reden von Agile, DevOps, Komplexität. Im Großen sicher nicht, aber haben wir im Kleinen, also innerhalb einer Organisation oder eines Teams ein gemeinsames Verständnis von den Begriffen welche wir täglich nutzen?
Platform: Wir kennen den Begriff aus dem Umfeld von Betriebssystemen (Cross-Plattform) und (Enterprise-)Laufzeitumgebungen (Java Platform, Java Enterprise Edition). Wir verstehen eine Platform als etwas Horizontales “Nicht-Funktionales”. Was ist es im Kontext von Kubernetes?
Eine Kubernetes Application Platform sollte Container basierte Anwendungen/Microservices also unterstützen in den Disziplinen
- Observability
- Authentication / Authorization
- Networking
- Key Management
- Storage (Block, Object, File)
- Databases (Relational, Key-Value, Document, Graph)
- Continuous Integration/-Delivery
- Backup/Recovery
- Messaging
Konzeptionell ist vieles nicht neu. Container bedingen allerdings viele neue Implementierungen:
Die Open Source Upstream Basis Komponenten lassen aus Sicht von Anwendungs-Entwicklern, im Folgenden kurz Entwickler (!= Infrastruktur- / Platform Entwickler) offensichtlich noch sehr zu wünschen übrig. Aus Sicht von Entwicklern ist es schlicht eine zu niedrige Abstraktion. Man merkt es spätestens wenn man versucht mit kubectl zu arbeiten.
- Muss jeder Entwickler wirklich wissen was ein Deployment, StatefulSet, DeamonSet, Pod, Service, ConfigMap, Secret, PersistentVolume(Claim) etc. sind und wie man damit umgeht?
- Muss man wissen was ein Controller, eine CustomResourceDefinition oder ein Operator ist und wie diese Dinge arbeiten?
- Muss man sich den Kopf darüber zerbrechen ob man imperativ oder deklarativ mit
kubectlarbeiten sollte?
Ich denke nein. Ich würde sogar soweit gehen zu sagen man sollte Anwendungsentwicklern Kubernetes komplett ersparen können.
Was will ein Anwendungsentwickler eigentlich wirklich von einer Platform? PaaS Anbieter haben sich ausgiebig mit dieser Frage beschäftigt. Zwar nicht Kubernetes, aber schauen wir exemplarisch einfach einmal auf die CLI Hilfe von heroku:
USAGE $ heroku [COMMAND] COMMANDS access manage user access to apps addons tools and services for developing, extending, and operating your app apps manage apps on Heroku auth check 2fa status authorizations OAuth authorizations autocomplete display autocomplete installation instructions buildpacks scripts used to compile apps certs a topic for the ssl plugin ci run an application test suite on Heroku clients OAuth clients on the platform config environment variables of apps container Use containers to build and deploy Heroku apps domains custom domains for apps drains forward logs to syslog or HTTPS features add/remove app features git manage local git repository for app help display help for heroku keys add/remove account ssh keys labs add/remove experimental features local run Heroku app locally logs display recent log output maintenance enable/disable access to app members manage organization members notifications display notifications orgs manage organizations pg manage postgresql databases pipelines manage pipelines plugins list installed plugins ps Client tools for Heroku Exec psql open a psql shell to the database redis manage heroku redis instances regions list available regions for deployment releases display the releases for an app reviewapps manage reviewapps in pipelines run run a one-off process inside a Heroku dyno sessions OAuth sessions spaces manage heroku private spaces status status of the Heroku platform teams manage teams update update the Heroku CLI webhooks list webhooks on an app
Openshift, Garden, Rio, Tilt und Jenkins X sind in diesem Sinne vergleichbare Produkte für Kubernetes. Sie alle sind deutlich näher an den Bedürfnissen von Entwicklern und versuchen Kubernetes mehr oder weniger “verschwinden” zu lassen. Jenkins X gefällt mir persönlich sehr gut weil sehr ausgereifte Kubernetes CI/CD Workflows für nahezu alle Laufzeitumgebungen git gesteuert out of the Box zur Verfügung stehen. Wer nicht mag sollte sich nicht mehr mit Kubernetes rumschlagen müssen. Zugegeben: On-Prem oder in Nischen Clouds ist Jenkins X heute kein Selbstgänger.
Was macht ein Platform Team?
Grundsätzlich wird ein dediziertes Platform Team erst ab einer gewissen Größe einer Organisation und Menge von Anwendungen Sinn machen. Primäre Aufgabe dieses Teams sollte es sein Entwicklern das Arbeiten mit der Platform so einfach wie möglich zu gestalten – sie sollten sich schließlich auf die Umsetzung der Anforderungen ihrer Kunden (der Business-Units) fokussieren.
In einer reifen Cloud-Umgebung “verschwinden” viele Aspekte der Platform-Komplexität (“Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.”). Man selbst hat nur noch wenig Arbeit mit diesen Dingen weil der Cloud (☝️Platform) Provider gut genug war sie verschwinden zu lassen ??. Otto beschreibt seinen Weg auf AWS und Erfahrungen im Kontext Platform im Post OTTO goes AWS – Teil 2.
Wie geht man mit einer Situation um wo man es mit einer weniger ausgereiften Umgebung zu tun hat? Wo gewisse essentielle Dienste womöglich fehlen? Sollte man selbst implementieren? (Und betreiben? Und langfristig warten?)
Pauschal kann man diese Fragen natürlich nicht beantworten. Ich denke man sollte vor allem ehrlich mit sich selbst sein und eigene Fähigkeiten nicht überschätzen bzw. Komplexität unterschätzen (Nerds neigen dazu). Ein guter Anwendungs-Entwickler ist noch lange kein guter Infrastruktur- oder Platform-Entwickler (Was ist eigentlich ein DevOps Engineer?)
In jeden Fall sollte man sich Zeit für ein gemeinsames Verständnis der Begriffe und Klarheit in Bezug auf Verantwortung nehmen.
Von autonomen Vertikalen haben wir inzwischen ein relativ gutes Verständnis. Wie in so einem Umfeld horizontale Plattform Dinge langfristig funktionieren scheint deutlich unklarer – insbesondere in Bezug auf die erforderlichen Strukturen in der Organisation und Planung. Make Boring Plans bietet viele wertvolle Anregungen Kontext Plattform.