Die IT unterliegt kontinuierlichem Wandel. Dieser macht auch vor moderner Softwareentwicklung nicht halt. Bereits vor einigen Jahren gab es von O’Reilly oder IBM Untersuchungen zu Verbreitung und Akzeptanz von Microservices. Bereits damals haben viele Unternehmen sich klar dafür ausgesprochen. Auch wenn diese Entwicklung in erster Linie die Softwareentwicklung betrifft, so hat sie zur Folge, dass sich auch der IT-Betrieb entsprechend anpassen muss. Dabei spielt es keine Rolle, ob man selbst Software entwickelt oder sie von Drittherstellern bezieht in Form einer Microservice-Architektur bezieht wird. Für den Betrieb solcher Software hat sich in den letzten Jahren Kubernetes durchgesetzt. Entsprechend stehen früher oder später fast alle Unternehmen vor der Herausforderung, eine eigene Kubernetes-Plattform aufzubauen. Angesichts der Vielzahl an Herstellern und Open-Source-Lösungen und der in jedem Fall vorhandenen sehr hohen Komplexität ist dies keine einfache Aufgabe. Besonders, wenn man bedenkt, dass Kubernetes durch seine nahezu unbegrenzten Erweiterungsmöglichkeiten das Potential zum Herzstück einer gesamten Unternehmens-IT-Infrastruktur hat und eine entsprechend kritische Position in der IT-Landschaft des Unternehmens einnimmt.
Doch wie gehen wir diese Aufgabe am besten an? In dieser dreiteiligen Artikelreihe befassen wir uns mit diesem Thema. Den Anfang macht eine Definition, was eine Plattform ist und welche Herausforderungen sie mit sich bringt, bevor wir in Teil zwei den Open-Source Do-It-Yourself (DIY) Ansatz behandeln. Im dritten und letzten Teil beleuchten wir abschließend den herstellerfokussierten Turnkey Ansatz genauer.
Plattform-Definition
Der Begriff Plattform wird in der IT sehr häufig verwendet. Und wie so oft geht das Verständnis bei diesem Begriff weit auseinander. Die Cloud Native Computing Foundation (CNCF) hat Anfang 2023 ein Whitepaper veröffentlicht, dass diesen Begriff etwas genauer erläutert.
„Die CNCF definiert eine Plattform als eine Sammlung von Tools und Diensten, die darauf abzielen, die Entwicklung, Bereitstellung und Verwaltung von Software zu vereinfachen.“
Quelle: https://tag-app-delivery.cncf.io/whitepapers/platforms/
Die Plattformen als Produkt
Welche spezifischen Tools und Dienste also bereitgestellt werden müssen, hängt stark von den Bedürfnissen der Stakeholder ab und muss im Vorfeld sorgfältig ermittelt werden. Natürlich sollte der Fokus auf den Funktionen liegen, die am häufigsten gefragt werden. Dabei gilt: Je spezifischer diese sind, desto später sollten sie implementiert werden – wenn überhaupt.
Nach der initialen Implementierung der Plattform ist die Arbeit jedoch noch nicht beendet. Die Softwareentwicklung verändert sich rasant und ihre Anforderungen entwickeln sich stetig weiter. Das bedeutet, dass auch die Plattform kontinuierlich angepasst und weiterentwickelt werden muss. Nur so kann die Akzeptanz langfristig gesichert und dem Unternehmen ein Mehrwert geboten werden.
Eine Plattform sollte somit als Produkt des IT-Operations-Teams für die Benutzer betrachtet werden, selbst wenn sich alles innerhalb eines Unternehmens abspielt. Folglich muss die Plattform auch entsprechend behandelt und gepflegt werden. Konkret bedeutet dies, dass Aspekte wie Nutzerzufriedenheit und Effizienz kontinuierlich überwacht werden sollten. Dabei spielt es keine Rolle, ob die Plattform in Eigenregie (DIY) entwickelt oder als schlüsselfertige Lösung (Turnkey) implementiert wurde. Die initial aufgenommenen Anforderungen können jedoch bereits wertvolle Hinweise darauf geben, welcher Ansatz – DIY oder Turnkey – für die jeweilige Situation am besten geeignet ist.
Anforderung an Plattform und Team
Das Team
Die wohl offensichtlichste und zeitgleich am meisten vergessene Anforderung ist wohl, dass überhaupt ein Plattform-Team existieren muss. Ohne entsprechend qualifiziertes Personal, das sich um die Plattform kümmert, wird diese nach und nach verfallen. Es reicht nicht, wenn sich einmal im Jahr jemand um Updates kümmert. Zum einen ist das Update-Intervall mit wenigen Wochen bis Monaten wesentlich schnelllebiger und zum anderen findet auf diese Weise keine Weiterentwicklung statt. Zusätzlich führt die fehlende Routine im Umgang mit der Umgebung zu Fehlern, wenn nicht sogar zu Ausfällen oder Datenverlust.
Die Plattform
Das Ziel jeder Plattform ist es, die darunter liegenden Mechanismen von den Benutzern fernzuhalten und zu abstrahieren, damit sie sich voll auf die Entwicklung ihrer Services konzentrieren können. Denn letztendlich sind es eben diese Services, welche die Existenzberechtigung für die gesamte Plattform darstellen.
Die Plattform sollte den Cloud-Kriterien der NIST entsprechen, also unter anderem den Benutzern Self-Service-Zugriffe auf die Plattform-Funktionen ermöglichen, ohne dass menschliche Intervention seitens des Plattform-Teams nötig ist. Darüber hinaus muss sie natürlich auch die firmeneigenen Ansprüche an Security und Compliance erfüllen. Dies sollte weitestgehend automatisiert erfolgen, damit sich die Benutzer darüber keine Gedanken machen müssen.
Die Plattform selbst wechselt kontinuierlich zwischen dem klassischen Betrieb, wie z. B. Monitoring, Skalierung, Troubleshooting, und der Weiterentwicklung, zu der Upgrades oder das Hinzufügen neuer Funktionen zählen. Das wiederum erfordert fortlaufende Feedbackloops zwischen Plattform-Team und den Anwendern, um bestehende Funktionen anzupassen, neue zu entwickeln oder nicht mehr gebrauchte abzuschalten.
Herausforderungen
Plattform-Bau (allgemein)
Es ist essenziell, die Anforderungen an die Plattform im Vorfeld zu bestimmen. Keine Plattform wird nur der Plattform wegen gebaut (mit Ausnahme von HomeLabs). Stattdessen sollen sie einen Business Case bedienen, an den bestimmte Anforderungen gebunden sind, die vorab durch die Stakeholder formuliert wurden. Wird an deren Bedarfen vorbei entwickelt, werden im schlimmsten Fall Workarounds gefunden, um die Nutzung der Plattform zu umgehen. Neben den Anforderungen der Entwickler sind hier auch die an Betrieb und Sicherheit zu berücksichtigen.
Ist das Ziel definiert, können daraus entsprechende Lösungen ausgewählt und es kann mit dem Design begonnen werden. Dazu gehören Fragestellungen wie z. B.:
- Welche Tools, Lösungen, Module werden benötigt?
- Wie passen diese zusammen?
- Wie müssen sie konfiguriert werden?
Steht die erste Version der Plattform, sollte sie vor Produktivsetzung ausgiebig getestet werden. Zum Überprüfen der Funktionsfähigkeit eignen sich Pilotprojekte. Selbstverständlich dürfen sie sich vor erfolgreichem Abschluss der Plattform-Testphase nur im Test- und nicht Produktivbetrieb befinden. Auch Last- oder Pentests sollten nicht vergessen werden.
Wurden alle Tests erfolgreich abgeschlossen, kann die Plattform in den Regelbetrieb übergehen. Dieser umfasst neben Fehlerbeseitigung und dem Warten bzw. Patchen der Umgebung auch die Weiterentwicklung der angebotenen bzw. die Implementierung neuer Funktionen.
Während in der Implementierungsphase oft alle hochmotiviert sind, so denkt kaum jemand an den späteren Betrieb. Dabei sind die Anforderungen einer Cloud-Native-Plattform auch hier grundlegend anders als bei einer traditionellen Silo-Architektur. Das notwendige „Automation-first“- bzw. GitOps-Mindset erfordert auch hier ein deutliches Umdenken und höchstwahrscheinlich auch entsprechende Umstrukturierungen in den Teams. Wer versucht Kubernetes oder eine vergleichbare Lösung mit traditionellen oder vielleicht sogar manuellen Methoden zu administrieren, wird schnell in Arbeit untergehen. Zusätzlich wird die Akzeptanz der Plattform sinken. Das Betriebsmodell einer solchen Umgebung stellt eine ganz eigene Herausforderung dar, eine detailliertere Betrachtung würde jedoch den Umfang dieser Artikel-Reihe sprengen.
Die Durchführung dieser Schritte erfordert Personal mit entsprechenden Skills. Ist das nicht verfügbar, so muss es zuvor entweder aufgebaut oder eingekauft werden.
Schlusswort
Dieser Artikel hat dargelegt, wie wichtig es ist, die Anforderungen zu kennen, bevor eine Plattform gebaut werden kann. Darüber hinaus hat er gezeigt, dass es auch nach abgeschlossener Implementierungsphase wichtig ist, die Umgebung kontinuierlich weiterzuentwickeln. Im nächsten Teil betrachten wir, wie wir dies mit Open-Source realisieren können und welche Herausforderungen dieser Ansatz mit sich bringt.