Das sollten Softwarearchitekten über Managed Kubernetes wissen

Microservices und 12-Faktor-Apps sind in der Diskussion, aber die Meinungen über die notwendige Infrastruktur zur Unterstützung dieser Anwendungen gehen weit auseinander. Für den Erfolg eines Projekts ist es wichtig, das Gesamtbild zu verstehen. Eine zentrale Frage lautet: Sollte ein Unternehmen einen eigenen Kubernetes-Stack aufsetzen oder eine Managed-Plattform nutzen?

Entwicklungsprojekte starten heute oft mit Kubernetes als Basisplattform für die Ausführung und Orchestrierung von Services. Die integrierten Funktionalitäten reichen allerdings für kaum ein Projekt aus. Wenn ein Unternehmen über die Entwicklung einer Kubernetes-nativen Anwendung nachdenkt, sollte es auch alle erforderlichen Anforderungen berücksichtigen.

Moderne Anwendungen benötigen viel mehr als nur Container und Orchestrierung. Sie werden zum Beispiel mit einem API-first-Ansatz entwickelt und nutzen Service-Discovery und -Aufrufe. Die Applikationen können skaliert werden und den SRE (Site Reliability Engineering)-Teams genügend Informationen liefern, um einen reibungslosen Betrieb sicherzustellen.

Im Idealfall sollten diese Eigenschaften in den Entwicklungsprozess integriert werden, und zwar mit Hilfe eines Änderungs- und Versionsmanagements, das einem modernen Modell für CI (Continuous Integration) und CD (Continuous Delivery) folgt.
Weitere Komponenten, die eine wichtige Rolle für den Erfolg eines Projekts spielen, verstecken sich unter dem Oberbegriff „Kubernetes“. Dazu gehören Compliance, Networking, Disaster Recovery oder Change Management, um nur einige zu nennen.

Prinzipiell haben Architekten nun die Wahl, einen Kubernetes-Stack eigenständig zusammenzustellen oder eine Managed-Plattform wie Red Hat OpenShift zu nutzen. Bei der Entscheidungsfindung sollten sie vor allem

• den Blick über die Kubernetes-Plattform hinaus richten und ihre Projektanforderungen als Plattformanforderungen behandeln sowie
• die Support- und Verantwortungsmatrix für ihr Projekt und die dafür erforderlichen Komponenten definieren und bewerten.

Angesichts der vielfältigen Aufgaben hinsichtlich Plattformfunktionen, Architektur, Kubernetes oder Security ist die Do-it-yourself-Variante selten die beste Wahl. Einfacher ist es, eine passende Plattform auszuwählen. Dies zeigt sich an den konkreten Anforderungen, die eine Managed-Kubernetes-Plattform abdecken sollte. Dazu gehören:

• Bereitstellung zentralisierter Informationen: Für eine reibungslose Entwicklung ist es sinnvoll, relevante Informationen an einem zentralen Ort zu sammeln. Ein Beispiel dafür liefert Quarkus. Das Framework enthält eine Entwickler-Benutzeroberfläche mit Integrationen für Runtime, Messaging und Protokollprüfung. Die Plug-ins der integrierten Entwicklungsumgebung von Red Hat unterstützen Entwickler zudem beim lokalen und Remote-Debugging und -Deployment, wobei eine Integration mit CI und CD auf Red Hat OpenShift gewährleistet ist.
• Self-Service-Optionen: Festgelegte Prozesse helfen zwar bei der Kontrolle des Ressourcenverbrauchs und der Budgetierung, sie können aber auch Entwicklungsprojekte durch unnötige Genehmigungen und Wartezeiten verlangsamen. Ein Self-Service-Ansatz wie bei Red Hat OpenShift gibt Entwicklern die Freiheit, ihre eigenen Ressourcen nach Bedarf innerhalb vordefinierter Standards zu erstellen.
• „Develop once, deploy everywhere“ als Ziel: Bei der Auswahl einer Plattform sollte darauf geachtet werden, dass kein Vendor-Lock-in entsteht. Die Nutzung einer definierten Anzahl von Technologien und Laufzeiten kann zwar unter Governance-Aspekten effizient sein, sie schränkt aber die Flexibilität ein. Die Anforderungen, sowohl aus technischer als auch aus geschäftlicher Sicht, ändern sich schließlich kontinuierlich und schnell. Folglich ist es wichtiger denn je, eine hohe Flexibilität zu besitzen, um Anwendungen etwa on-premises oder an der Edge bereitstellen zu können.
• Weniger YAML-Schreibaufwand: Sinnvolle Vorgaben sind nützlich, um Fehler zu vermeiden, aber sie verlangsamen nur die Entwicklung. Entwickler brauchen die Freiheit, Command-Line-Tools, hochintegrierte Dienstprogramme oder spezialisierte IDEs zu nutzen. Red Hat OpenShift bietet dabei sichere Standardkonfigurationen, sodass Entwickler weniger Zeit für das Schreiben von Konfigurationen aufwenden müssen und stattdessen mehr Zeit für das Schreiben von Code gewinnen. Quarkus bietet zudem einen optimierten Code für 80 Prozent der häufigsten Anwendungsfälle.
• Integrierte Security: Das Sicherheitsmanagement ist ein kontinuierlicher Prozess. Wenn Anwendungen bereitgestellt oder aktualisiert werden, sind dynamische Sicherheitskontrollen entscheidend. Mit Red Hat OpenShift können Architekten Sicherheitskontrollen auf die Software-Lieferkette anwenden. Dadurch wird die Verwaltung von Anwendungen erleichtert, ohne dass die Produktivität der Entwickler beeinträchtigt wird.

Diese wenigen Beispiele zeigen, worauf es bei Managed Kubernetes ankommt. Für eine erfolgreiche Nutzung ist mehr als nur die zugrunde liegende Orchestrierungsimplementierung nötig. Achtet ein Unternehmen auf alle relevanten Anforderungen, gerade auch hinsichtlich moderner Cloud-nativer Lösungen, kann es viele Fehler vermeiden und damit erfolgreich sein. Mit einem Wort: Wenn das Motto lautet „Manage your Business, not Kubernetes“, ist man auf dem richtigen Weg.

Markus Eisele ist Developer Strategist für die Region EMEA bei Red Hat.

Red Hat