Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Logo SoftwerkerCast - der IT-Podcast von Techies für Techies

WISSENS-HUB

Community

Softwareentwicklung

Kultur

SoftwerkerCast

Beim SoftwerkerCast gibt es geballtes Wissen für die Ohren aus der bunten Welt der Softwareentwicklung – von A wie API Design bis Z wie Zero Downtime.

SoftwerkerCast: der IT-Podcast von Techies für Techies

Jetzt abonnieren

Du hast Fragen oder möchtest dich zu deinen Herausforderungen austauschen? Gern – trag einfach deine Kontaktdaten ein.

Kontaktanfrage | Sales (allgemein)

Hast du Fragen?

SoftwerkerCast - der IT-Podcast von Techies für Techies

In dieser Episode sprechen Benedikt Ritter und Marco Paga über das vielseitige Thema Nix und NixOS. Ihr erfahrt, was Nix genau ist und welche Besonderheiten es auszeichnen. Benedikt erklärt, welchen Zweck Nix erfüllt und welche vielfältigen Einsatzmöglichkeiten es bietet.

Senior Solution Architect

SOFTWERKER

SoftwerkerCast Episode 55: NixOS mit Benedikt Ritter

In dieser Folge sprechen wir über Haushaltsgeräte und die Benutzbarkeit. Genauso stellen wir uns in diesem Zusammenhang was sinnvolle Produktinnovationen sind. Nicht immer muss die neueste Technologie wirklich besser sein.

User Experience Specialist

SoftwerkerCast Episode 54: UX in der Praxis mit Stefan

Mark erläutert, wie sich die Anzahl und Art der Kommunikationskanäle im Laufe der Zeit vervielfacht hat. Von klassischen analogen Methoden wie Briefpost und Fax hin zu modernen, digitalisierten Prozessen, die über E-Mail, Social Media und automatisierte Systeme laufen.

Head of Berlin, Erfurt, Hamburg, Leipzig, Münster

SoftwerkerCast Episode 53: Inputmanagement mit KI mit Mark Keinhörster

Maximilian Mayer, Experte für Observability, bietet uns tiefgehende Einblicke in große Systemlandschaften und beleuchtet, wie IT-Infrastrukturen effizienter gestaltet werden können.

Senor IT Consultant

SoftwerkerCast Episode 52: Nachhaltigkeit in der IT mit Max

Kamil zeigt auf, wie Businessprozesse analysiert werden und gezielte Empfehlungen für den Einsatz von generativer KI entstehen. Das Ziel? Den größten Mehrwert für das Unternehmen herausarbeiten.

AI Consultant and Engineer

SoftwerkerCast Episode 51: ChatGPT in der Praxis mit Kamil

Holger und ich sprechen über Micro Frontends. Welches Problem lösen sie und worauf ist beim Einsatz zu achten?

Senior IT Consultant | Senior Developer

SoftwerkerCast Episode 50: Micro-Frontends mit Holger

Marco hat Anna und Jenny vom Female Dev Club, einem Netzwerk in Düsseldorf zu Gast und spricht mit ihnen über den Weg zur Gründung und was Gegenstand ihres Meetups ist.

Senior IT-Consultant

IT-Consultant

SoftwerkerCast Episode 49: Female Dev Club

Nadine und Marco sprechen über positive Psychologie, Missverständnisse rund um das Thema und ganz konkrete Schritte für den eigenen Alltag.

SoftwerkerCast Episode 48: Aufblühen statt ausbrennen

Annika berichtet, sehr persönlich, wie sie ihren Weg in die IT gefunden hat. Sie beschreibt, was sie antreibt und gibt Impulse für deinen Weg.

SoftwerkerCast Episode 47: Quereinstieg in die IT

Fast jeder Entwickler arbeitet lieber mit modernen Microservices-Landschaften als mit veralteten Monolithen. Aber wo fängt das Modernisieren an und wo hört es auf? 

Solution Architect

SoftwerkerCast Episode 46: Moderne Microservices-Landschaften (Kubernetes, Dapr, Gateway API & mehr)

Wie startet man eine interne Entwickler-Plattform (Internal Developer Platform, kurz IDP)? Nach den ⁠ersten Einblicken ⁠in Platform Engineering mit Backstage in einer früheren Episode ist Marc Schnitzius erneut zu Gast im SoftwerkerCast, um die ersten Schritte in Richtung IDP zu beschreiben. 

Infrastructure & DevOps Consultant

SoftwerkerCast Episode 45: Platform Engineering revisited

Setzt man sich mit Performance-Messung von Websites auseinander, so wird man relativ schnell auf Googles Metriken-Set Core Web Vitals und das Tool Lighthouse stoßen. 

IT Consultant

SoftwerkerCast Episode 44: Google Lighthouse

Green IT reloaded: In dieser Folge steigen Marco Paga und Manuel Wessner ins Thema Green Cloud mit Serverless-Technologien ein.

SoftwerkerCast Episode 43: Green Serverless Batch Jobs

Marco Paga spricht in dieser Folge mit Goetz Markgraf über künstliche Intelligenz in der Softwareentwicklung.

Senior Agile Consultant

SoftwerkerCast Episode 42: KI in der Softwareentwicklung

Als Product Consultant hilft Marc Pudelski Unternehmen dabei, bessere digitale Produkte zu entwickeln. Was das bedeutet, erklärt er in dieser Folge.

SoftwerkerCast Episode 41: Produktstrategie

Nach der ⁠Einführung in Green IT⁠ in der vergangenen Folge haben wir dieses Mal mit Daniel Eichten einen Gast, der das Thema durch die Brille der Enterprise-Architektur betrachtet.

SoftwerkerCast Episode 40: Green IT & Enterprise-Architektur

Green IT – nur ein zeitgeistiger Hype oder 2024 eine Notwendigkeit? Dennis Breitling und Henning Waack zeigen in dieser Folge, welche Bestrebungen unter diesem trendig klingenden Oberbegriff zusammengefasst werden – und dass sie darauf abzielen, nicht nur Energie, sondern auch Kosten zu sparen.
 

SoftwerkerCast Episode 39: Einführung in Green IT

Sebastian Klatt von der METRO.digital zeigt in dieser Folge, wie so genannte „Recommender-Systeme“ unter der Haube aussehen: Welche Kriterien spielen dabei eine Rolle? Wie geht man vor, wenn man noch gar nichts über den User weiß (Stichwort: Coldstart-Problem)?

SoftwerkerCast Episode 38: Recommender-Systeme unter der Haube – mit Sebastian Klatt (METRO.digital)

ÖPNV – dahinter steckt in diesem Fall nicht der Begriff „Öffentlicher Personennahverkehr“ sondern vielmehr: „Öffentlicher Pflanzennahverzehr“. Was wiederum ein Smart-City-Projekt bezeichnet, das vor einigen Jahren gestartet ist. David Schwarzmann berichtet.

Industrial Solutions Consultant & DevOps Engineer

SoftwerkerCast Episode 37: Smart City – das digitale Gewächshaus

Niklas Haas und Kamil Braschke geben Einblicke in die aktuellen Entwicklungen rund um Private ChatGPTs und Self-hosted LLMs und werfen einen Blick in die Glaskugel – mit sehr spannenden Prognosen.

Service Lead GenAI

SoftwerkerCast Episode 36: Custom GPTs und Self-Hosted LLMs

Wo könnte man besser frei und neu denken als draußen in der Natur, außerhalb der Komfortzone? Jörg Schmerbauch gibt Marco Paga Einblicke in seine Arbeit als „Outdoor-Coach“ – und verrät, worauf es bei Einzel- und Teamcoachings in der freien Natur ankommt. 

SoftwerkerCast Episode 35: Walk-Life-Balance – Coaching im Grünen

„Was Hänschen nicht lernt, lernt Hans nimmermehr"? Fehlanzeige! Unsere Weihnachtsfolge ist ein Mut machendes Plädoyer für Beharrlichkeit und den Glauben an sich selbst.

IT-Consultant & Developer

SoftwerkerCast Episode 34: Vom Underdog zum Informatiker mit Bestnoten: Die ganz persönliche Geschichte eines ITlers

Marco Paga spricht mit Julian Arz über WebAssembly, einen offenen W3C-Standard, dessen beide Namensbestandteile „Web“ und „Assembly“ wenig über seine Funktionalität aussagen. WebAssembly kann nämlich noch einiges mehr und hat laut Julian „riesiges Potenzial“. 

SoftwerkerCast Episode 33: WebAssembly: „Riesiges Potenzial“

Mirko Novakovic ist codecentric-Mitgründer und Softwerker-Gründer sowie ehemaliger Softwerker-Herausgeber. In dieser Folge teilt er seine Erfahrungen als Serial Entrepreneur im IT-Umfeld und gibt wertvolle Tipps für Startup-Gründer.

SoftwerkerCast Episode 32: Das Startup-Mindset – mit Mirko Novakovic

Dr. Boris Adryan ist Academic Director, Data & Digital, bei Merck in Darmstadt. Er lehrt dort das Denken in Daten: Während eines zehnwöchigen Schulungsprogramms können sich Merck-Angestellte von ambitionierten Datenanwendern zu „Citizen Data Scientists“ weiterqualifizieren.

SoftwerkerCast Episode 31: Data Literacy und Data Creativity

Unsere Halloween-Folge zeigt euch die Highlights von Micro-Frontends – und entführt euch in ein auditives ⁠Uncanny Valley⁠. Frankenstein oder Geniestreich? Gruselig echt oder echt gruselig? Ihr entscheidet. Keine weiteren Spoiler.

Frontend Developer & Consultant

SoftwerkerCast Episode 30: Halloween-Spezial: Micro-Frontends

Niklas und Kamil geben in dieser Folge Einblicke in die Verwendung von Private ChatGPT und in Prompt Engineering. Weshalb sich Wissensmanagement besonders als Anwendungsfall für Large Language Models eignet thematisieren die beiden Experten ebenso wie die Vorteile von Microsofts Azure AI Services.

SoftwerkerCast Episode 29: Private ChatGPT und Prompt Engineering

Elvira „Ellie“ Siegel hat Machine Learning an der LMU in München studiert und ist Teil des SHERLOQ-Teams, das ein Produkt zur KI-gestützten Dokumentenverarbeitung entwickelt. In dieser Folge ordnet sie den Bereich der großen Sprachmodelle (LLM) in die Welt der künstlichen Intelligenz ein.

Machine Learning Engineer

SoftwerkerCast Episode 28: Large Language Models

Mit welchen Frontend-Technologien sollten sich Backend-Entwicklerinnen und -Entwickler heute mindestens auskennen?
Daniel Zenzes, seines Zeichens Principal Software Engineer bei adesso und ebenfalls Podcast-Host von „Herr Zenzes will's wissen“, verrät in dieser Folge, was die Frontend-Basics sind.

SoftwerkerCast Episode 27: Frontend für Backend Developer

Senior IT Consultant

SoftwerkerCast Episode 26: State of Frontend

SoftwerkerCast Episode 25: Serverless – Public Cloud oder On-Premises?

SoftwerkerCast Episode 24: Crossplane – Zwischen Multi-Cloud und Platform Engineering

Head of Data

SoftwerkerCast Episode 23: Data Mesh – DDD für Daten?

Principal Agile & Product Coach

SoftwerkerCast Episode 22: 5 Hebel für eine kürzere Time-to-Market

IT Consultant / Software Engineer

SoftwerkerCast Episode 21: Service Meshes

Team Lead & Consultant Data/AI

SoftwerkerCast Episode 20: Explainable AI

SoftwerkerCast Episode 19: Daten, AI und Erklärbarkeit 

SoftwerkerCast Episode 18: OpenFGA – Autorisierung leicht gemacht

SoftwerkerCast Episode 17: ChatGPT – Praktische Nutzung

Principal IAM Consultant

SoftwerkerCast Episode 16: Open Policy Agent: Mächtig sicher

SoftwerkerCast Episode 15: ChatGPT – Zwischen Hype, Hate und Halluzination

Principal IT Consultant

Cloud Partner Manager

SoftwerkerCast Episode 14: Platform Engineering XXL

SoftwerkerCast Episode 13: Platform Engineering mit Backstage

Senior Solution Architect / Head of API Consulting

SoftwerkerCast Episode 12: Platform Engineering 101

SoftwerkerCast Episode 11: Wie viel Wissen ist nötig, um Wissen zu teilen?

Standortleitung Dortmund

SoftwerkerCast Episode 10: „Kunde“ – wer ist das? Und wenn ja, wie viele?

SoftwerkerCast Episode 9: IT Security als „everybody's job“

SoftwerkerCast Episode 8: Cloud-Native (mit Lünendonk)

Software Team Enabler

IT Consultant and Software Engineer 

SoftwerkerCast Episode 7: 10x schneller in Softwareprojekten

Full Stack Consultant

SoftwerkerCast Episode 6: Software-Wartung – die vergessene Disziplin

SoftwerkerCast Episode 5: Recruiting in der IT

SoftwerkerCast Episode 4: IT als Beruf UND Hobby?

SoftwerkerCast Episode 3: To Cloud or not to Cloud?

SoftwerkerCast Episode 2: Application Performance … Management oder Monitoring?

SoftwerkerCast Episode 1: Jobs in der IT

SoftwerkerCast: Trailer

Marco Paga

Zu den Ausgaben

Zur SoftwerkerKonf

Stöbert in unserem kostenfreien Fachmagazin für Entwickler und Softwarearchitekten!

Trefft uns auf unserer Online-Konferenz zum Austausch über aktuelle Tech-Themen.

Hier gibt's noch mehr vom Softwerker

Der Softwerker – Das Magazin

SoftwerkerKonf

Unser SoftwerkerCast-Team

Head of Feelgood Management

Schreibt uns

<p>In diesem Artikel möchte ich einen Überblick über Tekton geben mit dem Ziel, die Grundlagen zu erklären und einen schnellen Einstieg zu ermöglichen.</p><p>Tekton möchte laut eigener Homepage der Standard für CI / CD werden. Zum einen bietet es ein Framework, um Cloud-native CI/CD-Systeme in Kubernetes zu bauen und darüber hinaus ein standardisiertes Tooling für diese Systeme. So hat es schon Einzug in Jenkins X gehalten und ist die Basis für <a href="https://cloud.redhat.com/learn/topics/ci-cd" target="_blank">RedHat OpenShift Pipelines</a> .</p><p>Entwickler, die ein CI-System nutzen wollen, profitieren von der breiten Unterstützung, da vorhandene Pipelines und Pipelineschritte ohne Aufwand zwischen den Tekton CI-Implementierungen ausgetauscht werden können.</p><p>Das Tekton-Projekt nutzt Kubernetes als Plattform und stellt im Kern die Building Blocks einer CI Pipeline in Form von CRDs dar. Eine Custom Resource Definition, kurz CRD, ist ein selbst erstelltes Kubernetes-Objekt, das genutzt werden kann, um eigene Objekte innerhalb der Kubernetes API sichtbar und nutzbar zu machen. So finden sich in Tekton Objekte wie z. B. eine <code>Pipeline</code>, die ebendiese abbildet, und durch <code>Tasks</code>, welche die einzelnen Prozessschritte ausführen, ausgestaltet werden können.</p><p>Die gesamte Konfiguration findet dann wie von Kubernetes gewohnt über Manifeste statt. Das vorhandene Kubernetes Know-how kommt hier voll zum Zuge, denn neben der Konfiguration kann auch eine Introspektion der Prozesse über diesen Weg stattfinden.</p><p>Als zentrale Anlaufstelle für durch die Community gepflegte Tasks und Pipelines wird der <a href="https://hub.tekton.dev/" target="_blank">Tekton Hub</a>  angeboten. Dort zu finden sind schon viele Bausteine, um die üblichsten Schritte abzudecken. Zusätzlich zu dem öffentlichen Hub ist es sehr einfach möglich, innerhalb der eigenen Organisation einmal spezifische Lösungen zu implementieren und zuverlässig zu verteilen.</p><p>Neben den Manifesten liefert Tekton natürlich auch die <a href="https://github.com/tektoncd/pipeline" target="_blank">Kubernetes-Operatoren im Tekton Pipelines Repository</a> , welche die konfigurierten Arbeitsschritte ausführen. Wie bei modernen CI-Systemen üblich werden die Build-Schritte innerhalb von Containern ausgeführt.</p><h2>Installation</h2><p>Die Installation erfolgt entweder durch Apply der Kubernetes-Manifeste der Release-Seite oder durch den <a href="https://operatorhub.io/operator/tektoncd-operator" target="_blank">Tekton Operator</a> .</p><p>Der Tekton Operator ist aktuell noch in einer frühen Entwicklungsphase und bietet aktuell die reine Installation. Hinweise zur Konfiguration der Installation sind auf den <a href="https://tekton.dev/docs/operator/" target="_blank">Hilfeseiten</a>  zu finden.</p><p>Die Installation über die Kubernetes-Manifeste ist im <a href="https://tekton.dev/docs/getting-started/">Getting Started Guide</a>  verständlich beschrieben.</p><p>Um schnell eine nutzbare Installation zu haben, empfehle ich die Installation der Pipeline- und der Dashboard-Komponente, die einen visuellen Einblick in die laufende Tekton-Installation bietet. Das Dashboard ist über einen Browser von außen zu erreichen.</p><h2>Ready-to-run-Projekt</h2><p>Im <a href="https://github.com/marcopaga/tekton-demo" target="_blank">Github-Projekt Tekton-Demo</a>  ist eine komplette Installation zu finden, die mit <a href="https://k3d.io/" target="_blank">K3d</a>  direkt auf dem lokal System läuft. Die Installation ist sowohl im README zu finden als auch immer aktuell <a href="https://github.com/marcopaga/tekton-demo/blob/main/.github/workflows/create-cluster.yml" target="_blank">in der GitHub Action</a> .</p><p>Nachdem die Installation erfolgreich durchgelaufen ist, ist das Cluster eine laufende Tekton-Installation mit Tasks und Pipelines, welche im Namespace <code>tekton-pipelines</code> installiert sind. Da man sehr leicht im falschen Namespace schaut, möchte ich nur kurz <code>kubectx</code> und <code>kubens</code> empfehlen, denn <code>kubens tekton-pipelines</code> setzt den default Namespace korrekt.</p><p>Das Dashboard ist über einen Port-Forward erreichbar und ein Eventlistener ist über einen Ingress nutzbar. Es kann auch schon auf Events reagieren, doch dazu kommen wir in einem weiteren Blogartikel.</p><h2>Eine beispielhafte CI Pipeline</h2><p>Nach der Installation können wir auch schon die Hauptkomponenten kennenlernen und mit diesen ein „Hello, World!“-Beispiel aufbauen.</p><p>Ein <code>Task</code> besteht aus einer Serie von <code>Steps</code>, die der Reihenfolge nach ausgeführt werden. Ein <code>Step</code> ist ein in sich abgeschlossenes Kommando, das im folgenden Beispiel Names <code>hello</code>, der Aufruf von <code>echo "Hello World!"</code> ist. Dies wird in einem Bash Container gestartet und ausgeführt, was natürlich auch nach Gusto geändert werden kann.</p><p>Im realen Einssatz finden sich an dieser Stelle Kommandos, die einen Checkout vornehmen, Images bauen und vieles mehr.</p>

```
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello
spec:
  steps:
    - name: hello
      image: bash:latest
      command:
        - echo
      args:
        - "Hello, world!"
```

<p>Ebenfalls ist ein <code>goodbye</code> Task angelegt, der sich durch ein <code>echo</code> Kommando auf der Systemconsole verabschiedet.</p><p>In diesem kleinen Beispiel werden wir eine Pipeline erzeugen, welche die beiden Tasks nacheinander aufruft, damit bei Betrachtung der Pipeline-Logs sowohl die Begrüßung als auch die Verabschiedung anzeigt.</p><p>Sehr intuitiv – wie ich jedenfalls finde – erstellen wir ein CRD vom Typ <code>Pipeline</code> und definieren dort eine Liste von Tasks, die mit Abhängigkeiten untereinander versehen werden können. In diesem einfachen Beispiel geben wir über <code>runAfter</code>an, dass die Verabschiedung nach der Begrüßung stattfinden soll.</p>

```
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: hello-goodbye-pipeline
spec:
  tasks:
    - name: hello
      taskRef:
        name: hello
    - name: goodbye
      runAfter:
        - hello
      taskRef:
        name: goodbye
```

<p>Der oben definierte <code>Task</code> wird über eine <code>taskRef</code>verlinkt, sodass die definierten Tasks darüber verknüpft werden und die Pipeline die zwei Schritte durchläuft.</p><h2>Interaktion mit Tekton</h2><p>Wie zu Beginn dargestellt arbeitet Tekton über die Konfiguration und Installation von CRDs. Diese API-Objekte können direkt über <code>kubectl</code> abgerufen und manipuliert werden, worüber eine nachvollziehbare API abgebildet wird. Installierte Pipelines können problemlos abgerufen werden:</p>

```
# kubectl get pipelines.tekton.dev --all-namespaces -o wide
NAMESPACE          NAME                     AGE
8
tekton-pipelines   hello-goodbye-pipeline   1s
9
```

<p>Weiterhin ist es natürlich auch möglich, eine Pipeline zu starten. In dem Repository ist ein <code>PipelineRun</code> zu finden, den ich im Folgenden einmal darstelle:</p>

```
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName:  hello-goodbye-pipeline-
spec:
  pipelineRef:
    name:  hello-goodbye-pipeline
```

<p>Die Konfiguration stellt ein Präfix für die erstellten Runs über das <code>generateName</code>-Attribut zur Verfügung. Ebenfalls wird eine Referenz zu der zu verwendeten Pipeline vergeben, welche wir während der Installation erzeugt und uns im Verlauf dieses Artikels angeschaut haben.</p><p>Wie kann eine Pipeline gestartet werden? Jetzt brauchen wir doch noch ein weiteres API-Objekt und zwar den <code>PipelineRun</code>. Dieses Objekt bringt die notwendigen Parameter – in unserem Fall noch keine – in Verbindung mit der auszuführenden Pipeline. Als Nutzer können wir durch Referenz auf den erzeugten Run den Status und auch die Log-Ausgabe abrufen.</p><p>Los geht’s:</p>

```
kubectl create -n tekton-pipelines -f ./hello-goodbye-pipeline-run.yaml
```

<p>Und wie schon angedeutet rufen wir alle Ausführungen ab:</p>

```
kubectl get pipelineruns.tekton.dev --all-namespaces -o wide
NAMESPACE          NAME                             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
8
tekton-pipelines   hello-goodbye-pipeline-v5h5l   True        Succeeded   13s         1s
```

<p>Hier erkennbar sind die vorhandenen Statusfelder dieses Objekts. Für das Blackbox-Testing können wir daher auf den Statuswechsel des PipelineRuns auf <code>Succeeded</code> warten, um den Durchlauf einer Pipeline zu erkennen.</p><p>Neben der direkten Interaktion mit <code>kubectl</code> bietet Tekton ein spezialisiertes Command Line Interface (CLI), das direkt über den aktuell genutzten Kubernetes Context mit dem Cluster interagiert. Viele Kubernetes-basierten Tools bringen ein passendes CLI mit, um effizient mit der Plattform zu arbeiten. <code>tkn</code> ist das entsprechende go Binary, was problemlos auf verschiedenen Plattformen lauffähig ist. Eine Installationsanleitung ist über das <a href="https://github.com/tektoncd/cli">GitHub Repository</a>  zu finden.</p><p>Mit diesem CLI ist es dann einfacher möglich z. B. die Tasks und Pipelines abzurufen. Hier ein kurzes Beispiel:</p>

```

tkn task list --all-namespaces
tkn pipeline list --all-namespaces
```

<p>Diese beiden Aufrufe zeigen alle vorhandenen Tasks und Pipelines in allen Namespaces an.</p><p>Die Inspektion der Logs erfolgt über dieses Kommando:</p>

```
tkn pr logs $PIPELINE_RUN_NAME
```

<p>Die Ausgabe aller Tasks wird hier gesammelt, nachvollziehbar ausgegeben und sieht wie folgt aus:</p>

```
[hello : hello] Hello World!

[goodbye : goodbye] Goodbye World!
```

<h2>Fazit</h2><p>Wir haben jetzt mit wenig Aufwand die Installation vorgenommen und auch schon die erste Pipeline erstellt. Damit haben wir schon viel erreicht und konnten den ersten Blick hinter die Kulissen wagen.</p><p>In den folgenden Artikeln werden wir eine Buildpack-Pipeline erstellen und die Build-Pipeline um einen WebHook-Trigger von außen erweitern. Damit kann Tekton automatisch ein Container Image bauen, wenn ein Push in einem Git-Repository getätigt wurde.</p>

Tekton Cloud-Native CI/CD: Ein pragmatisches Intro

<h1>Tekton Triggers in der Praxis</h1><p>Dieser Artikel ist Teil einer Reihe, die sich mit Tekton CI/CD und dem praktischen Einsatz beschäftigt.</p><p>Im <a href="https://blog.codecentric.de/2022/01/tekton-cloud-native-ci-cd-ein-pragmatisches-intro/" target="_blank">ersten Artikel</a>  haben wir die Installation vorgenommen und die erste Pipeline erstellt. Im <a href="https://blog.codecentric.de/2022/02/alles-schon-da-tekton-buildpack-pipeline/" target="_blank">zweiten Artikel</a>  haben wir die Vorteile von Tekton durch den geschickten Einsatz der wiederverwendbaren Komponenten erleben können. Dieser Artikel beschäftigt sich mit der Einbettung von Tekton in einen Projektkontext. Das Ziel für diesen Artikel ist erstmal die Grundlagen dafür zu schaffen. Wir werden mit Tekton Triggers ein WebHook Interface öffnen und ein Gitlab-WebHook-JSON-Objekt schicken, das einen Build in der Tekton-Installation startet.</p><h2>Möglicher Einsatz</h2><p>Was meine ich an der Stelle mit einem „Projektkontext“? Bisher haben wir Tekton in einem isolierten Setup laufen lassen, was in der Praxis nicht hilfreich ist, denn damit geht die Sichtbarkeit auf die eigene Arbeit schnell verloren. Die Gesamtsicht ist über mindestens zwei Systeme verteilt, welche untereinander nicht verknüpft sind. Schlimmer sogar, die Tekton muss bisher manuell gestartet werden.</p><h2>Warum nicht einfach das Integrierte nutzen?</h2><p>Der Trend bei den großen Plattformen wie <a href="https://github.com/" target="_blank">GitHub</a>  oder <a href="https://about.gitlab.com" target="_blank">Gitlab</a>  ist die Integration der Entwicklungstools. Angefangen vom Git Repository über eine Pipeline-Lösung wie <a href="https://github.com/features/actions" target="_blank">GitHub Actions</a> , über das <a href="https://github.blog/2019-05-10-introducing-github-package-registry/" target="_blank">Container Repository</a>  bis hin zur Integration der <a href="https://about.gitlab.com/blog/2018/08/02/4-ways-to-use-gitlab-issue-boards/" target="_blank">Organisationstools</a> . Der dahinterstehende Grund dabei ist die Transparenz zu erhöhen.</p><p>Dem entgegen steht die Nutzung von Tekton für den Aspekt der CI/CD-Ausführung. Sinn ergibt das, wenn der Wunsch der Compliance, Wiederverwendbarkeit und vermeintlicher Zukunftsfähigkeit steigt. Die <a href="https://github.com/tektoncd/community/blob/main/roadmap.md#mission-and-vision" target="_blank">richtungsweisende Vision</a>  ist die API-Kompatibilität in die Breite zu tragen und ein nachhaltiges Öko-System aufzubauen. Dies ist natürlich erstmal der Beginn einer Reise und es bleibt abzuwarten, ob dies realistisch ist. Bei Entscheidungen die das CI/CD-System betreffen ist die Zukunftsfähigkeit aus meiner Sicht ein interessantes Kriterium.</p><p>Schreibt gerne eure Meinung in die Kommentare oder gebt gerne <a href="https://twitter.com/m_p_dus?s=20" target="_blank">per Twitter</a>  Feedback.</p><h2>Triggers Installation</h2><p>Tekton Triggers sind eine weitere Komponente, die im Cluster installiert sein muss. Hierzu können wir der Installationsanleitung im <a href="https://github.com/tektoncd/triggers" target="_blank">GitHub – Projekt folgend</a>  die notwendigen Manifeste einspielen. Im Kapitel „<a href="https://github.com/tektoncd/triggers/blob/main/docs/install.md#setting-up-tekton-triggers" target="_blank">Setting Up Tekton Triggers</a> “ findet man die beiden Dateien, welche über das Tool der Wahl eingespielt werden können.</p><p>Die Datei mit dem Namen release.yaml beinhaltet die gesamte Triggers-Basisinstallation und die interceptors.yaml-Datei bringt <a href="https://tekton.dev/vault/triggers-main/interceptors/#overview" target="_blank">Interceptoren</a>  für die einfache Anbindung von Systemen wie gitlab, github oder bitbucket mit. Diese sollten ebenfalls installiert werden, denn wir werden einen installierten <code>ClusterInterceptor</code> später noch benutzen. Im nächsten Abschnitt beschreibe ich, welchen Zweck diese haben.</p><p>An dieser Stelle der kurze Hinweis, dass die Tekton-Installation inklusive der Tekton Triggers in <a href="https://github.com/marcopaga/tekton-demo" target="_blank">meinem GitHub Projekt</a>  fertig aufgebaut ist. Einfach klonen und testen. Alles Wichtige ist in der README.md oder auch in der github Action zu finden, die den Code bei jedem Push testet. Mehr zu diesem Projekt ist im <a href="https://info.codecentric.de/softwerker-vol-19" target="_blank">Softwerker Vol. 19</a>  zu finden, denn dort beschreibe ich das gesamte Projekt in der Tiefe und zeige die Zusammenhänge auf.</p><h2>Triggers-API-Objekte</h2><p>Die Triggers API sieht auf den ersten Blick sehr kompliziert aus, jedenfalls ist es mir so gegangen. Am besten wir gehen Schritt für Schritt durch und verstehen, wofür das jeweilige Objekt genutzt wird. Hier meine kurze <a href="https://remarkable.com/referral/NT3R-9TVK" target="_blank">Remarkable-Notiz</a>  die mir bei der Orientierung sehr geholfen hat:</p><p><img width="1024" height="1090" src="https://media.graphassets.com/fhVlBFQpQqubKkeJ1JVG" alt /></p><h3>EventListener</h3><p>Unser Ziel ist einen WebHook von außen zu empfangen. Auf Seite von Kubernetes bedeutet dies, dass ein Service einen TCP-Port zur Verfügung stellt, der dafür genutzt werden kann. Als Anker wird der EventListener genutzt und mit den weiteren Objekten verknüpft. Neben dem zu verwendenden <code>ServiceAccount</code> werden an dieser Stelle die Trigger angehängt. Hinter einem EventListener können beliebig viele Trigger auf unterschiedliche Anfragen lauschen.</p><p>Durch Erstellung des EventListeners wird automatisch der beschriebene Service erstellt. Nur kurz zur Einordnung: Dieser Service ist nur im Cluster verfügbar und kann je nach Use Case z. B. durch ein <code>Ingress</code> für andere Applikationen außerhalb des Clusters sichtbar gemacht werden.</p><h3>Trigger</h3><p>Die Aufgabe des Triggers ist darauf aufbauend die Anfragen zuzuordnen und durch die Verwendung von Interceptoren, TriggerBindings und TriggerTemplates zu verarbeiten. Der Trigger hat einen Namen und alles weitere wird in den genutzten Objekten verwendet.</p><h3>Interceptor</h3><p>WebHooks werden häufig durch bestimmte Systeme aufgerufen. Im Falle von Tekton sind dies Git Repositories wie z. B. Gitlab oder Github. Die Formate des Aufrufs und die genutzten Sicherheitsmechanismen unterscheiden sich zwischen den Systemen.</p><p>Ein <a href="https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/github" target="_blank">WebHook von Github</a>  wird z. B. mit einem HMAC des Payloads und mithilfe eines geheimen Strings abgesichert, wohingegen durch <a href="https://github.com/tektoncd/triggers/tree/main/examples/v1beta1/gitlab" target="_blank">Gitlab</a>  ein <code>X-Gitlab-Token</code> HTTP Header mit einem Secret hinzugefügt wird.</p><p>Wir können den passenden Interceptor nutzen, das notwendige Secret und den Event-Type definieren.</p><h3>TriggerBinding</h3><p>Mit diesem Binding greifen wir auf den JSON Body der Anfrage zu und extrahieren die notwendigen Informationen, wie z. B. die URL des git repositories und den Branch-Namen.</p><p>Die extrahierten Werte sind dann als Parameter verwendbar und können im letzten Objekt verwendet werden.</p><h3>TriggerTemplate</h3><p>An dieser Stelle wird jetzt der eigentlich Aufruf vorgenommen, und zwar werden hier die extrahierten Parameter referenziert und einem Template, z. B. einem PipelineRun, zur Verfügung gestellt. Der PipelineRun wird bei einem WebHook-Aufruf gestartet und das Wissen aus den ersten Artikeln greift hier wieder.</p><h2>Praktische Umsetzung im Sample Projekt</h2><p>Hier das<a href="https://github.com/marcopaga/tekton-demo/blob/2bf387b0df0563fe7d6238d03282d5de49f050c9/tekton-triggers/gitlab-trigger-pipeline-listener.yaml" target="_blank"> komplette Beispiel aus dem Demo-Projekt</a> , welches die angesprochenen Objekte nutzt:</p><div>

```yaml
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: gitlab-listener
spec:
  serviceAccountName: tekton-triggers-gitlab-sa
  triggers:
    - name: gitlab-push-events-trigger
      interceptors:
        - name: "verify-gitlab-payload"
          ref:
            name: "gitlab"
            kind: ClusterInterceptor
          params:
            - name: secretRef
              value:
                secretName: "gitlab-secret"
                secretKey: "secretToken"
            - name: eventTypes
              value:
                - "Push Hook"
      bindings:
        - name: git-revision
          value: $(body.checkout_sha)
        - name: git-repository-url
          value: $(body.repository.git_http_url)
      template:
        spec:
          params:
            - name: git-revision
            - name: git-repository-url
          resourcetemplates:
            - apiVersion: tekton.dev/v1beta1
              kind: PipelineRun
              metadata:
                generateName: show-parameter-triggered-pipeline-
              spec:
                pipelineRef:
                  name: show-parameter-pipeline
                params:
                  - name: image
                    value: test-image-build-by-buildpack-and-triggered:latest
                  - name: git-repository-url
                    value: $(tt.params.git-repository-url)
                  - name: git-revision
                    value: $(tt.params.git-revision)
```

</div><p>In dem Beispiel-Projekt wird der Aufruf durch eine Gitlab-Instanz durch einen curl simuliert. Der Aufruf enthält, wie bei den Interceptoren beschrieben, das notwendige Secret und die eigentlichen Daten des Aufrufs.</p><div>

```bash
curl -v \
-H 'X-GitLab-Token: 1234567' \
-H 'X-Gitlab-Event: Push Hook' \
-H 'Content-Type: application/json' \
--data-binary "@gitlab-push-event.json" \
http://localhost:8081
```

</div><p>In diesem kurzen Ausschnitt möchte ich beschreiben, wie eine Zuordnung zum Aufruf stattfinden kann, denn auf der einen Seite ist dieser Aufruf ein Fire-and-Forget-Lösung, doch auf der anderen Seite kann es notwendig sein, im Rahmen einer Fehlersuche die Verarbeitung nachzuvollziehen. Möglich ist dies, weil Tekton Triggers ein JSON-Objekt zurückliefert, welches eine Event-ID definiert. Diese Event-ID wird als Label an den PipelineRun weitergegeben, der dann darüber identifiziert werden kann. Im folgenden Snippet ist dies in der Praxis dargestellt und <a href="https://github.com/marcopaga/tekton-demo/blob/2bf387b0df0563fe7d6238d03282d5de49f050c9/.github/workflows/create-cluster.yml#L77" target="_blank">komplett hier zu finden</a> .</p>

```
    EVENT_ID=$(./trigger-tekton.sh | jq -r '.eventID')
    echo "EVENT-ID found in the response of the web-hook call${EVENT_ID}"
    # Wait for the triggered PipelineRun to complete
    kubectl -n tekton-pipelines wait --for=condition=SUCCEEDED=True --timeout=60s pipelineruns.tekton.dev -l triggers.tekton.dev/triggers-eventid==$EVENT_ID
```

<h2>Zusammenfassung und Ausblick</h2><p>Dieser Artikel zeigt anhand eines praktischen Beispiels, wie Tekton in eine vorhandene Umgebung eingebunden und genutzt werden kann. An dieser Stelle haben wir ein CI-System aufgebaut, das automatisch Pipelines startet wenn ein Push stattgefunden hat.</p><p>Wie geht die Serie weiter? Wie angekündigt wird ein Post folgen, der die Integration mit Gitlab praktisch darstellt – und zwar auf Basis eines AWS EKS Clusters. Was danach kommt ist noch offen: Möglich wäre es z. B., einen eigenen Task zu entwickeln und zur Verfügung zu stellen oder auch in die Richtung der <a href="https://tekton.dev/docs/chains/" target="_blank">Supply Chain Security</a>  abzubiegen.</p><p>Wenn ihr Fragen oder Anmerkungen zu dem Post habt, freue ich mich über Rückmeldungen von euch hier auf dem Blog, per E-Mail oder gerne auf <a href="https://twitter.com/m_p_dus">Twitter</a> .</p>

Tekton Triggers in der Praxis

<p>Im <a href="https://blog.codecentric.de/2022/01/tekton-cloud-native-ci-cd-ein-pragmatisches-intro/">ersten Artikel</a>  haben wir die Tekton-Installation gemeistert, erste API-Objekte kennengelernt und dabei eine erste kleine Pipeline erstellt. Hier eine kurze <a href="https://remarkable.com/referral/NT3R-9TVK" target="_blank">grafische Zusammenfassung</a>  als Erinnerung.<img width="1024" height="768" src="https://media.graphassets.com/6GtFNokKQ8uWaaYYGE6b" alt="Tekton Building Blocks" /><br /> Jetzt werden wir eine praktisch nutzbare Pipeline erstellen, die, wie für ein CI-System üblich, bei neuen Commits neue Images erstellt. Die Wiederverwendbarkeit von Tekton-Komponenten, sowohl Tasks als auch ganze Pipelines, ist eine Stärke, die ich gerne in diesem Artikel praktisch darstellen möchte.</p><h2>Wie bauen wir?</h2><p>Container Images können wir auf verschiedene Arten erstellen. Docker, die Firma, die Container in die Breite getragen hat, sah es vor, ein <code>Dockerfile</code> zu schreiben, das durch einen <code>docker build</code> schrittweise ein Container Image gebaut hat. Ein <code>Dockerfile</code> zu schreiben ist sehr simpel, jedoch wird es schnell sehr aufwendig, wenn man einen sicheren, stabilen Build und Betrieb gewährleisten möchte.<br /> Ich möchte nur zwei Impulse setzen, die man klären sollte:</p><ul><li>Sollte das CI-System wirklich einen Docker Socket an die Build-Container weitergeben?</li><li>Sollte innerhalb des Docker Images wirklich der Root User genutzt werden?</li></ul><p>Für diese Themen gibt es viele Lösungsmöglichkeiten. Im Folgenden werde ich den Buildpack-Ansatz beleuchten.</p><p><a href="https://buildpacks.io/" target="_blank">Cloud-Native Buildpacks</a>  sind eine einfache Lösung, um Container Images zu erstellen. Was ist also zu tun? Es reicht ein <code>pack build my-image</code>, um die Anwendung im aktuellen Verzeichnis als <code>my-image</code> zu bauen und in einem Image Repository abzulegen. Zugegebenermaßen ist die Lösung sehr einfach zu nutzen, gleichzeitig passiert viel im Hintergrund, um einen optimalen Image Build zu gewährleisten. Themen wie z. B. Caching und Security werden transparent gelöst.</p><h2>Integration in Tekton</h2><p>Wir werden eine Pipeline benötigen, die Schritt für Schritt die benötigten Tasks ablaufen lässt. Die Pipeline wird zuerst den Sourcecode aus einem Git-Repository klonen und in einem Verzeichnis ablegen. Der zweite Schritt wird den Sourcecode in diesem Verzeichnis lesen und mit Buildpack Tooling das Image erstellen und in ein Container Registry pushen.<br /> Im ersten Artikel haben wir uns angeschaut, wie wir eine Pipeline erstellen können und Tasks verknüpfen, aber mit Dateien haben wir noch nicht gearbeitet.</p><h2>Workspaces</h2><p>Verzeichnisse können in Tekton mithilfe von Workspaces zwischen Tasks geteilt werden. Workspaces können auf diverse Kubernetes-Storage-Typen zurückgreifen; so kann z. B. ein <em>PersistentVolumeClaim</em>, eine <em>Config-Map</em> oder ein <em>emptyDir</em> verwendet werden.</p><p>Bei der Definition einer Pipeline legen wir die benötigten Workspaces fest. In unserem Fall definieren wir einen Workspace, um den Sourcecode aus dem Git-Repository für die Laufzeit der Pipeline zu speichern. An dieser Stelle sind nur der Name und die Verknüpfung zu den Tasks bekannt. Tasks können Workspaces erwarten, die dann unter einem bestimmten Namen durch die Pipeline bereitgestellt werden können.</p><p>Hier sehen wir eine kurze Pipeline, die den Sourcecode aus einem Git-Repository in einen Workspace mit dem Namen <em>source-workspace</em> klont.</p><div>

```yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: git-clone-sample-pipeline
spec:
  params:
    - name: git-clone-url
      type: string
      description: HTTP URL of the git repository to clone
    - name: git-revision
      type: string
      default: "main"
      description: Git revision (branch, tag, commit-id) to clone
  workspaces:
    - name: source-workspace # Directory where application source is located. (REQUIRED)
  tasks:
    - name: fetch-repository # This task fetches a repository using the `git-clone` task you installed
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: source-workspace
      params:
        - name: url
          value: $(params.git-clone-url)
        - name: revision
          value: $(params.git-revision)
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
```

</div><h2><em>PipelineRun</em></h2><p>Wie schon im ersten Artikel beschrieben, erzeugen wir einen <code>PipelineRun</code>zum Start der Pipeline und zur Übergabe von Parametern und Workspaces.</p><p>Im folgenden Beispiel starten wir die oben definierte Pipeline mit den gewünschten Werten. Das Git-Repository wird auf einen festen Wert gesetzt und der <code>source-workspace</code> wird mit einem vorhandenen <code>PersistentVolumeClaim</code> verknüpft.</p><div>

```yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: git-clone-sample-pipeline-
spec:
  serviceAccountName: tekton-service-account
  pipelineRef:
    name: git-clone-sample-pipeline
  workspaces:
    - name: source-workspace
      subPath: source
      persistentVolumeClaim:
        claimName: source-workspace-pvc
  params:
    - name: git-clone-url
      value: https://github.com/marcopaga/feeding-the-ci-process-single-project.git
```

</div><p>Jetzt startet die Pipeline, klont das Repository und terminiert erfolgreich.</p><h2>Credentials für Clone und Push bereitstellen</h2><p>Für Open-Source-Projekte mit einem öffentlich verfügbaren Repository sind wir damit am Ziel. Bei dem internen Einsatz mit Credentials auf einem Repository müssen wir diese noch dem Git-Prozess zur Verfügung stellen.</p><p>Bei der Recherche zu diesem Aspekt habe ich verschiedene Informationen gefunden. Für mich hat diese Variante, die dort beschrieben wird, funktioniert. Im Kern wird ein Secret mit den Anmeldeinformationen erstellt und mit Annotations erweitert, die beschreiben, für welchen Einsatz und welchen Server dies zu verwenden ist. Der Key <code>tekton.dev/git-0</code>gibt an, dass dies für github.com-Repositorys zu verwenden ist.</p><div>

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: github-clone-secret
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: git-clone-user-name
  password: git-clone-password
```

</div><p>Das alleine reicht noch nicht, denn die zu benutzenden Secrets müssen dem <em>ServiceAccount</em> des <em>PipelineRuns</em> hinzugefügt werden. Wie im folgenden Beispiel zu sehen, wird das Secret einfach mit aufgeführt.</p><p>Für den Container Image Push ist ebenfalls ein Secret notwenig. Hierbei reicht es, ein normales <a href="https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-by-providing-credentials-on-the-command-line" target="_blank">Docker Registry Secret</a>  anzulegen, wie hier in den Tekton Docs beschrieben. Wichtig auch hierbei ist, dies dem <em>ServiceAccount</em> hinzuzufügen.</p><p>Im Folgenden ist ein <em>ServiceAccount</em> mit den beiden definierten Secrets zu sehen.</p><div>

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: buildpacks-service-account
secrets:
  - name: docker-registry-secret
  - name: gitlab-clone-secret
```

</div><h2>Vorhandene Pipeline und Tasks nutzen</h2><p>Jetzt haben schon einmal eine Pipeline angelegt, mit der wir den Code klonen können. Wir können jetzt mit unserem Wissen weitermachen und schrittweise die nächsten Schritte hinzufügen.</p><p>Auf dem Tekton Hub finden wir <a href="https://hub.tekton.dev/?query=buildpack" target="_blank">Tasks für den Build</a> . So weit, so gut! Die Tasks sind gut dokumentiert und eigentlich können wir diese direkt einbauen.</p><p>Man kann auch <a href="https://hub.tekton.dev/?query=buildpack&kind=Pipeline" target="_blank">nach Pipelines suchen</a> . Wenn wir das machen, finden wir eine komplette Pipeline, die schon fertig und getestet ist.</p><p>Die Buildpacks-Pipeline ist wunderbar dokumentiert. Wir finden Informationen zum Hintergrund, den benötigten Abhängigkeiten und der Installation.</p><p>Wie im ersten Artikel beschrieben, werden diese installiert und direkt benutzt. Der vorhandene <code>PipelineRun</code> wird der Dokumentation folgend angepasst und schon ist alles fertig.</p><h2>Fazit</h2><p>Diese Wiederverwendbarkeit erlaubt eine Zusammenarbeit und einen Austausch von CI-Komponenten innerhalb der eigenen Organisation und sogar im Open-Source-Umfeld.</p><p>Wir konnten durch Verwendung und Konfiguration von Community-Komponenten mit sehr wenig Aufwand eine funktionierende Pipeline erstellen. Damit haben wir jetzt einen Startpunkt, um die eigenen Erweiterungen vorzunehmen und auch dabei von der Community des Tekton Hubs zu profitieren und hoffentlich sogar eigene Contributions zurückzugeben.</p><p>Im nächsten Artikel werden wir mit Tekton Triggers auf dieser Basis weitermachen und beim Push in ein Repository einen Build dieser Pipeline starten.</p>

Tekton Buildpack Pipeline: Alles schon da?

**Der Open Policy Agent (OPA) ist eine universell einsetzbare, quelloffene Policy Engine, also eine Sammlung von Komponenten, die eine einheitliche und effiziente Umsetzung von Regeln aller Art erlaubt. Dieser Artikel zeigt ein kleines Praxisbeispiel.**

Wann hast du das letzte Mal von einer Policy gehört? Etwa:
Wir sollen im Terraform-Skript darauf achten, dass wir bestimmte Parameter setzen.
Oder:
Wir sollen beim Kubernetes-Deployment darauf achten, dass wir nicht als Root laufen.
Das Ganze kann man umsetzen, indem man organisatorische Maßnahmen trifft, was eine umständliche Formulierung für ein Peer Review oder Freigabeprozess ist. Oder durch geschickte Automatisierung. Letztere erhöht zum einen die Sicherheit – denn, mal Hand aufs Herz: Wie oft fällt doch mal etwas nicht auf? – und zum anderen auch die Geschwindigkeit, da eine automatische Prüfung innerhalb einer Pipeline auf jeden Fall schneller ist, als ein Mensch es je sein kann.
In dieses kleine Beispiel möchte ich gerne in diesem Artikel konkret hineinschauen, weil ich denke, dass dies eine schöne Möglichkeit ist, mit wenig Aufwand einen In-House-Prozess durch Automatisierung zu beschleunigen – mit dem Open Policy Agent.

## OPA-Ökosystem
Um es direkt zu sagen: Das Ökosystem ist groß und die Einsatzmöglichkeiten sind sehr vielfältig. 
OPA bietet zum einen die Softwarekomponenten, die benötigt werden, um Regeln während der Laufzeit auszuführen, und zum anderen ist es ein Ökosystem mit verschiedensten Werkzeugen und Integration. Und da zeigt sich meiner Meinung nach auch die Stärke dieser Lösung. 
Wir haben damit die Möglichkeit, als Community voneinander zu profitieren, wie wir es auch normalerweise bei unserer Arbeit gerne machen. 

## Benutzung
Wenn wir das Projekt einsetzen wollen, können wir zwischen mehreren Deployment-Varianten auswählen. Im Folgenden einmal die Herausstechenden:

1. Einbindung als Library, z. B. in einem Go-Projekt oder über Web Assembly
2. Standalone-Deployment als Service mit REST-basierter API
3. Benutzung in einem Test-Tool wie z. B. <a href="https://github.com/open-policy-agent/conftest" rel="noopener noreferrer" target="_blank">Conftest</a> 

Je nach Einsatzszenario unterscheiden sich die Ansätze, wie die Daten und Regeln geladen und zur Ausführung gebracht werden. So gibt es etwa die Möglichkeit, die Daten und Regeln in der Auslieferung als Paket mitzuliefern oder diese Regeln von außen zu erhalten.

Was die Szenarien verbindet, ist das generelle Vorgehen: Zunächst erfolgt ein Aufruf, der von außen an die Engine geliefert wird. Die Regeln werden dann ausgeführt und die Entscheidung wird mit Meta-Daten zurückgeliefert. 
Conftest ist das einfachste Werkzeug, da in diesem Fall die Regeln und die Eingabedaten vorhanden sind und einfach lokal ausgeführt werden kann.

## Rego
Bei dieser Sprache handelt es sich um eine für diesen Zweck optimiert entwickelte Sprache, die von Dataloc inspiriert ist. Ich muss zugeben, dass ich erst im Rahmen der Recherche das erste Mal von dieser Sprache gehört habe.
Wir können hiermit effizient Regeln definieren, die auf strukturierte Eingabedaten angewendet werden. 
Dokumente oder Eingabedaten sind über eine bestimmte Variable innerhalb der Regelausführung bekannt und können über logische Operationen validiert werden. Die Navigation innerhalb der Dokumente ist mit <a href="https://github.com/stedolan/jq" rel="noopener noreferrer" target="_blank">https://github.com/stedolan/jq</a>  vergleichbar und geht mit ein wenig Übung leicht von der Hand.
Damit gehen wir schnell in das obligatorische „Hello, World!“-Beispiel. Als Eingabedaten verwenden wir hier ein JSON-Dokument mit dem Input-Objekt bestehend aus zwei Attributen.
Die Policy prüft, ob die beiden Attribute mit den gewünschten Werten vorhanden sind.

Eingabedaten:
```yaml
{
    "greeting": "hello",
    "message": "world",
	
}

```
Policy:
```yaml
default result := false
result if {
    input.message == "world"
    input.greeting == "hello"
}
```

# Kubernetes

Eingabedaten können beliebige strukturierte Dokumente sein, wie z. B. YAML- oder JSON-Dokumente, sodass sich als Beispiel Kubernetes-Manifeste anbieten, weswegen ich in diesem kurzen Artikel diesen Use Case betrachte.

Die Validierung von Kubernetes-Manifesten kann sowohl im CI-System als auch durch einen Admission Controller im Cluster erfolgen. Innerhalb des CI-Systems wird das OPA-Tooling verwendet, um einen Build mit einer entsprechenden Fehlermeldung zu beenden. Darüber hinaus kann auf den Clustern ein aktiver Check in Form des o. g. Admission Controllers eingebunden werden. Dieser Admission Controller weist Kubernetes-API-Objekte zurück, die den definierten Firmenvorgaben nicht entsprechen.

Ein kleines Beispiel, wie man die Validierung der Kubernetes-Manifeste über das Open-Policy-Agent-Tool <a href="https://github.com/open-policy-agent/conftest" rel="noopener noreferrer" target="_blank">Conftest</a> umsetzen kann: Conftest ist ein kleines Kommandozeilentool, das die Rego-Policies und Deploymentkonfiguration erhält, die Prüfung vornimmt, das Ergebnis ausgibt und einen entsprechenden Return-Code liefert, um in der CI darauf reagieren zu können. 

Wir implementieren jetzt diese Policies in Rego, die ein Deployment prüfen.


```yaml
# Wird in den folgenden Regeln referenziert, um nur auf Deployments zu arbeiten. Andere API-Objekte werden ignoriert
is_deployment {
  input.kind = "Deployment"
}

# Nur Container-Images vom internen Container-Repository sollen verwendet werden. Wird geprüft durch eine Regular Expression auf dem Image-Name
deny[msg] {
    kubernetes.is_deployment
    container := input.spec.template.spec.containers[_]
    not re_match("^internal.repository.de/.+$", container.image)
    msg = sprintf("Container in Deployment %s should use an image from the internal repository", [name])
}

# Wir wollen eine Warnung erzeugen, falls für ein Deployment keine Liveness-Probe definiert wurde. Es wird direkt geprüft, ob diese definiert wurde
warn[msg] {
    kubernetes.is_deployment
    container := input.spec.template.spec.containers[_]
    not container.livenessProbe
    msg = sprintf("Container in Deployment %s should define a livenessProbe", [name])
}
```

Sollte eine Regel nicht erfüllt sein, wird eine Meldung durch den msg-Block zurückgeliefert und ist damit in der CI-Pipeline sichtbar.
Ein sehr einfacher Schritt, der aus dem Stand Mehrwert bietet. Wenn du Fragen dazu hast, melde dich gerne direkt bei mir z. B. über <a href="https://twitter.com/m_p_dus" rel="noopener noreferrer" target="_blank">Twitter</a>  oder per-Mail, dann schaue ich gerne zusammen mit dir, wie wir das umsetzen können.

# Ausblick
Dieser Artikel hat dir schnell einen ersten Überblick über das Projekt Open Policy Agent (OPA) und eine Einsatzmöglichkeit gegeben. Es gibt viel mehr Optionen, das Tool zu verwenden. Um einen ersten Eindruck davon zu erhalten, lohnt es sich, auf der Ökosystem-Seite des Projekts zu stöbern.
Weiterhin werden wir auf diesem Blog Artikel zu diesem Thema posten und auch eine <a href="https://www.codecentric.de/softwerkercast" rel="noopener noreferrer" target="_blank">SoftwerkerCast-Folge</a> zu diesem Thema aufnehmen. 

Open Policy Agent – Maschinen, die auf Regeln starren

Warum „Platform Engineering“ eigentlich der falsche Begriff ist und wie man den Golden Path findet, erklärt Daniel Kocot, Senior Solution Architect, im folgenden Interview.\nMarco Paga: Warum ist Platform Engineering interessant?\nDaniel Kocot\n: Ich habe im September [2022] einen ersten Versuch eines \nBlogposts\n gestartet, um das Thema aufzunehmen und zu verstehen, woher der Drive kommt, um festzustellen, dass wir das bei codecentric seit 2014 gemacht haben, ohne es „Platform Engineering“ zu nennen. Wir haben schon immer etwas ausgeliefert oder zu Kunden mitgebracht, um sie zu befähigen, Softwareprodukte schneller umzusetzen. Das heißt, es ist alles schon da gewesen, jetzt gibt es einen Begriff dafür – der vielleicht nicht ganz passend ist, das schon vorab.\nMaximilian Mayer: Lass uns den Begriff „Platform Engineering“ gleich vorab klar definieren, damit jeder von uns versteht, was das überhaupt ist, wenn wir darüber sprechen.\nDK\n: Platform Engineering ist eigentlich ein falscher Begriff. Ich baue keine Plattform auf, sondern unterstütze dabei, eine Plattform entstehen zu lassen. Also Softwareprodukte oder ein Softwareprodukt an sich. Das heißt, ich bin in der DevOps-Schiene unterwegs und versuche entsprechend, all das, was diese Software braucht, in den Lebenszyklus zu integrieren. Darin steckt auch Governance: dass man Vorgaben macht und schaut, wohin die Reise gehen könnte. Ich möchte damit verhindern, dass Teams etwas benutzen, was im Unternehmen nicht gesetzt ist, und baue Schranken auf. Wenn wir über Platform Engineering reden, dann auch über den „Golden Path“ und welche Rolle Spotify darin hat.\nMM: Wir reden also nicht von einzelnen CI/CD-Pipelines, sondern Platform Engineering ist eher so etwas wie ein Meta-Begriff.\nDK\n: Genau. Es ist ein Überbegriff. Vielleicht möchte ich auch nicht, dass eine Plattform das für mich erledigt, sondern eine Art von Orchestrierung und eine unendliche Anzahl von verschiedenen Plattformen, die mir helfen, Dinge voranzutreiben. Es kommt auch darauf an, wo ich unterwegs bin. Falls ich mit Azure arbeite, ist es eventuell sinnvoll, gewisse Sachen mit Azure DevOps zu lösen. Aber ich kann es durch Platform Engineering so abstrahieren, dass die Software-Entwicklungsteams gar nicht mitbekommen, welche darunter liegenden Technologien sie benutzen. Ganz klar spielt hier auch Developer Experience eine Rolle: das Gefühl zu haben, sich auf die Entwicklung konzentrieren zu können, ohne z. B. irgendwelche Pipelines bauen zu müssen. Es ist alles schon da.\nMP: Das heißt, es ist zum einen Dokumentation, also es sind Hilfestellungen oder Ideen hinterlegt, wie bestimmte Dinge umgesetzt werden, welche Technologien oder innerhalb welchen Technologiespektrums man sich bedienen sollte. Und ich habe auch schon Artefakte mitgebracht, z. B. ein Testing oder etwas in Richtung CI/CD. Das ist ein Baukasten, aus dem ich mich bediene. Fehlt außerdem noch etwas?\nDK\n: Es ist, grob gesagt, genau dieser Baukasten. Was wichtig ist: Ich muss die Entwickler abholen und mich erkundigen, was sie benutzen, was „State of the Art“ ist. Vielleicht stelle ich z. B. fest, dass eine bestimmte Frontend Library nicht das Richtige ist. Ich muss einen Weg finden, die Dinge langfristig besser steuern zu können. Das trägt Spotify sehr stark nach außen, mit Backstage z. B. Die Grundlage von allem ist der sogenannte „Golden Path“: den Fokus auf die reine Entwicklung zu legen. Wir haben, wie ihr auch wisst, sehr häufig Debatten über CI/CD-Pipelines, welches Tooling, warum und zu welcher Zeit. Das will man umgehen, indem man sagt: OK, du willst eine Spring-Boot-Anwendung entwickeln – hier ist ein Button, der ganz viele Dinge auslöst. Schon passieren Sachen im Hintergrund, und ich kann mich wieder auf die Entwicklung fokussieren. D. h. ich kann das Repo auschecken und direkt anfangen, ohne mir Gedanken machen zu müssen, was ich ja auch nicht will. Ich will mir nicht zuerst etwas aufbauen, sondern direkt starten. Es ist alles gesetzt, es gibt vielleicht gewisse Spielregeln, an die ich mich halten muss. Die kann ich auch noch verändern. Aber es ist ein Baukasten, plus ein bisschen mehr.\n„Was wir hier tun, ist nichts Neues. Wir geben dem Ganzen einen anderen Raum und eine andere Position.“\nMM: Das gibt es in der IT doch eigentlich seit 20, 30 Jahren und es hat jetzt einfach einen neuen Namen bekommen – oder sehe ich das grundlegend falsch? Ich komme aus dem Ops-Bereich, dort wurde den Entwicklern häufig schon vorgearbeitet: „Schubs deine Sachen da hinein, dann verteilen wir es weiter“ usw., d. h. sie hatten schon früher in mehr oder weniger komfortablen Konstrukten schöne Buttons, auf die sie nur noch klicken oder E-Mails, die sie verschicken mussten, um Sachen über den Zaun zu werfen. Sehe ich das verkehrt?\nDK\n: Die Grundlage ist immer schon da gewesen. Was wir hier tun, ist nichts Neues. Wir geben dem Ganzen einen anderen Raum und eine andere Position. Wir wollen den gesamten Entwicklungszyklus transparent unterstützen und bieten dir ein gewisses Set von Möglichkeiten. Du kannst natürlich auch den Golden Path verlassen und sagen: Juckt mich alles nicht. Aber wenn du in einem Großunternehmen gewisse Regularien hast und bestimmte Software- und Infrastrukturkomponenten nutzen möchtest, hast du hiermit eine gewisse Chance, alles in eine Art von Alignment zu setzen, sodass alle das nutzen, was da ist und kein Wildwuchs entsteht. Denn das sehen wir bei sehr vielen Kunden: Sehr, sehr viele Komponenten, aber man fragt sich, in welchen Komponenten das Service-Team, das für die Bereitstellung zuständig ist, eigentlich fit ist. Man muss sich um eine schnellere Time-to-Market bemühen. Und am meisten halten Diskussionen darüber auf, \nwas\n man verwendet und \nwarum\n. Es gibt auch Sicherheit, wenn alles standardisiert ist und es geht dann nur noch um die Entwicklung: das Erstellen und Deployment von Software.\nDer Golden Path\nMP: Kannst du den Begriff „Golden Path“ noch einmal für uns einordnen und sagen, was sich dahinter verbirgt?\nDK\n: „Golden Path“ ist das, was die Geschwindigkeit bei Spotify ausmacht. Die können relativ schnell Sachen ausliefern, die bekommen ein schnelles Onboarding hin. Der Golden Path zielt darauf ab, gewisse Sachen zu standardisieren: Abhängigkeiten von Services, Discovery von Services etc., sodass ich Sachen nicht nur schnell finde, sondern auch schnell nach dem Baukastenprinzip zusammenklicken und mich aufs Entwickeln fokussieren kann. \n„Man muss sich um eine schnellere Time-to-Market bemühen. Und am meisten halten Diskussionen darüber auf, \nwas\n man verwendet und \nwarum\n.“\nMM: Das Gedanke hinter dem Golden Path ist also „Schuster, bleib bei deinen Leisten“ bzw. „Entwickler, kümmere dich bitte darum, dass du entwickelst und nicht um das Drumherum“, denn Letzteres wird schon vorbereitet. Spannend, dass du Standardisierung nennst, denn daran scheitert es oft in Unternehmen: Man möchte oft den zweiten Schritt vor dem ersten machen – Kubernetes und all die fancy Sachen – aber der erste Schritt, Dinge zu standardisieren, wird vergessen. So entsteht Schatten-IT: Leute, die die neuesten Sachen machen wollen, treffen auf solche aus dem „Legacy“-Bereich, die noch nicht abgeholt sind und beim Bewährten bleiben wollen. Mit Platform Engineering lassen sich alle schön einfangen, um einen Rahmen zu geben, oder?\nDK\n: Platform Engineering ist eine Art von Knowledge Sharing: Ich teile das Wissen, das ich im Unternehmen gesammelt habe, wie ich Dinge aufbaue. Marco nannte es vorhin „Dokumentation“.  Für Entwickler ist es dann alles unter einem Dach, und ich muss nur dafür Sorge tragen, dass die Entwickler es benutzen. Natürlich gibt es Feedback Loops. Was man mit Platform Engineering erreichen möchte, ist eine Art Self-Service.\nMP: Self-Service heißt, es ist noch kein Platform Engineering, wenn man ein gutes Confluence-Wiki pflegt und ein Ticket-System hat, wo man bestimmte Dinge anfragen kann. Da geht es schon um mehr.\nDK\n: Ja. Ich mag den Begriff „Developer Experience“ nicht – das ist immer so eine eine platzende Seifenblase, und kein Mensch kann etwas damit anfangen – aber es geht darum, dass der Entwickler sagen kann: „Ich klicke mir etwas zusammen, dann passiert etwas Magisches. Ich muss nicht wissen, wie ein Kubernetes-Deployment funktioniert, weil es gar nicht meine Baustelle ist. Ich will nur sehen, dass mein Service in irgendeinem Cluster liegt und funktioniert.“\nMM: Ich war jahrelang im Ops-Bereich tätig und kenne den ewigen Konflikt mit Entwickler-Teams, die mal etwas anderes machen wollen. Wenn man denen dann sagt: Nimm das und benutze es, wird es immer welche geben, die ihre eigenen Tools benutzen wollen, das neueste JavaScript-Framework usw. Hier sehe ich die Gefahr, dass sich Geschichte wiederholen könnte. Wie gehe ich damit um?\n„Platform Engineering ist eine Art von Knowledge Sharing: Ich teile das Wissen, das ich im Unternehmen gesammelt habe, wie ich Dinge aufbaue.“ \nDK:\n Gute Frage. Man muss den Mehrwert erklären können: Warum gehen wir so vor? Weil wir Geschwindigkeit wollen. Wenn das der eine oder andere als Gängelung auffassen sollte, kann man sagen: Ja, du kannst das anders machen, aber dann bekommst du keine Unterstützung und wir können das nicht jedes Mal machen. Wir können nicht auf jede Technologie reagieren, weil wir einen Plan haben. Wenn jemand Vorschläge hat, kann er die natürlich einbringen. Das ist dann allerdings ein Abweichen vom Golden Path, vom „One-Click Shop“, wie es ein Kunde von mir nennt. Ich mache einen Klick und bin schon in der Entwicklung. Ich kenne genug Beispiele von Kunden, wo das schon so funktioniert: Das nennt sich dann „App Store“ o. ä., wo du dir wirklich mit einem Klick Applikationen in jeder Programmiersprache zusammenbauen lassen kannst. Und alles ist konfiguriert. Das ist möglich. Es ist nur die Frage, wie schnell ich das auf die Mannschaft übertragen kann. \nEs geht auch um Adaption, nicht um Kopieren. Nur weil Spotify es so macht und Backstage nutzt, heißt es nicht, dass wir es auch so machen. Es geht darum, zu entscheiden, was mir aktuell hilft – und wenn es erstmal nur ein Git-Repo ist.\nMP: Diese Einordnung ist wichtig. Es ist ein Weg, den man geht, und je nachdem, wo man startet, kann man relativ schnell Mehrwert bieten. Während des Prozesses lassen sich ja auch Schleifen drehen. Wenn Leute andere Technologien verwenden wollen, die z. B. schneller oder besser machen, kann man diesen Leuten Anknüpfungspunkte bieten – sei es, dass man sich in einer Gilde austauscht oder in Sachen Architektur die Möglichkeit hat, einen Dialog aufzubauen oder das Ganze auszutesten, zu validieren, ob das wirklich mehr bringt, dass es irgendwo geregelt ist, und die Potentiale mitnehmen kann.\nDK\n: An Begrifflichkeiten gibt es auch noch „Internal Developer Platform“, abgekürzt IDP, was total schlecht gewählt ist, weil IDP normalerweise etwas anderes bedeutet. Max hat es schon gesagt: Es gibt tausend Begriffe für Dinge, die eigentlich schon da sind. Man muss für sich schauen, was das Ziel ist, welcher Player im Markt man ist: Bin ich ein Datenlieferant, muss ich natürlich bis zum Ende durchautomatisieren, und das muss ich in eine Plattform – jetzt sage ich es schon wieder – oder einen Lebenszyklus gießen. Das ist es, was wir als Entwickler tun: Wir haben eine Idee, setzen diese um, indem wir etwas entwickeln, wir testen, kommunizieren viel, holen Feedback. Und am Ende gibt es ein Artefakt, das in eine Produktion deployt wird. Was wir [mit Platform Engineering] leisten, ist einfach eine Art Unterstützung. Wir helfen, Sichtbarkeit zu erlangen, Dinge zu sehen und zu verstehen, das Suchen und Finden für Entwickler noch einfacher zu machen – in der Regel braucht man einfach eine Such-Engine, die einem hilft, Dinge wiederzufinden. Wir bauen nichts Neues, sondern nehmen Komponenten, die seit 20 Jahren oder länger schon da sind – und geben ihnen ein neues Ansinnen. \nMM: Es ist also weniger die Frage, \nwomit\n als die Frage, \nwie \nman es macht. Hier sehe ich zwei Kernelemente: Standardisierung und Integration der Möglichkeiten. Oft hat man eine Build-Pipeline und einen Kommunikationskanal an anderer Stelle. Wenn man das miteinander sauber integrieren kann, ist das schon die halbe Miete. Wenn man dann noch klar macht, dass es das ist, was mit dem Label „Platform Engineering“ gemeint ist, hat man den Begriff schon entmystifiziert.\n„Es geht um Adaption, nicht um Kopieren. Nur weil Spotify es so macht und Backstage nutzt, heißt es nicht, dass wir es auch so machen.“\nTool-Unterstützung\nMP: Was wirklich wichtig ist, ist, dass man nicht einfach irgendein Tool kauft und installiert. Sondern es geht um viel mehr.\nTrotz allem gibt es Tools, die unterstützen. Was sind sonst noch Tools, die man nutzen kann?\nDK\n: Backstage ist eine Art Entwicklungsportal oder -Framework. Es kommt darauf an, was man braucht. Es gibt auch Humanitec, das so etwas wie Plattform-Orchestrierung bietet, eine zentrale Steuerungseinheit. So werden Dinge einfacher und greifbarer, weil wir nicht so viel über die darunter liegende Plattform wissen müssen, sondern einfach eine Art Konfigurationsmanagement machen. Bei Humanitec gibt es auch eine Beschreibungssprache, die sich \nPlaform-Agnostic Workload Specification \nnennt. Die beschreibt, wie ein Workload Plattform-agnostisch aussehen soll. Das heißt, ich kann mir in einer YAML-Datei den Workload beschreiben, den ich auf verschiedene Plattformen auslagern möchte. Jonas hat über \nCrossplane\n geschrieben, das auch in diese Richtung geht: Es bietet Möglichkeiten für verschiedene Cloud-Hersteller, bewegt sich also in Richtung Multi-Cloud, und kann Dinge dadurch vereinfachen. Es gibt, wie immer, einen Haufen Tools, und man muss sich für sich überlegen: Was will ich eigentlich erreichen bzw. was hilft mir im Moment? Aktuell brauchen die meisten eine Sichtbarkeit auf vorhandene Services und darauf, wie eigentlich entwickelt wird, was die eigenen Standards sind. Daraus ergeben sich im Laufe der Zeit weitere Tools, die ich brauche, um den Platform-Engineering-Begriff füllen zu können. Das Erste ist für die meisten Discovery. Das ist ein einfaches und lösbares Problem: Sichtbarkeit auf das, was ich habe und wo ich stehe.\nMP: Vielen Dank, Daniel, dass du dir die Zeit genommen hast, mit uns das Thema Platform Engineering mit Leben zu füllen und den Leuten näher zu bringen!\nDieses Gespräch führten Max, Marco und Daniel im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter \nhttps://www.codecentric.de/softwerkercast\n. \n\nMaximilian Mayer\n arbeitet als APM Consultant für die codecentric AG. Er hat viele Erfahrungen als Linux-Admin und im DevOps-Umfeld gesammelt. Neben Automatisierung interessiert er sich für Ruby-Entwicklung. Motorräder und alte Autos zählen zu seinen Leidenschaften.\nMarco Paga\n entwickelt Software aus Leidenschaft. Gerne arbeitet er im Team an der Lösung komplexer Probleme. In der Vergangenheit hat er dabei erfolgreich Legacy-Applikationen modernisiert, um diese auf geänderte Herausforderungen vorzubereiten. Alle Beteiligten auf diesem Weg mitzunehmen und für neue Technologien zu begeistern – das ist für ihn selbstverständlich.

„Platform Engineering ist eine Art von Knowledge Sharing“

Platform Engineering mit Backstage\nIm folgenden Interview berichten Marc Schnitzius und Pascal Sochacki von ihren ersten Erfahrungen mit Backstage als Platform-Engineering-Lösung.\nMarco Paga: Marc, Pascal, ihr habt eine Sicht auf Platform Engineering, die ihr gerne mit uns teilen wollt.\nMarc Schnitzius\n: In dem Projekt, in dem ich aktuell mit Pascal bin und generell in Projekten ist man oft in der folgenden Situation: Die Firma schneidet neue Domänen und startet Teams, die alle Services programmieren sollen. Da läuft viel parallel, und es gibt eine ganze Menge Tools, die theoretisch jeder beherrschen müsste, um die Services deployen zu können. Daher kommt der Gedanke, die Hemmnis, die dadurch entsteht, und die kognitive Last zu reduzieren – man muss erst viel lernen, hat eine lange Ramp-up-Phase, muss viele Tools beherrschen – und eine Plattform zu bauen, die das Ganze einfacher macht. \nMP: Das heißt, der Kunde hatte schon viel gemacht, man konnte also schon viele Tools nutzen, musste dann immer nur ein gewisses Konzert „abfeuern“, damit man wirklich einen neuen Service an den Start bringen konnte?\nMS\n: Tatsächlich gab es einige Tools. Aber für die Software, die geschrieben werden sollte – sie wollten mehr in Richtung Microservice-Architektur gehen – kamen einige neue Tools dazu. Das war das eigentliche Problem: der Umstieg von den bekannten, vielen Tools, die ein Dev-Team auch schon relativ langsam gemacht haben, zu vielen neuen Tools, die die Dev-Teams noch langsamer gemacht haben. Keiner will langsame Teams. Deshalb kam der Gedanke, eine „Paved Road“ zu bauen, mit der die Software schnell von der Idee in die Umsetzung kommt.\nMaximilian Mayer: Aber ihr habt wohl kaum gesagt: „Wir machen jetzt Backstage“, sondern es wird ein Prozess gewesen sein, oder?\nMS\n: Auf jeden Fall. Der Prozess dauerte etwa ein dreiviertel Jahr, bis wir zu Backstage gekommen sind. Zuerst haben wir umgestellt von Jenkins auf GiLab CI, haben Kubernetes-Infrastruktur aufgebaut, in dem Fall in der IONOS-Cloud. Es war ein reguliertes Umfeld, deswegen war ein DSGVO-konformer Cloud-Anbieter wichtig. Wir haben viele Terraform-Module geschrieben und erst einmal den Prozess modelliert, wie wir was automatisieren wollten. Am Ende kam ein guter Prozess heraus, für den man aber immer noch eine Anleitung brauchte, was wo zu tun ist. Es gab immer noch eine relativ hohe Hemmschwelle in den Entwicklerteams, diese Plattform zu nutzen, denn: Was Terraform war, was Kubernetes war, wie man deployt, was man kaputt machen konnte usw., war alles nicht klar. Dann kamen wir auf den Gedanken, dass wir ein Frontend für unsere Plattform brauchten, das genau den Prozess, den wir modelliert hatten – neuen Service schnell starten, deployen, monitoren – nochmal abstrahiert und zugänglicher macht.\nMP: Mit „neuen Service starten“ meinst du, dass ein Team damit anfängt, einen neuen Microservice aufzusetzen und dann unterstützt wird dadurch, dass es ein eigenes Git-Repo bekommt, ein CI-System für das Projekt, dass Kubernetes-Ressourcen erzeugt werden ...\nMS\n: ... Security Compliance usw. Alles, was man in eine Pipeline packen kann, sollte einfach schon da sein. Dinge, die normalerweise erst später im Projekt kommen, z. B. Security Scanning, ist darin von Anfang an enthalten. Das ist der DevOps-Gedanke: schnell Feedback zu geben, wo es ein Problem gibt, und es direkt zu adressieren.\nMP: Ihr habt also bei den Basics angefangen: erst einmal alles automatisiert, dargestellt, sodass man darauf aufsetzen kann. Das ist auch ein Learning: dass man erst die Basics einbeziehen muss, bevor man die weiteren Abstraktionsschichten nutzen kann, und auch gewinnbringend. Ich kann ja nicht einfach ein Plattform-Tool nutzen, wenn ich dahinter noch kleine Snowflake-Server habe, die manuell gewartet werden. \nMS\n: Genau. Es ist sehr wichtig, alles iterativ anzugehen. Eine Plattform ist im besten Fall ein Produkt, und die Kunden des Plattform-Teams sind die Entwickler-Teams. Ein Produkt kommt meistens nicht mit einem großen Knall daher, sondern iterativ und im besten Fall so, dass man sich immer wieder vergewissert, ob es noch dem Kundenbedürfnis entspricht. \nAls wir schon fast ein Jahr im Projekt waren, haben wir gesehen, wie die Prozesse sind, wie Leute arbeiten, wie die Teams funktionieren, worauf es ankommt, wo es scheitert, wo Bottlenecks sind. Wir haben erst mal modelliert und angefangen zu automatisieren. Am Ende haben wir dem Produkt ein Gesicht gegeben, ein UI.\nMP: Und das Gesicht könnte in eurem Fall Backstage sein?\nMS\n: Genau. Hier kam Pascal ins Spiel. \n„Eine Plattform ist im besten Fall ein Produkt, und die Kunden des Plattform-Teams sind die Entwickler-Teams.“ \nBackstage\nPascal Sochacki\n: Ich betreibe Backstage seit zwei, drei Monaten und versuche es für uns zu entwickeln, damit wir ein schönes UI für unsere Plattform haben.\nHier muss ich kurz ausholen und erklären, was überhaupt Backstage ist und woher es kommt: Seit zwei Jahren ist es in der CNCF [Cloud-Native Computing Foundation], wurde von Spotify als Open Source bereitgestellt und bei Spotify schon länger eingesetzt. Es ist ein Service-Katalog für große Firmen mit mehreren Teams, die mehrere Services entwickeln, damit ich einen Ort habe, an dem ich alle Informationen finde, die ich für mein tägliches Doing als Entwickler brauche. Es geht darum, zu erfahren, welche Services es um mich als Entwickler herum noch gibt, damit ich z. B. keinen Service schreibe, den es vielleicht schon gibt. Oder welche APIs es gibt, die ich eventuell von anderen Teams konsumieren kann. Oder wenn ich einen neuen Service starten will, der schon so konfiguriert sein soll, dass er auf der zentralen Plattform laufen kann, ohne dass ich viel durchlesen und konfigurieren muss. Es bringt auch ein großes Plug-in-System mit sich, d. h. wenn ich in meiner Plattform schon verschiedene Tools verwende, kann ich sie dort wunderschön integrieren. \nMP: Backstage bietet mir also die Transparenz, die ich brauche. Ich habe verschiedene Services, OpenAPI Specs usw. Wie kann ich das als Entwickler pflegen? Muss ich da immer auf die Oberfläche und klicke mich durch, oder wie kommen die Daten rein?\nPS:\n Es gibt mehrere Möglichkeiten. Ich habe ein Git-Repo, und dort liegt die \ncatalog-info.yaml. \nDie hat ein gewisses Schema, was genau dieses Repo darstellt. Dann kann man entweder die URL Backstage übergeben, und es checkt sie ein; oder man kann sich über Plug-ins einen „Crawler“, wie ich es nennen würde, schreiben, der über alle Git-Repos geht, die er findet. Wenn er die \ncatalog-info.yaml\n findet, registriert er diese und sie ist danach in Backstage vorhanden. Es gibt also keine Hürde, weil ich niemanden bitten muss, meinen Service zu registrieren, sondern das sollte jeder selbst tun.\nMP: Also sehr zugänglich. Was ich oft beim Kunden sehe, ist, dass es ein System gibt, das man pflegen könnte, aber das ist oft sehr veraltet. Daher klingt das sehr gut, dass man bei Backstage mehrere Möglichkeiten hat, es aktuell zu halten.\nMM: Backstage ist glaube ich nicht das einzige Tool [dieser Art] auf dem Markt, aber es legt den Fokus sehr stark auf Platform Cataloguing. Mir fallen andere Tools ein, die so etwas Ähnliches anbieten, einige davon habe ich schon bei Kunden gesehen, aber das war immer eine ziemliche Fummelei. Wie hat Spotify mit Backstage Akzeptanz erreicht? Denn daran scheitert es meistens: Das Tool kann noch so cool sein – wenn es niemand benutzen möchte, hat man verloren. Deshalb bin ich neugierig: An welchem Punkt holt Backstage die Entwickler ab, dass es tatsächlich eine hohe Akzeptanz erreicht?\nPS\n: Schwierige Frage, die wir für unser Projekt auch noch nicht ganz beantwortet haben. Wir sind gerade noch dabei, alle Teams in Backstage zu registrieren. Leuten zu sagen: „Hey, macht das jetzt bitte!“ ist immer schwierig. Man muss ihnen einen Benefit versprechen. Man könnte sie mit Dokumentation locken – das klingt vielleicht komisch, aber Backstage gibt einem die Möglichkeit, seine Dokumentation zu pflegen, als Code im Repo. So habe ich es geschafft, ein Team onzuboarden. \n„Ab einer gewissen Größe ist es sinnvoll, Leute an Bord zu haben, die nur das tun: das Ganze als Produkt denken.“\nMM: Man muss die Leute aus ihrer Komfortzone herauslocken in eine neue Komfortzone. Wenn die Hürde dann gering ist, umso besser. \nMS\n: Ab einer gewissen Größe ist es sinnvoll, Leute an Bord zu haben, die nur das tun: das Ganze als Produkt denken. Das ist auf jeden Fall ein Learning für uns.\nEs ist auch immer schwierig, wenn schon Software vorhanden ist und man schauen muss, ob alles zueinander passt oder ob die Services von ihrer Architektur her so verteilt sind, dass man jedes Mal ganz individuell handeln muss. Wenn es keine Schnittmenge gibt, wird es schwierig. \nMM: Was sind weitere Learnings aus dem Projekt? Dinge, die ihr beim nächsten Mal anders machen werdet?\nMS\n: Ich bin, wie gesagt, seit etwas über einem Jahr in dem Projekt. Als ich dazu kam, lief das Ganze schon ein halbes Jahr. Zu dem Zeitpunkt waren hauptsächlich Entwickler von codecentric in dem Projekt. Das Bottleneck war immer beim Operations-Team. Daher war die Idee, dass ich mit ihnen spreche und sie enable, ihnen zeige, wie Automatisierung funktionieren kann. Es war ziemlich schnell klar, dass nicht einer eine Plattform baut und das Problem weg ist. Ein Learning war, alles ganzheitlich zu denken, nicht nur in der Domäne Operations, sondern sich zu fragen, wie sie arbeiten, was deren Wertschöpfungskette ist. So kamen wir zu der Erkenntnis, dass eine Plattform Sinn machen würde, da die Firma viele Teams zusammenstellte und anfing, viele Services zu programmieren. Spätestens da wurde klar, dass man ein Team brauchen würde, das das Ganze treibt. Es gibt ja nicht nur die Leute, die die Plattform bauen, sondern am besten je nach Größe auch ein eigenes Team oder zumindest eine Gruppe, die Enablement-Rollen in den Teams besetzen kann. Das kommt aus dem Team-Topologies-Gedanken: Steram-Aligned-Teams, Enablement-Teams und eben ein Plattform-Team.\n„Man muss Backstage sehen wie normale Software, die upgegradet werden muss, wo Abhängigkeiten upgedatet werden müssen.“ \nMP: Wenn man es auf die Wertschöpfungskette der Teams bezieht, macht es ja auch Sinn, das so aufzusetzen. Auf der einen Seite hat man ein Team, das sich um die Plattform kümmert und Leute, die in die Teams hineingehen und fragen, was deren aktuelle Needs sind, wo es klemmt, wo es mehr Transparenz braucht. Damit man die Plattform auch als Produkt leben lässt und nicht im schlimmsten Fall „abwirft“ und abwartet, was passiert.\nMS\n: Ein Operations-Team denkt erst mal gar nicht in Produkten. Es denkt in Infrastruktur: Wenn im Monitoring etwas rot wird, behebt man das, und dann geht es weiter. Sie denken nicht in Zyklen. \nMP: Nochmal zu Backstage: Ist es ein „Free Lunch“, d. h. wenn ich meine ganzen darunter liegenden Prozesse automatisiert habe, IaC-Tools verwende, werfe ich dann einmal Backstage ab und es läuft immer, oder wie sieht Tag 2 aus?\nPS\n: Anders als andere Projekte bei der CNCF ist Backstage Software, die ich von Grund auf kompiliere und deploye. Ich habe selber den TypeScript-Code in der Hand und muss meine Änderungen vornehmen. Wenn ich Plug-ins hinzufüge, ist das ein \nnpm-install \nund ich habe das Modul in meinem Backstage und muss es noch in meinen Code einbauen. Das heißt, man muss es sehen wie normale Software, die upgegradet werden muss, wo Abhängigkeiten upgedatet werden müssen. Deshalb ist es etwas anstrengender als andere Tools, die man normalerweise in dem Umfeld benutzt. \nMM: Vermutlich ist es deswegen auch weniger für Ops-Teams geeignet, sondern eher für Personen, die einen Softwareentwickler-Hintergrund haben.\nPS\n: Das würde ich auch sagen. Das ist das Spannende und Schwierige an Backstage: Du kannst zu keinem Ops-Team gehen und sagen: Benutz das bitte.\nMM: Eine wichtige Information. Denn wenn man so ein Tool einsetzt, das eine Plattform bietet, neigt man dazu, es den Ops-orientierten Leuten aufs Auge zu drücken. Denn da könnte der erste Fehler in der Implementierung entstehen. \nMS\n: Wir kennen das aus der DevOps-Bewegung: Ein Ops-Team bekommt neue Tools, und dann soll es ein DevOps-Team sein. Es ist eine Illusion zu glauben, dass es reicht, ein Operations-Team in „DevOps“ umzubenennen, dann vielleicht noch in „SAE-Team“, dann in „Plattform-Team“. Das wird nichts.\nMP: Was gibt es sonst noch zu Backstage zu sagen?\nMS\n: Wir können noch darüber sprechen, wann es überhaupt Sinn macht, sich darüber Gedanken zu machen, Backstage zu nutzen und wie man anfängt. Wenn wir ein Plattform-Team haben und jemanden, der an Backstage „schraubt“, es eigene Software ist, ist es auch immer ein Investment. Wann lohnt es sich?\nDie kognitive Last von Entwicklern kann man beispielsweise mit einfachen Umfragen messen: Wie schwierig ist es, ein Test Environment aufzusetzen? Man kann die Zeit messen. So lässt sich der Bedarf offenlegen. Neben Test Environments kann man fragen, wo die Ownership liegt. Wenn sie beim Dev-Team liegt, sind diesem alle Prozesse klar? Wen muss ich informieren, wenn es außerhalb der Geschäftszeiten einen Ausfall gibt? Wie laufen Restores ab? Viele Dinge außerhalb der fachlichen Anforderungen an ein Dev-Team kann man gut messen, damit den Bedarf an dem Thema generell transparent machen und tracken, ob sich diese Metrik vielleicht mit Einführung der Plattform verringert. \nMP: Das heißt, man kann damit die Investition rechtfertigen, wenn ich das Ganze auf eine Zeitachse legen kann. Habt ihr für euch ein Template mit einigen Faktoren ausgearbeitet?\nMS\n: Daran arbeiten wir gerade – es transparenter zu machen. Wir hätten es von Anfang an machen sollen. Man kann schnell transparent machen, wie viel schneller man geworden ist, welches Problem man gelöst hat. Eine Zahl, die höher oder niedriger ist, sagt mehr aus als ein Ticket, auch über die eigene Domäne hinaus, wo es gar kein fachliches Verständnis gibt. \nMP: Seid ihr selber transparent im Sinne von „Dogfooding“, insofern, als ihr das Platform Engineering auf der Plattform selber darstellt? Wenn ich als interessierter Entwickler wissen möchte, was ihr gerade macht, worauf ihr den Fokus legt, wo kann ich das direkt in Erfahrung bringen?\nMS:\n Ein Plattform-Team arbeitet eigentlich nicht anders als ein Software-Team. Im besten Fall gibt es einen Scrum-Zyklus, ein Board, ein Backlog, ein Review. Genau diesen Prozess implementieren wir gerade. Dadurch, dass unser Team gewachsen ist, wird dies erst möglich.\nMP: Haltet uns gern auf dem Laufenden. Vielen Dank, dass ihr euch die Zeit genommen habt, so offen mit uns darüber zu sprechen. \nDieses Gespräch führten Marc, Pascal, Marco und Max im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter \nhttps://www.codecentric.de/softwerkercast\n. \n\n
\nMarc Schnitzius\n ist DevOps und Infrastructure Consultant bei codecentric in Frankfurt. \nPascal Sochacki \nist IT Consultant bei codecentric in Nürnberg. Sein aktuelles Fokusthema ist Backstage.\nMaximilian Mayer\n arbeitet als APM Consultant für die codecentric AG. Er hat viele Erfahrungen als Linux-Admin und im DevOps-Umfeld gesammelt. Neben Automatisierung interessiert er sich für Ruby-Entwicklung. Motorräder und alte Autos zählen zu seinen Leidenschaften.\nMarco Paga\n entwickelt Software aus Leidenschaft. Gerne arbeitet er im Team an der Lösung komplexer Probleme. In der Vergangenheit hat er dabei erfolgreich Legacy-Applikationen modernisiert, um diese auf geänderte Herausforderungen vorzubereiten. Alle Beteiligten auf diesem Weg mitzunehmen und für neue Technologien zu begeistern – das ist für ihn selbstverständlich.

„Eine Plattform ist ein Produkt, die Entwickler-Teams sind die Kunden“

Victor Volle und Marc Bialowons geben Einblicke aus dem Review eines Platform-Engineering-Projekts in einem großen Unternehmen, das sich in diesem Bereich klar als Vorreiter herausstellte. Marco Paga hat mit ihnen gesprochen.\nMarco Paga: Victor, Marc, ihr wart bei einem großen deutschen Unternehmen. Könnt ihr kurz euren Auftrag beschreiben?\nMarc Bialowons: \nDer Kunde hat uns damit beauftragt, einen Blick auf sein Platform Engineering zu werfen, das er gerade für knapp 2000 Mitarbeiter in der IT zur Verfügung stellt. Dabei war es wichtig, unvoreingenommen an das Thema heranzugehen und den Blick des Marktes darauf zu werfen. Wir haben das Thema schnell heruntergebrochen in einzelne Teilkomponenten bzw. unterschiedliche Arbeitspakete: Einerseits haben wir uns mit den Nutzern der Plattform auseinandergesetzt, in Form von User Interviews. Andererseits haben wir uns mit der Technik selbst befasst, damit herumgespielt und in einem Beispielprojekt die Plattform benutzt.\nVictor Volle:\n „Herumgespielt“ damit hat eigentlich Marco Paga. \nMP: Genau, ich hatte die Möglichkeit, mir die Plattform aus Entwicklersicht anzuschauen, zu schauen, wie man damit arbeiten kann, welche Services es gibt. Es war ein sehr spannender Einblick, weil ich mit einem Buddy zusammenarbeiten konnte, der mir die ersten Fragen beantwortet und mich herumgeführt hat. Von daher: Danke, Victor, dass du mir den Ball zugespielt hast. Wir drei waren zufällig in diesem Consulting-Auftrag unterwegs.\nMöchtet ihr noch etwas über den Kunden sagen?\nVV: \nDie haben sehr früh mit Platform Engineering angefangen. Die ersten Schritte waren vor fünf Jahren. An der Stelle muss ich skizzieren, was wir mit „Platform Engineering“ meinen. Sie haben ganz banal angefangen, Kubernetes bei sich zu benutzen und internen Teams anzubieten. Das ist für mich der minimale erste Schritt: ein Angebot, das Teams, die Software entwickeln, ganz klischeehaft „Value-Stream-Teams“ genannt, nutzen können, ohne Kubernetes selbst einrichten zu müssen – gerade vor fünf Jahren war das noch ein bisschen schwieriger –, sondern das eine Team, das zum Nukleus des Platform-Engineerings wurde, hat Kubernetes zusammen mit einem externen Dienstleister hochgezogen. Die haben es betreut und betrieben und dann intern angeboten. \nDann gab es ein Projekt, das Kafka verwendet hat, und andere Projekte wollten ebenfalls Kafka verwenden. Nicht jeder muss alle Details wissen, wie man das betreibt, einrichtet, hochzieht. Das wurde dann auch intern angeboten. Das waren die ersten Schritte, die fünf Jahre her sind. Das ist ganz schön lang. Solche Dinge gab es schon vorher, aber das dann sehr gezielt als Angebot für die eigenen Softwareentwicklungsteams bereitzustellen fand ich schon ziemlich beeindruckend. In Deutschland zählen sie für mich zu den Vorreitern. \nMP: Das heißt, sie haben Probleme gelöst, die sie damals schon hatten. Als der Begriff noch nicht wirklich gängig war. Sie haben verstanden, dass es einen Wert hat und das Ganze ein Produkt ist. \nVV: \nEin Produkt ist es dort sicherlich noch nicht. Aber was ich gut finde: Sie sind nicht einfach auf den [Platform-Engineering-]Hype aufgesprungen. Ich finde den Begriff sehr gut, aber er ist momentan auch in aller Munde. Sie haben damals mit einem Problem losgelegt und gemacht, was sie brauchten. Irgendwann haben sie es dann „Platform Engineering“ genannt. \nMP: Sollen wir den Aspekt einmal genauer beleuchten?\nMB: \nDas war für uns eine interessante Erkenntnis. Wir wurden quasi in kaltes Wasser geworfen, um uns einen externen Blick in „die Plattform“ zu erarbeiten. Daher gingen wir davon aus, dass wir uns „die Plattform“ ansehen können. Die erste Erkenntnis war dann aber, dass es gar nicht die eine Plattform gibt, auf der man sich einzelne Services automatisiert zusammenklicken kann. Es war eher ein sehr großes Konstrukt aus verschiedenen Plattform-Teams, die alle ihre spezifischen Services für die Projekte anbieten, aber noch nicht so sehr in einer einzelnen Plattform vereint. \nVV: \nUm dies zu verdeutlichen: Als du anfingst, unser Beispielprojekt zu bauen, Marco, wie viele Tickets hast du gebraucht, um alles zusammenzubekommen, was du brauchtest? \n„Wir haben alle gefragt: Wohin schaust du als erstes, wenn du etwas suchst? Jeder hat uns eine andere interne URL gesagt.“ \nMP: Das war auf jeden Fall im zweistelligen Bereich. Deswegen hatte ich auch Schwierigkeiten zu verstehen, was mit „Plattform“ gemeint ist. \nVV:\n Sie sprechen eher von einer „Organisationseinheit Platform Engineering“. Und ja, sie wollen ganz klar – das war auch eine unserer Empfehlungen – zu \neiner\n Plattform.\nZu unserem Vorgehen: Wir haben klassischen User Research gemacht – so gut wir es können, wir sind keine Produktmenschen. Dabei haben wir zwei Kerngruppen von Menschen identifiziert, die diese Plattform nutzen. Die eine Gruppe sind Leute, die sehr, sehr erfahren sind. Die sind früher selbst in Plattform-Teams gewesen oder arbeiten schon lange mit ihnen zusammen. Die andere Gruppe sind Leute, die weiter weg sind – das kann auch geographisch sein – oder die einfach noch nicht so lange dabei sind. Wir haben einen riesigen Unterschied in den Bedürfnissen dieser zwei User-Gruppen festgestellt: Die erfahrenen Menschen wollten dieses neue technische Feature und jenes Angebot usw. haben. Nur: Jeder wollte etwas anderes, was ihm oder ihr wichtig war. Die weniger erfahrenen Menschen – „erfahren“ muss hier nicht heißen, dass sie erst seit drei Jahren im Job sind, aber neu bei diesem Kunden oder bei der Plattform – waren teilweise noch sehr am Suchen. Wir haben alle gefragt: Wohin schaust du als erstes, wenn du etwas suchst? Jeder hat uns eine andere interne URL gesagt. Das heißt, es gibt nicht diesen einen Einstiegspunkt. Einer hat uns gezeigt, wie er in deren Weekly gezielt und sehr geschickt sucht, um das Richtige zu finden im „Wald vor lauter Bäumen“. Eine Plattform, die Menschen Self-Service-artig sehr einfach etwas zur Verfügung stellt, machen sie noch nicht. Wo sie richtig gut sind, ist alles andere: Unterstützung, Consulting, Support, Bereitstellen an Informationen bis in die Details. Gerade auch für den Betrieb, Observability und Logging, war alles da – in unterschiedlicher Ausprägung und Tiefe. Das hörten wir auch in den User-Interviews: Die waren zufrieden mit dem, was angeboten wurde, und wollten mehr. \nMB:\n Das ist ein super spannendes Learning aus dem Projekt: Es braucht nicht unbedingt eine „shiny“ Plattform, um Platform Engineering erfolgreich zu betreiben. Im Kern geht es um gute Leistungen, gute Services, die man als Team der eigenen Firma zur Verfügung stellt. Es war sehr erhellend zu sehen, dass nicht mit einem Tool wie Backstage angefangen wurde, sondern mit den Problemen, die man in der Softwareentwicklung hat. Bei 2000 Menschen in der Entwicklung kommt natürlich irgendwann eine neue Ebene dazu, nämlich die Metaebene: Wie benutze ich die Plattform möglichst effizient?\n„Im Kern geht es um gute Leistungen, gute Services, die man als Team der eigenen Firma zur Verfügung stellt.“\nFreedom and Rules \nVV\n: Was extrem spannend war, denn diese grundsätzliche Diskussion haben wir auch unabhängig von Platform Engineering immer wieder, war die Frage: Wie viel schreibe ich den Teams vor und wie viel Freiheit gebe ich? Das war dort in meinen Augen sehr ungewöhnlich, denn die Teams hatten sehr viel Freiheit. Wir sagen immer „Freedom and Rules“. Es muss eine Balance geben. Meine Lieblingsanekdote: Jemand, der sehr erfahren war und den wir interviewt haben, sagte, es gebe zu wenige Regeln. Aber dann sagte er wenig später, dass er sich selbst an gewisse Regeln nicht halte. Diesen Kampf haben wir immer wieder, sobald ein Team anderen Teams etwas bereitstellt oder vorschreibt – berühmt-berüchtigt: die Enterprise-Architektur im Elfenbeinturm. Das gab es dort in dieser Form nicht, und das tat auch manchmal weh. Aber das Angebot war einfach gut. Ich hatte nicht nur ein fertiges Kubernetes, sondern auch ein Kubernetes, das schon mit allem verknüpft war, was ich brauchte. Nicht ganz \nout of the box\n, aber es war der berühmte \nGolden Path\n, ein Spotify-Begriff. Das ist ein Riesengewinn. Marc Schnitzius \nsprach von „Cognitive Load“\n. Ich sage ganz banal: Aufwand runter. Ich schaue eher mit einer Management-Brille darauf. Ich will den Aufwand, der nicht notwendig ist, der keinen Value generiert, aus dem Value-Stream-Teams rausnehmen. Das klappt [in dem Unternehmen] einfach gut, weil das Angebot größtenteils schlüssig und aus einem Guss ist und funktioniert.\nMB: \n„Freedom and Rules“ hat bei diesem Kunden auch eine große Auswirkung darauf gehabt, wie die Plattform wahrgenommen wurde. Dadurch, dass die Teams am Ende die Entscheidungshoheit darüber hatten, die Plattform zu nutzen oder nicht zu nutzen und sich selbst etwas zusammenzustellen, eignete man sich implizit die Produktdenkweise an. Man fragte sich, welche Probleme der Teams es wirklich zu lösen gilt, damit die Plattform Traktion erfährt. Das führt zu einer sehr produktorientierten Denkweise im Plattform-Team. In anderen Unternehmen wird den Entwicklungsteams eher etwas vorgeschrieben, was sie als Standard-Entwicklungsprozess nutzen müssen.\nVV:\n Eines der wenigen Dinge, die vorgeschrieben waren: Wenn du in die Cloud gehen wolltest, war ein bestimmter Cloud-Provider vorgeschrieben, und du hast über das Plattform-Team einen Account bekommen. Das fand ich sehr gut. Das sind Basics. Das muss einfach gesetzt sein, sonst herrscht völliges Chaos. Aber in diesem Cloud-Account hätte ich tun und lassen können, was ich will. Ich hätte mit Haskell in Lambda mit einer selbstgestrickten MongoDB arbeiten können. Als ehemaliger Entwickler finde ich das toll. Als Mensch, der den Wildwuchs beherrschen muss, habe ich Angst. Es war gut zu sehen, dass das gut funktioniert hat. \nMB: \nEines der Architekturprinzipien, die sie beim Kunden angewendet haben, war: „You can use the new fancy stuff if you've tried out the old boring stuff first.“ Das hat sehr bei mir resoniert, weil es herrlich pragmatisch ist und gleichzeitig dem Drang, technisch Neues auszuprobieren, entspricht.\nVV:\n Der enge Kontakt mit den Nutzern ist das beste Mittel gegen den Elfenbeinturm. Wir kennen Kunden, wo sich die Enterprise-Architektur etwas ausdenkt, und alle sechs Wochen gibt es ein Architecture Board, bei dem man etwas vorstellen muss, und dann sagen die „Nein“, schicken dich zurück, und sechs Wochen später darfst du wiederkommen. Das gibt es dort [beim Kunden] nicht. Klar, es hat auch Nachteile, wenig vorzuschreiben. Bei Security ist bei uns immer die Grenze erreicht. \nMP: Wenn ihr das Thema Platform Engineering jetzt mit dem erweiterten Horizont beschreiben müsstet, würdet ihr es jetzt anders sehen als am Anfang des Projekts?\nVV: \nWas [beim Kunden] noch besser sein könnte, ist der Produktgedanke. Sie haben eng mit ihren Nutzern gearbeitet, aber eher mit denen, die ohnehin laut waren, weil sie sie gut kannten. Richtig wäre es herauszufinden, welche Nutzergruppen es gibt und wie groß sie sind und danach vorzugehen. Gerade in dieser Größe würde ich jedem dazu raten.\nDas zweite, was ich anders machen würde, ist das Thema Self-Service. Einfach loslegen zu können würde eine deutliche Beschleunigung ermöglichen. Das betrifft nur den Start eines Projekts, eines Services, das muss man sich auch klar machen. Wenn ich die Hürde niedrig halten möchte, gerade am Anfang einer Plattform, wenn sie noch nicht so ausgereift ist, möchte ich, dass die Leute sie benutzen.\nPlattformen auf der Plattform\nMP: Habt ihr bei dem Kunden irgendwelche Patterns gesehen, die für euch ein Augenöffner waren?\nMB: \nSie haben ein Kern-Plattform-Team, das die einzelnen Plattform-Services aufbaut und zur Verfügung stellt. Dadurch, dass sie eine derart große Organisation sind, die in unterschiedlichen Verticals, Produkten und Sparten aufgeteilt ist, haben sich „Platform-on-top-of-platform-Teams“, wie wir sie nannten, gebildet, die die Plattfom-Services genutzt haben, um eigene Mehrwerte neu zu kreieren, beispielsweise, um ein Applikations-Template für ihren spezifischen Bereich neu aufzubereiten, um die Entwickler, die in ihrem Bereich tätig sind, mit einer noch „fertigeren“ Lösung zu unterstützen. Das war ein interessantes Pattern, von dem wir am Anfang noch nicht sicher waren, ob es gut ist oder nicht. Am Schluss kamen wir zu der Erkenntnis, dass es ein sehr positives Zeichen ist, dass es eine lebende Plattform ist, wenn sich diese Teams bilden, wirklich damit arbeiten und eigene Lösungen auf Basis einer Plattform bauen. Denn genau das ist es, was man mit einem Plattform-Gedanken erreichen will. \nVV\n: Es gibt Schichten: ganz unten das Netzwerk, dann kommt vielleicht der Cloud-Provider, dann das Plattform-Team. Ganz oben sind die Value-Stream-Teams. Und wir dachten wirklich erst, zwischen Plattform-Teams und Value-Streams braucht es nichts mehr. Aber wenn ich z. B. einen großen E-Shop baue und darin 30, 40 oder 100 Services habe, haben diese Services in diesem Produkt ähnliche Anforderungen: Sie müssen in die gleiche CI/CD-Pipeline-artige Struktur hinein usw. In der Größe will ich das nicht für 2000 Entwickler standardisieren. Das wäre Wahnsinn. Ich würde völlig stillstehen. Deswegen sage ich, wie Marc, das ist gut. Wie auch Marc dachte ich zuerst: „Das riecht komisch.“ Jetzt sage ich: „It smells like green apples.“\nMB\n: Eine spannende Frage ist: Wie sieht es in Unternehmen aus, die nicht 2000 Menschen in der IT haben? Ich glaube tatsächlich, dass das, was in diesen „Platform-on-top-of-platform-Teams“ passiert ist, durchaus in einem kleineren Kontext in das Plattform-Team hineingezogen werden kann oder sollte. Sie haben sich Blaupausen bzw. Applikationstemplates überlegt – was Projekte, Produkte oder Applikationen sind, die sie häufig bauen, die man als Standard definieren kann – und eine technische Infrastruktur darunter gelegt, um diese skalierbar und wiederverwendbar zu machen. Das kann für ein Plattform-Team viel Mehrwert generieren. \n„Ab acht Teams muss man schon gute Gründe haben, sich aktiv gegen ein Plattform-Team zu entscheiden.“\nVV\n: Sie haben auch Support für ihre Leute geleistet und sie enablet, weil sie deren Fehlersituationen viel besser kennen als ein Plattform-Team für 2000 Leute. Wir glauben, dass dieses Pattern erst ab dieser einer Größe relevant wird. \nWir haben neulich darüber diskutiert, ab wann sich ein Plattform-Team lohnt. Es gab sehr unterschiedliche Meinungen, von „ab zwei Teams“ bis „ab acht Teams“. Wir haben keine finale Meinung. Wir haben festgestellt, dass man ab dem zweiten Team Dinge gleich handhaben muss – etwa, weil das zweite Team einfach nur ein Split des vorherigen Teams ist – und dass man ab dem vierten oder fünften Team auf jeden Fall darauf achten muss, um nicht irgendwann überrollt zu werden und dann hinterherlaufen zu müssen. Eine Daumenregel, auf die ihr mich aber bitte nicht festnagelt: Ab acht Teams muss man schon gute Gründe haben, sich aktiv \ngegen\n ein Plattform-Team zu entscheiden.\nMP: Was sind weitere Punkte, die nicht unter den Tisch fallen sollten?\nVV: \nEine Anekdote: Wir machen am Ende von Projekten immer eine Retrospektive. Die projektexterne Kollegin, die diese moderiert hat, war vorher schon etwas neidisch, weil das alles spannend klang. Hinterher sagte sie: „Jetzt bin ich noch neidischer.“ So war es auch. Das Projekt hat einfach Spaß gemacht, und das muss ich umso deutlicher sagen, weil ich am Anfang skeptisch war, ob es wirklich interessant ist. \nMB\n: Da kann ich mich voll anschließen. Mit einem „Outside View“ auf eine gewachsene Plattform zu schauen war unglaublich spannend. Wir haben viel gelernt und konnten auch glaube ich viel zurückgeben – hoffentlich! Das war sehr schön.\nVV\n: Unsere Empfehlungen kamen extrem gut an. Es war natürlich nicht wahnsinnig viel Neues, aus zwei Gründen: Wir haben ihnen vorab schon erzählt, was unsere Pläne sind, um uns früh Feedback zu holen, damit wir nicht aus deren Sicht in eine falsche Richtung laufen. Wir haben versucht, die Schwerpunkte zu betonen. Denn: Die Leute im Platform Engineering kommen aus der Technik. Gerade die, die früh angefangen haben und viel gemacht haben, kennt das: Dies wird gebaut, jenes hinzugefügt. Dadurch verringert sich die Innovationsgeschwindigkeit, gerade in den Bereichen, die wirklich ausgereift sind. Daher waren sie etwas enttäuscht. Wir arbeiten ja gerne mit der Simon-Wardley-Metapher \n„Pioneers, Settlers, Town Planners“\n. Die Pioneers am Anfang legen einfach los, machen einfach. Wenn dieselben Leute nach drei, vier Jahren immer noch da sind, wird denen langweilig. Denn es bedeutet viel Maintenance. Da brauche ich die Settler oder die Town Planner. Das war ein Effekt, den wir sehr deutlich dort sehen konnten: Die [Pioneers] wollten – natürlich – am liebsten neue Technologien, neue Features machen, und wir haben uns bemüht, sehr nachdrücklich zu sagen: Ihr seid in vielen Bereichen an einer anderen Stelle. Ihr müsst euch vor allem um die Leute kümmern, die neu reinkommen und nicht nur „Fancy Sh...“ machen. So waren sie natürlich nicht, ich übertreibe jetzt. Die waren richtig schlau, deswegen hat die Zusammenarbeit auch unglaublich Spaß gemacht.\nMP: Ich danke euch beiden sehr für eure Zeit! \nVV: \nVielen Dank auch an dich!\nDieses Gespräch führten Marc, Pascal, Marco und Max im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter \nhttps://www.codecentric.de/softwerkercast\n\n\n\n

„Der enge Kontakt mit den Nutzern ist das beste Mittel gegen den Elfenbeinturm“

Cloud FinOps bietet einen etablierten Prozess, um Kosten für den Cloudbetrieb zu reduzieren (s. auch [diesen Artikel](https://www.codecentric.de/wissens-hub/blog/was-ist-finops)). Zu diesem Zweck bietet es ein etabliertes Cloud-unabhängiges Vorgehen, das eine Organisation schrittweise aufgreifen kann.
Das Tooling ist vorhanden, nutzt Daten aus den Cloud-Accounts und hilft im täglichen Geschäft.

## FinOps vs. DevOps ##
Der Begriff FinOps hat in erster Näherung eine Verbindung zum DevOps-Begriff. Bei DevOps geht es um die stärkere Zusammenarbeit der Development- und Operations-Abteilungen entlang der Wertschöpfungskette über Abteilungsgrenzen hinweg. Es ist wichtig zu beachten, dass FinOps nicht nur eine technische Initiative ist, sondern auch eine organisatorische und kulturelle Veränderung erfordert, um den Fokus auf Kosten und Wirtschaftlichkeit in der gesamten Organisation zu fördern. Dies kann die Implementierung von Tools und Prozessen, die Schulung von Teams und die Schaffung einer finanziellen Transparenz umfassen. 

## Cloud-Kosten im Blick behalten ##
Bei FinOps geht es um den Blick auf die Kosten der Cloud-Ressourcen durch alle Beteiligten. In vielen Organisationen, die wir begleitet haben, können Ressourcen bezogen werden, jedoch sind die Kosten für die tägliche Arbeit nicht transparent und im Normalfall nicht für die Optimierung handhabbar.
Bei der Entwicklung einer Funktionalität ist es damit nicht möglich, die Kosten zu sehen, wodurch diese Metrik nicht optimiert wird. Im Resultat steigen die Cloud-Kosten, im schlimmsten Fall ohne eine Erhöhung der Wertschöpfung.

In der On-Premises-Welt ist die Kostenerhebung und -verrechnung ein etablierter Prozess. Vereinfacht gesprochen wird der Bedarf nach Hardware und Infrastruktur für die nächsten Jahre geschätzt und darauf basierend angeschafft. In der On-Premises-Umgebung erfolgt die Kostenverwaltung durch Schätzungen und Anschaffungen von Hardware mit definierten Lebenszyklen. Die monatlichen Kosten werden nach einem festen Schlüssel auf die genutzten Applikationen verteilt, was eine transparente und kontrollierte Ressourcenverwaltung ermöglicht.

## FinOps einführen ##
Machen wir doch einfach FinOps! Ein gelebter Wandel ist nicht mit einem großen Sprung vollzogen, daher bietet das FinOps-Vorgehen die Phasen des „crawl“, „walk“ und „run“ an, um den organisatorischen Fortschritt darzustellen. Am Anfang finden noch viele Dinge manuell statt und werden weiter optimiert und, wenn möglich, automatisiert, um eine höhere Geschwindigkeit zu erreichen.
Wichtig ist hierbei, im Laufe des Prozesses die Unit Economics in den Fokus zu holen. Wie viel kostet es, einen Artikel in den Warenkorb zu legen, oder wie teuer sind die Cloud-Ressourcen pro Kunde? Die Idee ist, diejenigen Kosten zu identifizieren, die nicht zur Wertschöpfung beitragen, um sie gezielt zu reduzieren, während gleichzeitig diejenigen Ausgaben, die das Geschäft vorantreiben, bewusst akzeptiert werden. Dies ermöglicht eine optimierte und zielgerichtete Kostenkontrolle in Bezug auf die Leistungsfähigkeit des Unternehmens.

## Kein Blindflug ##
Durch FinOps sollen nicht blind Kosten gespart werden. Wir beziehen die Cloud-Kosten auf Metriken, die den Geschäftserfolg darstellen. Mehr Bestellungen in einem Online-Shop sorgen für höhere Cloud-Kosten, jedoch ist dies gewollt. Wir wollen nur die unnötigen Kosten sichtbar machen und reduzieren.

## Wie ist unser erprobtes Vorgehen? ##
Wir arbeiten in einem Framework, das im ersten Schritt eine kurze Vorarbeit benötigt, in der die Rahmenbedingungen wie Stakeholder und Verantwortungen abgestimmt werden. Das Framework bietet viele Aspekte, wobei wir einen Start wählen, der schnell erste Einsparungen erlaubt.

Bevor wir optimieren können, müssen wir den aktuellen Zustand erfassen können. Hier liegt die Arbeit darin, das aktuelle Account- und Tagging-Modell zu verstehen und bei Bedarf zu optimieren.
Die Aufgaben und Wünsche aller Beteiligten müssen über Tags und Accounts darstellbar sein, um darüber Auswertungen zu ermöglichen.

Es bietet sich an, wenn man auf der grünen Wiese startet, das Tagging und die Account-Struktur von Anfang an zu planen und umzusetzen.
Bei vorhandener Infrastruktur ist es möglich, mit einem Pilotprojekt zu starten, um die ersten Erfahrungen in der Organisation zu machen. Ein großer Vorteil für Unternehmen, die auf Aspekte des [Platform Engineering](https://www.codecentric.de/leistungen/platform-engineering) setzen, da die benötigten Anpassungen mit weniger Aufwand in der Breite umgesetzt werden können. Technisch ist es z. B. über Terraform oder [Crossplane](https://www.codecentric.de/wissens-hub/fachmedien/crossplane-gitops-fuer-die-multi-cloud) möglich.

Jeder Cloud Service Provider verfügt über eigene Billing-Komponenten, die eine Auswertung der Kosten ermöglichen und Vorschläge zur Kostenreduktion bieten. Nachdem die Tagging-Strategie umgesetzt ist, werden diese Auswertungen hilfreich. Ein erstes Arbeiten ist damit möglich, um die Sparpotenziale zu erkennen.
Sehr gute Ergebnisse erzielen wir bei der Verwendung von FinOps-Tools, die direkt mit den Umgebungen arbeiten. Über diesen Weg werden viele Möglichkeiten der Kosteneinsparung aufgezeigt, die übernommen werden können. Ein Begriff, der an dieser Stelle oft genannt wird, ist „Rightsizing“ und bedeutet, dass Services in einer genau passenden Größe verwendet werden. Um ein Gefühl dafür zu geben, wie es in der Praxis aussehen könnte: Zu große Compute-Instanzen fallen dabei auf.

An dieser Stelle wird das Show-Back und Charge-Back für die Beteiligten relevant. Show-Back bedeutet, dass Kosten der Entstehung zugeordnet werden können. Mit diesem Schritt ist es jedem Team möglich, in Echtzeit auf die Kosten zu schauen und Auswirkungen der eigenen Arbeit zu sehen.
Bei dem sogenannten Charge-Back handelt es sich um die Verrechnung der entstehenden Kosten auf die gewünschten Organisationseinheiten. Ein wichtiger Knackpunkt ist hierbei die Verteilung von verteilten Kosten, die durch ein optimales Tagging- und Account-Modell möglich gemacht werden.

FinOps-Tools sind derzeit im Trend und bieten immer mehr Funktionen zur Berichterstattung über Umweltaspekte wie Green IT und CO₂-Emissionen. Diese Tools sind nicht mehr nur auf die Kostenverwaltung beschränkt, sondern können auch umweltbezogene Metriken liefern. Dies ist im Einklang mit dem wachsenden Bewusstsein für Umweltschutz und Nachhaltigkeit in der IT-Branche.

Nach diesen ersten Schritten ist es ein individueller Weg, welche Aspekte auf dem Framework als Nächstes in den Fokus genommen werden. Wichtig ist es, den Aspekt in die Breite zu tragen und zu verankern: Aufbau eines FinOps-Teams, Aufnahme in Development Guidelines, OKR-Ziele usw. Es bietet sich an, kreativ zu sein und auch mal unkonventionelle Ideen auszuprobieren. Warum nicht einen Wettbewerb ausrufen, welches Team die größten prozentualen Einsparungen vornehmen kann?

## Ausblick ##
Dieser Artikel lieferte einen ersten Einblick in das Thema und gibt ein Gefühl für das Vorgehen. Im nächsten Artikel verknüpfen wir die Kosteneinsparungen mit einem Green-IT-Aspekt, was in den nächsten Jahren ebenfalls an Relevanz gewinnen wird.

SoftwerkerCast - der IT-Podcast von Techies für Techies

Jetzt abonnieren

Hast du Fragen?

Mehr laden

Hier gibt's noch mehr vom Softwerker

Der Softwerker – Das Magazin

Zu den Ausgaben

SoftwerkerKonf

Zur SoftwerkerKonf

Unser SoftwerkerCast-Team

Fragen und Anregungen?

Schreibt uns

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten