“… deine Individualsoftware.” Grundsätzlich können wir fast jede Software in Containern in OpenShift betreiben. Bei Individualsoftware, vor allem im Java-Umfeld, sind wir zu Hause und liegen im Speziellen unsere Stärken.
“Wir bauen und betreiben…” drückt aus, dass wir die Verantwortung übernehmen und nicht nur Werkzeuge oder Beratung anbieten.
“Wir bauen und betreiben…” sagt aus, dass der Build-Prozess einer unserer Stärken ist. Absichtlich nicht “entwickeln”. (Java-) Entwicklung bieten wir an, aber nicht im Rahmen dieses Angebots.
“... und betreiben…” Du als Kunde musst dich nicht um Installation und den Betrieb kümmern. Wir sorgen dafür, dass die Software läuft und du einfach die Funktionen nutzen kannst.
Etwas ausführlicher: “Wir stellen eine Plattform und Dienstleistungen zum Entwickeln, Bauen und Betreiben von Individualsoftware auf Basis der OpenShift Container Plattform zur Verfügung.”
// OpenShift und gepardec-run
Red Hat OpenShift bildet die Basis sowohl für die gepardec-run Container-Plattform als auch für Betriebs- und Entwicklungswerkzeuge. Damit Anwendungen auf gepardec-run laufen können, müssen sie auf OpenShift lauffähig sein. Die Werkzeuge von gepardec-run gehen in einigen Teilen über OpenShift hinaus.
Build Pipelines
In OpenShift können Build Pipelines mittels
- BuildConfig und Trigger
- OpenShift Pipelines
- Jenkins
erstellt werden. In gepardec-run erstellen wir Pipelines mittels
Deployment
Wir setzen primär auf das in OpenShift vorhandene Argo CD. Das Deployment ist eng mit dem Build-Prozess (Argo Workflows) integriert, sodass Pipelines von der Entwicklung bis zur Produktion definiert werden können.
Observability
Unter Observability fassen wir die Themen Metriken, Logging und Tracing zusammen. OpenShift bietet derzeit dafür eher dürftige einzelne GUIs und einige vorgefertigte, nicht veränderbare Dashboards.
Wir arbeiten an einer integrierten Lösung, die Metriken, Logging und Tracing auf Basis von Grafana zusammenführt. Insbesondere sollen alle Metriken, egal aus welchen Bereichen (Entwicklung oder Betrieb), zentral verknüpfbar und auswertbar sein.
Alerting
Wir verwenden den AlertManager von OpenShift Monitoring.
Container Registry
Wir binden eine Container Registry des Kunden ein oder verwenden die interne OpenShift Registry.
Source Code Repository
Wir integrieren Git-Repos des Kunden oder freie, wie z.B. GitHub. OpenShift hat kein Source Repository integriert.
Security Scans
Trivy wird zum Scannen zur Build-Zeit verwendet. OpenShift hat per Default keine Security Scans. Zusatzprodukte können eingebunden werden.
// Managed OpenShift Angebote und gepardec-run
Es gibt mehrere Managed OpenShift Angebote. Siehe z.B. https://developers.redhat.com/products/openshift/overview oder auch https://www.appuio.ch/offering/managed/
Wie unterscheiden sich diese Angebote von gepardec-run?
Kurzfassung: Bei gepardec-run benötigst du als Kunde kein Wissen zu OpenShift oder Kubernetes.
Managed OpenShift Angebote stellen die OpenShift Plattform zur Verfügung. Sie ist dann grundsätzlich installiert und läuft. Um sie zu verwenden, benötigst du aber einerseits beträchtliches Kubernetes-Wissen, wie Anwendungen darauf installiert und konfiguriert werden, andererseits auch anwendungsspezifisches technisches Wissen zum Betrieb der Applikationen. Dieses Wissen wird in gepardec-run bereitgestellt
Für die Entwicklung gilt analoges zum Betrieb. Managed OpenShift Angebote stellen einige Tools zur Verfügung, aber das Wissen über den Aufbau effektiver Build Prozesse muss beim Kunden vorhanden sein. Auch hier bietet gepardec-run einen wesentlichen Mehrwert.
// gepardec-run powered by VSHN
gepardec-run wird in Zusammenarbeit mit VSHN durchgeführt, wobei VSHN den OpenShift Cluster (auf A1 Exoscale Infrastruktur) baut und zur Verfügung stellt und den 24/7 Support im technischen Betrieb gewährleistet.
// Begriffsklärung
Technischer Anwendungsbetrieb
Unter technischem Anwendungsbetrieb verstehen wir, dass wir sicherstellen, dass Anwendungen technisch korrekt zur Verfügung stehen. Das beinhaltet, dass die Anwendung
- … für den Anwender verfügbar ist
- … genügend Ressourcen an Speicher und CPU erhält
- … die Verbindung zu benötigten internen Komponenten funktioniert
- … die Verbindung zu benötigten externen Systemen funktioniert
- … aus Securitysicht auf aktuellem Stand ist
Die Tätigkeiten des technischen Anwendungsbetriebs werden von der Rolle Technische:r Anwendungs-Betriebsmitarbeiter:in ausgeführt. Gute Kenntnisse im Thema Observability nutzt er oder sie, um auch andere Bereiche zu unterstützen.
Benötigte Kenntnisse:
- Wie arbeitet Kubernetes, wie werden Applikationen darauf gestartet
- Kubernetes Ressourcen und Umgang damit
- Wie bekommt man Infos über Kernmetriken von in Kubernetes wie CPU oder Memory
- Konzepte und Umgang mit Observability, Werkzeuge wie Grafana, Prometheus, …
- Debuggen von Applikationen in Kubernetes
- Grobes Verständnis über fachliche Zusammenhänge der Anwendungen
Fachlicher Betrieb
Der fachliche Betrieb ist dafür verantwortlich, dass die Anwendung inhaltlich korrekt funktioniert.
Die Tätigkeiten des fachlichen Betriebs werden von der Rolle Fachliche:r Betriebsmitarbeiter:in ausgeführt.
Benötigte Kenntnisse:
- Detailliertes Verständnis über fachliche Zusammenhänge der Anwendungen
- Ablauf der Geschäftsprozesse
- Datenmodelle und ihre fachliche Funktion
- Grobes Verständnis der technischen Applikationslandschaft
Fachliche Feature-Entwicklung
Die Feature Entwicklung ist der Kern der Softwareentwicklung. Sie implementiert den für die fachlichen Funktionen notwendigen Code.
Die fachliche Feature-Entwicklung wird von der Rolle Fachliche:r Feature Entwickler:in ausgeführt.
Benötigte Kenntnisse:
- Implementierungssprache der jeweiligen Fachanwendung (z.B. Java)
- Softwarearchitektur
- Interne Details der Fachapplikation
- Grobes Verständnis zu Kubernetes und Cloud Plattformen
Build Automatisierung
Die Build Automatisierung ist dafür verantwortlich, dass die für die Entwicklung notwendigen Prozesse wie Build oder automatisierte Tests technisch funktionieren. Sie sorgt dafür, dass die fachliche Feature Entwicklung sich auf ihre Kernaufgabe konzentrieren kann. Die für die Tätigkeit nötige Rolle bezeichnen wir als Build Automatisierer:in
Benötigte Kenntnisse:
- Konzepte und Werkzeuge zum Aufbau von Build- und Deployment Pipelines
- Kubernetes Ressourcen und Umgang damit
- Konfiguration der in der Applikation verwendeten Runtime (z.B. Quarkus, EAP)
- Abhängigkeiten zu anderen Applikationen
- Skriptsprachen und Werkzeuge zur Automatisierung von wiederkehrenden Tätigkeiten in der Entwicklung.
Transition
Die Transition ist das Bindeglied zwischen Entwicklung bzw. Build und Betrieb. Sie ist dafür verantwortlich, dass die in der Entwicklung erzeugten Anwendungen in Produktion gelangen. Dafür ist organisatorisch die Rolle Release Koordinator:in und auf technischer Ebene die Rolle Deployment Automatisierer:in verantwortlich.
Deployment Automatisierung
Dabei werden technische Deploymentprozesse von der Rolle Deployment Automatisierer:in entwickelt und umgesetzt.
Benötigte Kenntnisse:
- Konzepte und Werkzeuge zum Deployment komplexer Applikationslandschaften
- GitOps Konzepte und Werkzeuge, ArgoCD
- Kubernetes Ressourcen und Umgang damit
- Zusammenhänge der Applikationslandschaft
Release Koordination
Die Rolle Release Koordinator:in sorgt dafür, dass bei der Einführung einer neuen Funktion (neue Applikation oder neue Version einer Applikation) die fachlichen und organisatorischen Voraussetzungen gegeben sind.
Benötigte Kenntnisse:
- Releasepläne der Anwendungen und der Abhängigkeiten
- Fachliche Zusammenhänge der Anwendungen
- Grobes Verständnis zu Kubernetes und Cloud Plattformen
Werkzeuge für Betrieb bereitstellen
Bei diesen Tätigkeiten werden von der Rolle Betriebs-Tools Ersteller:in Applikationen bereitgestellt, die der Betrieb für seine Arbeit benötigt. z.B. Monitoring oder Logging Tools. Sie sind danach in einem Zustand, wie sie vom Erzeuger per Default ausgeliefert wurden. Es gibt keine Anpassung an die speziellen Anforderungen des Betriebs. Diese werden von der Rolle Technische:r Anwendungs-Betriebsmitarbeiter
Benötigte Kenntnisse:
- Kubernetes Ressourcen und Umgang damit
Werkzeuge für Entwicklung bereitstellen
Analog zu oben für die Rolle Entwicklungs-Tools Ersteller:in für Entwicklung statt Betrieb.
Benötigte Kenntnisse:
- Kubernetes Ressourcen und Umgang damit
// Rollenverteilung und Zusammenarbeit mit Kunden
Die grobe Aufteilung der Verantwortung zwischen dir als Kunde und Gepardec bei der Arbeit in gepardec-run ist:
Du als Kunde kümmerst dich um die fachlichen Aspekte deiner Applikationslandschaft und um die Implementierung der Geschäftslogik. Die Mitarbeiter sollten ein grundlegendes Verständnis zur Cloud Plattform haben, benötigen aber kein Detailwissen, wie die Plattform installiert, bzw. wie Applikationen darauf installiert werden.
Gepardec kümmert sich darum, dass aus vorhandenem Source Code eine ausführbare Applikation wird und diese stabil und sicher auf einer Cloud Plattform betrieben wird.
Aus dieser Aufgabenverteilung ergeben sich Schnittstellen, die Notwendigkeit zur Zusammenarbeit und gegenseitige Anforderungen.
Technischer Betrieb – Fachlicher Betrieb
Beide Rollen sind für die korrekte Funktion der Anwendungen verantwortlich. Der eine auf fachlicher, der andere auf technischer Ebene. Die Grenzen, besonders bei komplexen Fehlerbildern oder Performanceproblemen, sind nicht immer scharf zu ziehen. Dadurch ist ein gewisses Verständnis der jeweils anderen Domäne nötig. Der technische Betrieb benötigt vom fachlichen Betrieb Informationen über die fachlichen Zusammenhänge in den Anwendungen. Umgekehrt kann der technische Betrieb den fachlichen Betrieb bei Auswertungen oder bei der Erstellung von Dashboards unterstützen, die diesem bei der Analyse der Anwendung helfen.
Technischer Betrieb – Entwicklung
Die Rolle Technische:r Anwendungs-Betriebsmitarbeiter
Auch zur Verbesserung der Observability, z.B. beim Einbau von speziellen Metriken, kann der Betrieb Änderungen von der Entwicklung benötigen.
Bei der Fehleranalyse ist eine Zusammenarbeit von Entwicklung und technischem Betrieb notwendig. Damit dies effizient geschieht, stellt der technische Betrieb der Entwicklung Informationen, z.B. Logs und Metriken zur Verfügung.
Deployment Automatisierer:in – Release Koordinator:in
Beide Rollen sind für die Inbetriebnahme von Anwendungen verantwortlich. Einerseits auf technischer, andererseits auf organisatorischer Ebene. Damit die Inbetriebnahme reibungslos funktioniert, müssen sich beide Rollen zeitlich und inhaltlich abstimmen.
Build Automatisierer:in – fachliche:r Feature-Entwickler:in
Die Rolle Build Automatisierer:in benötigt von der Feature Entwicklung Informationen, welche Komponenten es gibt und wie sie zusammenspielen.
Umgekehrt stellt die Rolle Build Automatisierer:in der Feature-Entwicklung Auswertungen über Builds und Tests zur Verfügung. Darüber hinaus unterstützt sie bei entwicklungsspezifischen Automatisierungen.
// Organisation und Rollen
Die oben dargestellten Rollen werden in gepardec-run nicht unbedingt von unterschiedlichen Personen ausgeführt. Die Rollen Technische:r Anwendungs-Betriebsmitarbeiter:in, Deployment Automatisierer:in, Build Automatisierer:in sollten für eine Applikation von 1-2 Personen ausgefüllt werden. Wir präferieren die Organisation in cross-funktionalen Teams, in denen ein Team eine Anwendung unterstützt. Die Teams sollten einem agilen Prozess (z.B. Scrum) folgen.
// Autor:in
Erhard Siegl
