DevOps als Philosophie und organisatorische Herausforderung

Eine DevOps-Philosophie bedingt organisatorische und kulturelle Anpassungen. Nicht jeder Entwickler ist auf die Installation und den Betrieb von Software spezialisiert, nicht jeder System-Engineer kennt sich mit Software-Entwicklung aus und eine Partei ist vielleicht nicht bereit, sich mit der anderen auseinanderzusetzen. DevOps – und der eigentlich einfache Gedanke dahinter – stellen Unternehmen somit vor grosse Herausforderungen. DevOps ist schwieriger in einer bestehenden Organisation zu implementieren, als es den Anschein macht! Gelingt es einem Unternehmen aber, Entwicklung und Betrieb an einen Tisch zu setzen, wird es Software und Services mit erhöhter Geschwindigkeit und in besserer Qualität ausliefern und betreiben können.

Was aber, wenn ein Unternehmen von den Vorzügen der DevOps-Philosophie profitieren möchte, selbst aber keine Software entwickelt und vielleicht auch nicht selber für deren Betrieb zuständig ist? Und was, wenn diese Unternehmen durch Regulatorien auf stark gehärtete IT-Umgebungen und Prozesse angewiesen sind, wie es zum Beispiel bei Finanz- und Versicherungsdienstleistern der Fall ist?

In diesem Fall ist es hilfreich, die DevOps-Philosophie, die entsprechenden Werkzeuge und Architekturen einzeln zu betrachten und darin passende Schnittstellen zwischen Entwicklungs- und Betriebspartnern zu identifizieren. Das Ziel bleibt dabei dasselbe, nämlich Entwicklung und Betrieb von Software oder Services näher aneinander zu bringen. Dabei sind alle Parteien gemeinsam für den Erfolg eines Produkts verantwortlich – dennoch muss jederzeit klar sein, wo die jeweiligen Verantwortlichkeiten beginnen und enden.
Inventx als innovativer IT-Partner für führende Finanz- und Versicherungsdienstleister hat sich in den letzten Jahren intensiv mit diesen Themen auseinandergesetzt und entsprechende Frameworks, Plattformen und Services entwickelt, um Kunden die Vorteile von DevOps und Werkzeugen wie CI/CD-Pipelines, Microservices, Container und Container-Plattformen anzubieten. Die Services sind auf die jeweiligen Bedürfnisse und Anforderungen der einzelnen Parteien ausgerichtet und berücksichtigen dabei die regulatorischen Anforderungen an gehärtete IT-Umgebungen.

In der Blogserie zum Thema DevOps in gehärteten Umgebungen gehen wir in drei aufeianderfolgenden Artikeln auf spezifische Aspekte ein:

  1. DevOps macht eine neue Aufgabenverteilung zwischen Entwickler und Betriebspartner erforderlich. Wir erklären, warum und wie diese im Idealfall aussieht (nachfolgend).
  2. Welche Sicherheitsanforderungen sind in diesem Umfeld und mit dem DevOps-Ansatz zu beachten?
  3. Sicherheitslücken in Software, die in einem Container liegt, müssen anders angegangen werden als bei Software auf einem Server. Der letzte Beitrag der DevOps-Serie widmet sich dem Thema Software-Aktualisierungen und Prozesse.

Wenn Entwicklung und Betrieb verschmelzen

Die Services von Inventx erlauben es, externen wie auch internen Software-Lieferanten, sich auf ihre Kernaufgabe zu konzentrieren – Software-Entwicklung.
Der Einsatz der Docker-Container-Technologie bietet eine klar definierte Grenze zwischen Entwicklung und Betrieb: Die Entwickler kümmern sich darum, was innerhalb des Docker-Containers passiert, der Betrieb konzentriert sich darauf, was mit dem Docker-Container geschieht. Docker-Container eignen sich auch hervorragend, um grössere Software-Projekte in kleinere Teilprojekte zu unterteilen und einzelne Funktionen einer Gesamtlösung in Microservices aufzuteilen. Eine Isolierung der Microservices bei Sicherheitsproblemen ist dadurch bereits gegeben.

Der Software-Lieferant ist für die Entwicklung und Wartung der Software und den Bau der Docker Images zuständig und liefert sie in die Public Docker Registry der Inventx ein. Dafür können Continuous-Integration- und Continuous-Delivery-(CI/CD) Werkzeuge wie GitLab, GitLab Runner, Jenkins etc. eingesetzt werden.
Die Public Docker Registry wird durch Inventx in einer Public Cloud betrieben und dient als Quarantäne, in der die Docker Images regelmässig auf Sicherheitslücken in den Softwarepaketen untersucht werden.

Neben der Lieferung von Docker Images unterstützt der Software-Entwickler während einer Onboarding-Phase Inventx als Betriebspartner auch bei der Konfiguration der Continuous Deployment Pipeline, da nur der Entwickler über spezifisches Wissen der Applikation, wie benötigte Umgebungsvariablen oder TCP Ports, verfügt. Die Continuous Deployment Pipeline wird mit ähnlichen Werkzeugen umgesetzt, wie die CI/CD-Pipeline. Wichtig ist es, auf Werkzeuge zu setzen, die eine API für die vollständige Automatisierung bieten. Die Continuous Deployment Pipeline synchronisiert als erstes das Docker Image in der Public Registry (Quarantäne) mit der Private Registry in den Inventx-Rechenzentren. Anschliessend wird das neue Docker Image als Container, beziehungsweise Pod, auf einer Kubernetes-Container-Plattform gestartet. Neben dem eigentlichen Pod werden automatisch auch Storage, Monitoring-Endpunkte und Ingress-Regeln für die korrekte Weiterleitung von eingehenden Netzwerkverbindungen auf den Pod und die darin laufende Software konfiguriert. Weitere wichtige Ressourcen wie Kubernetes Network Policies und Kubernetes Pod Security Policies werden ebenfalls automatisch installiert. Verfügt die Applikation über einen Kubernetes Operator, in dem das Wissen von System-Engineers in Form von Code implementiert ist, kann auch der komplette Lebenszyklus einer Applikation weiter automatisiert und standardisiert werden.