Über Container IaC und GitOps - Notwendigkeit der Containerisierung

Heutzutage entwickelt man agile – und agile heißt, möglichst schnell von der Kundin oder dem Kunden Feedback zu den neuen Features zu bekommen. Aus Sicht der IT bedeutet das, Änderungen möglichst mit minimalem Aufwand und Risiko umzusetzen. Das Budget soll für den eigentlichen Entwicklungsprozess eingesetzt werden und nicht für den Rollout-Prozess. Der einzige Weg, dies umzusetzen, besteht darin, sämtliche IT-Prozesse zu automatisieren. Das führt dazu, dass Laufzeitumgebungen der Anwendungen immer fein granularer aufgebaut und so Wartungs- und Konfigurationsarbeiten abgegeben werden können.

In den 90er Jahren liefen die Anwendungen noch auf dedizierten Rechnern und man musste die gesamte Hard- und Software selbst warten und konfigurieren. Virtuelle Maschinen, die dann in den 80ern eingesetzt wurden, abstrahierten von der Hardware, sodass die Konfiguration und Wartung dieser wegfielen, lediglich das Betriebssystem musste als Softwarekomponente noch selbst aufgesetzt werden. Die heutige eingesetzte Container-Technik sorgt für Abstraktion von Hard- und Software. Ein und derselbe Container läuft in der Regel auf allen Systemen. Egal ob Windows oder Linux, x64 Intel oder M1 von Mac, solange die zuständige Container-Laufzeitumgebung darauf läuft.

So weit – so gut, aber was sind nun eigentlich „Container“ genau? Ein „Container“ ist eine konkrete Instanz eines Container Images. Ein Container Image ist ein Software-Paket mit allen benötigten Abhängigkeiten (externe Bibliotheken oder Tools), mehr oder weniger isoliert von seiner Umwelt.

Container und IaC – passt perfekt

In Kombination mit Infrastructure as a Code (IaC) nutzen Container ihr Potenzial erst richtig gut aus. IaC ist eine Methode, bei der es darum geht, sämtliche Schritte zum wiederkehrenden Aufsetzen eines IT-Systems als Source Code festzuhalten und es in einem Source Control Management System (SCM) wie Git abzulegen. Source Code umfasst hierbei Shell-Skripte sowie etwaige Konfigurationsdateien für Konfigurationsmanagement-Programme wie Ansible.

Ziel von IaC ist es, den Installations- und Konfigurationsprozess von IT-Systemen immer nachvollziehbar und automatisiert zu gestalten. Für ein lokales System mag das weniger relevant sein, da das Programm innerhalb des Containers für sich genommen autark funktioniert, externe Personen können ihn genauso gut starten wie die Entwicklerinnen und Entwickler selbst. Nutzt man den Container allerdings in der Cloud, sieht man sich plötzlich mit einem riesigen Haufen von Konfigurationsaufwänden konfrontiert, um das System zuverlässig betreiben und skalieren zu können. Um für Ausfallsicherheit zu sorgen, werden Container in der Regel redundant betrieben. Damit man nicht die Übersicht verliert, macht ein Container-Orchestrator wie Kubernetes Sinn. Außerdem kann es – abhängig von dem produzierten Traffic der betriebenen Website – sinnvoll sein, einen Loadbalancer einzusetzen. Weitere Ressourcen wie DNS-Einträge, TLS-Zertifikate, Benachrichtigungen über unerwartete Fehler des Systems und Loggings müssen auch konfiguriert werden. Plötzlich ist das Container Image nur ein kleiner Teil des Gesamtsystems. Ohne die benötigte Infrastruktur kann niemand anderes das System bei sich betreiben. Es wird eine Lösung benötigt, um mein Container Image inklusive der Konfigurationen meiner Infrastruktur abzuspeichern, sodass mein System als Ganzes portiert werden kann. Mit IaC ist das kein Problem mehr, denn Paketmanager wie „Helm“ ermöglichen es, genau dies zu tun. Sie erleichtern den Austausch von containerisierten Anwendungen mit anderen Anwendungen, indem sie das eigentliche Container Image zusammen mit einer Vorlage der benötigten Infrastruktur abspeichern. Mit GitOps wird die aktuelle Infrastruktur (Ist-Konfiguration) fortlaufend mit der im Sourcecode deklarierten Infrastruktur (Soll-Konfiguration) abgeglichen. Dadurch kann das System vor nicht nachvollziehbaren Änderungen geschützt werden. Externe Systeme haben ausschließlich einen lesenden Zugriff (ausschließlich via Pull Requests) auf den im Repository gespeicherten Sourcecode. So können Konfigurationsänderungen ausschließlich von dem zu ändernden System selbst gemacht werden.

Vorteile der Containerisierung im Geschäftsumfeld

Dank der neuen Container-Technologie müssen sich weder Auftragnehmerinnen und -nehmer noch Stackholder um die darunter liegende Hard- oder Software kümmern – das spart Zeit und Kosten, und zwar auf beiden Seiten. Die Softwareentwicklerinnen und -entwickler auf der einen Seite als Auftragnehmende können sich vollständig auf ihre Kerntätigkeit konzentrieren, nämlich die angeforderten Funktionalitäten konzeptionell und programmiertechnisch umzusetzen. Sie können die Software als Container Image beim Entwickeln untereinander verteilen, ohne dass Probleme bezüglich fehlender oder falscher Programmbibliotheken entstehen. Auch das Installieren der Software als fertiges Programm fällt leichter, sofern die Kundin oder der Kunde die gleiche, bereits eingerichtete Containerlaufzeit-Umgebung besitzt. Auf der anderen Seite benötigt die Kundin oder der Kunde als Auftraggeberin oder Auftraggeber kein zusätzliches Fachpersonal mehr, das sich um die Wartung der darunter liegenden Software oder Hardware kümmert. Die Verantwortung kann ganz einfach abgegeben werden. Möglich wird das durch den hohen Grad der Standardisierung der Container-Laufzeitumgebungen.

Wie kann die Containerisierung der Versicherungsbranche helfen?

Die Systeme der Versicherer sind meist monolithischer Natur, sie sind höchst individuell und über viele Jahrzehnte lang gewachsen. Der Kern wurde von einzelnen Fachexpertinnen und -experten entwickelt und in einer Programmiersprache umgesetzt, die mittlerweile ziemlich in die Jahre gekommen ist. Das Problem an der ganzen Sache ist, dass sich monolithische Systeme oft miserabel warten oder erweitern lassen. Oftmals sind derartige Altsysteme schlecht oder gar nicht dokumentiert, sie können meist nur von den ursprünglichen Developern verstanden werden, die aber nicht selten bereits berentet sind. Neues Personal findet sich nur wenig auf dem Markt, da niemand mehr mit solch altertümlichen Programmiersprachen arbeiten möchte.

Die Digitalisierung macht aber auch vor der Versicherungsbranche nicht halt, wird jedoch von deren Altsystemen abgebremst. Microservices, eine Software-Architektur, die eine modulare Softwareentwicklung vorsieht, eignet sich perfekt für die Verwendung der bereits vorgestellten Technologien. Architekturänderungen oder Erweiterungen können durch IaC und GitOps transparenter gestaltet werden und für jeden nachvollziehbar. Definierte API-Schnittstellen ermöglichen ein problemloses Austauschen der einzelnen Container während des Betriebes, ohne dass das Gesamtsystem unkontrolliertes Verhalten an den Tag legt. So kann das Wissen über die Anwendungslandschaft langfristig gebündelt und im Unternehmen gelassen werden, auch bei Ausscheiden der jeweiligen Fachexpertinnen und -experten.

Fazit

Ist dadurch alles einfacher und besser geworden in der IT? Nicht ganz. Das Aufsetzen einzelner Teilkomponenten eines Systems ist zwar leichter geworden, das Gesamtsystem als solches ist jedoch komplexer geworden. Es besteht aus deutlich mehr Einzelkomponenten, die viel häufiger interagieren. Definierte APIs sind da zwar von Vorteil, aber machen wir uns nichts vor: Von allen Beteiligten wird ein deutlich breiteres Spektrum an Wissen über die zu betreibende Anwendungslandschaft gefordert, um einen erfolgreichen Betrieb zu gewährleisten.

Weitere spannende Themen aus der adesso-Welt findet ihr in unseren bisher erschienenen Blog-Beiträgen.