Heimat für Container

Ein bisschen Cloud-Erfahrung und ein großes weißes Blatt reichen nicht aus, um eine zukunftsfähige IT-Umgebung für Kunden aus der Bankenbranche zu designen. Es braucht dazu insbesondere auch tiefe Expertise und kongruentes branchen- sowie bereichsspezifisches Vorausschauen. Es ist nämlich wirklich keine einfache Aufgabe, eine solche IT-Umgebung zu entwickeln – aber eine überaus wichtige. Und genau deshalb, weil wir die Relevanz erkannt hatten und wussten, wir verfügen auch über die entsprechende Fähigkeiten- und Wissensbasis, haben wir uns ihrer angenommen: 2018 stellte sich ein kleines Team bei FI-TS dieser Herausforderung – und schuf mit scharfem Verstand und auf Basis der Annahme, dass Workloads bald bevorzugt in Containern laufen werden, die FI-TS Finance Cloud Native (FCN). Im 30. Jahr von FI-TS zeigt sich längst klar: Die Enthusiasten von damals lagen richtig. Die FCN ist für uns und unsere Kunden längst unerlässlich geworden und zentraler Bestandteil unseres Angebots.

Allgemein gilt, wer eine erfolgreiche Plattform aufbauen will und entsprechend auch ordentlich in Hardware und Personal investieren muss, steht vor einer Richtungsfrage, die fast seherische Fähigkeiten verlangt: Welchen Technologiestack soll man bloß verwenden? Was heute alle Funktionen abdeckt und praktische Verwaltungstools beinhaltet, kann in zwei oder fünf Jahren schon zur Sackgasse geraten. Die IT-Geschichte ist reich an solchen Beispielen. Eine kleine Truppe von Technikenthusiasten um Abteilungsleiter Christian Brunner (Bild unten) stand nun also bei uns im Jahr 2018 vor einer solchen Richtungsentscheidung. Und sie fand schnell den zentralen, und wie wir inzwischen längst wissen, auch tatsächlich zukunftsweisenden Ansatz: Im Zentrum sollte das Hosting von Containern stehen. Denn keine andere Technik unterstützte die Devops-Prinzipien, agiles Entwickeln und das Skalieren von Microservices besser.

Eine Open-Source-Lösung nehmen?

Nun machten sich die IT-Architekten auf die Suche nach einer Infrastrukturplattform für den Betrieb ihrer Containerdienste. Sie evaluierten hierfür zunächst alle einschlägigen Open-Source-Produkte und -Projekte. Aber fast alle zeigten Unzulänglichkeiten in Sachen Enterprise-Netzwerk oder verlangten nach Kompromissen in anderer Hinsicht. Mit einem gut passenden Feature-Set konnte lediglich OpenStack punkten. Allerdings gab es hier einen anderen großen Haken: Es war besaß eine herausfordernde Komplexität, und die häufigen Updates waren sehr mühselig umzusetzen. Außerdem lag die Systemsicherheit in der Verantwortung der vielen OpenStack-Einzelprojekte, statt im Sinne von Security by Design als Gesamtaufgabe an der Spitze des Projekts verankert zu sein.

Auch angesichts der anspruchsvollen FI-TS-Kunden, die sicherheitskritische Anwendungen rund um die Uhr anbieten, entschied sich das Team um Christian Brunner deshalb am Ende gegen den modularen Riesenbaukasten OpenStack. Und Stefan Majer, Netzwerkspezialist sowie leidenschaftlicher Go-Programmierer, erläutert dazu weitergehend: »Das Netzwerkdesign von OpenStack war mir schon damals zu konventionell und statisch gestrickt. Wer heute eine Cloud für die Zukunft konzipiert, muss auch etwa für sprunghaftes Wachstum gewappnet sein.« Inzwischen wissen wir längst aus unserem Alltag, wie entscheidend der Faktor Dynamik ist. Auch unter diesem Gesichtspunkt war das Nein zu OpenStack also richtig.

Beim konventionellen Marktführer kaufen?

Nun richtete das Brunner-Team seinen Blick auf den Marktführer für kommerziellen Linux-Kubernetes-Betrieb: Das 1993 gegründete Linux-Pionier-Unternehmen Red Hat hatte mit OpenShift eine Kubernetes-Betriebsplattform für Rechenzentren am Start. Am Markt etabliert und zudem technisch geeignet – ein klares Signal für die Weichenstellung in Haar nahe München?

Mitnichten. Christian Brunner und Stefan Majer klangen noch die Worte von Mark Shuttleworth, dem südafrikanischen Canonical-Gründer und Ubuntu-Linux-Finanzier, in den Ohren. Der hatte Mitte 2018 auf dem OpenStack Summit im kanadischen Vancouver für einen Eklat gesorgt, indem er in seiner Keynote offenbart hatte, dass Kunden von Red Hats OpenStack- und Kubernetes-Lösung dreimal mehr Maintenance-Kosten als nötig berappen mussten (siehe Abbildung unten). Shuttleworth’ bissiges Fazit in Richtung Red Hat: „Wir investieren, um effizienter zu sein, nicht um mehr Kosten zu verursachen.“

Hinzu kam, als das Team um Christian Brunner Ende 2018 die wegweisende Entscheidung treffen musste, wurde klar, dass IBM Red Hat übernehmen würden. Es stand also sehr infrage, dass von jener Seite, der elementare Umwälzungen bevorstehen mochten,die nötige technologische Konstanz erwartet werden konnte. Wie und wann würde der neue Eigentümer das Produktportfolio umgestalten, wie würden sich die Preise entwickeln? Und könnte man dann noch reagieren, drohte bei dieser Grundsatzentscheidung nicht der so genannte Vendor-Lock-in, also die praktisch komplette Abhängigkeit vom Anbieter, da ein Wechsel quasi unmöglich sein würde? Nein, bei allen Vorzügen, Red Hat kam für uns doch nicht infrage.

Auf Partnerpluralität vertrauen – und selbst weiterentwickeln

Doch was tun, wenn sowohl klassische Anbieter als auch solitäre Open-Source-Protagonisten keine passenden Partner für uns waren? Die durch und durch rationale und zugleich moderne Antwort unseres Entwicklungsteams war: Wir nehmen Open-Source-Software, bei der die Codebeiträge nicht nur von einer Firma kommen, und den Rest programmieren wir selbst!

Mit intensiver Suche im Internet, nach Testinstallationen und über Diskussionen auch nach außen stieß das Team auf das SAP-Gardener-Projekt (https://gardener.cloud), einen Kubernetes-Cluster-Manager, der tausende Kubernetes-Cluster hochautomatisiert installieren, verwalten und überwachen kann, und dies auf verschiedenen Public- und Private-Cloud-Plattformen. Er konnte genau das, was wir brauchten. Überdies war das zugehörige API jenem von Kubernetes sehr ähnlich, die Schnittstellenanbindung also leicht möglich, und die wichtigen Gardener-Komponenten liefen ebenfalls in Kubernetes-Clustern (siehe Abbildung 3). Kurzum, unser Team war fündig geworden! Die Entscheidung fiel nun ganz leicht, und wir arbeiten seitdem mit SAP Gardener. Wie wir heute mit Bestimmtheit sagen können, hat FI-TS so genau den richtigen Weg eingeschlagen: Diese Open-Source-Software, die trotz ihres Namens nicht nur von einer großen Firma abhängig ist, als Zentrum der eigenen Cloud zu benutzen und zugleich an dem Projekt mitzuarbeiten, erwies sich als wahrer Glücksgriff – wobei das Wort hier nur bedingt passt, denn vor allem haben Brunner, Majer und die anderen Teammitglieder einfach sehr gute Arbeit geleistet.

Weitere Weichenstellung: Kubernetes-Maschinen selbst verantworten

Nach und neben dieser Grundsatzentscheidung für SAP Gardener waren selbstverständlich noch viele weitere elementare Weichenstellungen nötig. Auch hier bewies das Brunner-Team ein ausgezeichnetes Gespür. Hinsichtlich der Betriebsplattform etwa kam man überein, die Kubernetes-Maschinen nicht virtuell und keinesfalls bei einem Public-Cloud-Riesen laufen zu lassen. So sollten nicht nur Lizenzkosten und Administrationsaufwand eingespart, sondern sollte vor allem die Mandantentrennung für die sensible Kundschaft gewährleistet werden.

Die Sorge vor unautorisiertem Informationsabfluss war dabei von vornherein nicht lediglich theoretischer Natur: Mit Meltdown und Spectre waren 2018 zwei handfeste Sicherheitslücken in Prozessoren öffentlich geworden, gegen die allenfalls Workarounds halfen. Und auch für aktuelle CPUs ist das facettenreiche Thema Seitenangriffe eine fortwährende Bedrohung, es ist mithin bis heute nicht vom Tisch.

Die neue Cloud sollte also direkt auf Hostcomputern (im IT-Jargon: „auf Blech“) laufen – und dabei sollte dies nicht nur für die Kubernetes Compute Nodes gelten, sondern auch für die Kundencluster-dedizierten Firewall-Nodes. So etwas gab es noch nicht – also bauten wir es neu auf. „Wir wollten eine frische und saubere Herangehensweise an das ganze Thema Infrastruktur, und wir waren dazu bereit, etwas Innovatives selbst zu entwickeln“, schildert Christian Brunner die Situation damals. Die erste Version unserer Neu- resp. Weiterentwicklung hieß Metal Pod, drei Monate später bekam sie den noch heute verwendeten Namen Metal Stack (https://metal-stack.io).

Via Metal Hammer von Anhängigkeiten befreien

Für die Nodes kaufte Brunner Blade-Server der Big-Twin-Serie von Supermicro, die sich lediglich die Stromversorgung teilen, was Abhängigkeiten bei Ausfällen minimiert. Und jeder Server im Compute-Pool bekam eine Verbindung zu einem speziellen Verwaltungsnetzwerk, welches das Provisionieren vom Betriebssystem – meist Debian Linux – sowie von Kubernetes- und Gardener-Komponenten regelt. Dieses selbst entwickelte Verwaltungsnetzwerk ist im Kern ein Bootstrapping-Agent – und dieser wiederum trägt den eindrücklichen Namen Metal Hammer.

Zudem führten die IT-Architekten die Netzwerkinterfaces aller Compute- und Firewall-Nodes redundant aus. Das war gut für die Ausfallprävention (ein kleiner Wehrmutstropfen, es verdoppelte auch die Zahl der nötigen Switchports am anderen Ende der Verkabelung). Eine flache Netzarchitektur wurde auf Vorschlag von Stefan Majer realisiert, der im Januar 2019 zur Inspiration den Open Net Summit in Amsterdam besucht hatte, durch ihn setzte das Team zudem auf Hardware, die dem Open-Computing-Networking-Konzept folgt. Als Switch-Betriebssystem wurde Cumulus Linux genommen, der Klassiker in Sachen Software-defined Networking. Zudem wurde ein EVPN-Overlay (Ethernet Virtual Private Network) in Layer 2 des Stack eingebracht, und im Layer 3 separieren VRF-Instanzen (Virtual Routing and Forwarding) die Kubernetes-Cluster von ihren Nachbarn.

Stehen Cluster-Updates an oder ist mal eine Störung zu beseitigen, verfolgen durch die vom Brunner-Team installierte Architektur sowohl Kubernetes als auch SAP Gardner und Metal Stack den gleichen modernen Ansatz: Die Administratoren ändern keine Konfigurationen und patchen auch keine laufenden Systeme, sondern wechseln die bestehenden Systeme kurzerhand gegen funktionierende neue aus. Und die APIs unterstützen dies durch einfach erlernbare Kommandos, die kundenseitig eingegeben werden können. Damit dabei keine Daten verloren gehen, gibt es in jedem Rechenzentrum zudem zentrale Storage-Komponenten, die Updates jeder Art überleben: das FCN Blockstorage (eine NVMe-over-Ethernet-Lösung) ersetzt Node-lokale SSDs, und das FCN Objectstorage fungiert als günstiges Backup-Ziel.

Ein Dauerbrenner – der stetig weiterentwickelt und größer wird

Heute betreibt FI-TS die Finance Cloud Native in vier deutschen Rechenzentren in der vielfachen Größe im Vergleich zu 2019, dabei launchen wir weiterhin stetig neue Features. Unsere Kunden melden uns zurück, dass sie überaus zufrieden sind, und dass sie etwa dank der horizontalen und vertikalen Skalierungsautomatiken ihre Anwendungen auf der Plattform mit einer derart hohen Effizienz betreiben, wie sie Legacy-Systeme ihnen keinesfalls bieten könnten. Mehr hierzu erfahren Sie in der Referenz unseres Kunden GuideCom.

Passend zum Immer-größer-Werden der FCN ist auch das Team von Abteilungsleiter Christian Brunner gewachsen. Doese Team sorgt zuverlässig weiterhin dafür, dass Innovation permanent stattfindet. So kann die Finance Cloud Native heute ihren Kunden etwa auch gemanagte Microservices anbieten, wie georedundante PostgreSQL-Datenbanken, Apache Kafka oder Elasticsearch.

Das Ergebnis: eine moderne und flexible, skalierbare und sichere Cloud-Umgebung

Der Blick auf die Anfänge und die Entwicklung des Finance Cloud Native Stack zeigt, dass für den Marathon, den es braucht, wenn es um eine dauerhaft moderne und flexible, skalierbare und sichere Cloudumgebung geht, gerade die ersten hundert Meter entscheidend sind – wie so oft bei wirklich neuen Technologien. Wichtig dabei: Die ersten hundert Meter dürfen nicht in einem Full-Sprint durchgezogen werden, nach dem man dann lediglich atemlos zum Stillstand kommt, sondern sie müssen den Rhythmus setzen und die richtige Ausgangsposition sichern. Hierzu kommt es etwa auf die Wahl der Strategie, der Taktik und der Softwarekomponenten an. Das Team Brunner hat genau hier verdammt viel richtig gemacht – und dadurch viel dazu beigetragen, dass FI-TS im 30. Jahr noch besser dasteht denn je.