Technologie erklärt: DevOps-Fachjargon für Business-Entscheider

Talk Business to me: Wenn DevOps-Profis Geschäftsentscheidern CI/CD, Kubernetes oder AIOps erklären müssen, helfen diese Kommunikationsstrategien weiter.


Foto: GaudiLab – shutterstock.com

Jede (IT)-Disziplin hat ihren eigenen Jargon. Meist ist dieser all jenen, die nicht mit den Tools, Workflows und allgemeinen Problemstellungen zu tun haben, schwer zu vermitteln ist. Software-Ingenieure tun sich selbst einen Gefallen, wenn sie eine leicht zu erklärende Nomenklatur verwenden, über deren Definition Einigkeit besteht. In Wahrheit ist ja auch gar nicht so schwierig, die Grundlagen von agilen Methoden, Data Warehouses oder Firewalls zu erklären. Teilweise sind die Namen schon in gewisser Weise selbsterklärend, auch wenn sich Experten – wie so oft – über die exakte technische Definition uneinig sind.

Irgendwann werden Sie als Entwickler mit einer Situation konfrontiert, dass eine Führungskraft Sie bittet, ein Buzzword oder einen Fachbegriff zu erklären. Sie sollten den betreffenden Terminus dann in einfachen Worten erklären können, technische Details außen vor lassen und weiteren Fachjargon vermeiden, der lediglich neue Fragen und Definitionen nach sich zieht.

Ich habe mehrere Experten dazu befragt, wie sie die wichtigsten Begriffe im DevOps-Umfeld in einfacher Sprache erklären würden.

Dan Knox, Vice President of Engineering beim Softwareanbieter G2, liefert eine wasserdichte Definition zum Akronym für Continuous Integration und Continuous Delivery, ohne dabei zu technisch zu werden: “CI/CD ist eine Taktik, um Code kontinuierlich testen und bereitstellen zu können, um so das Risiko von Problemen beim Bereitstellen funktionaler Software zu verringern. Das ist praktisch für solche Teams, die besonders schnell sein und vor der Konkurrenz auf dem Markt sein will.”

Nehmen wir an, Sie werden gebeten, mehr Details zu nennen. In diesem Fall schlägt Sashank Purighalla, CEO beim No-Code-Anbieter BOS Frameworks, folgende Antwort vor: “CI/CD hilft mit bestimmten Nischen-Tools dabei, eine Automatisierungs-Pipeline in verschiedenen Phasen des Software-Lebenszyklus' aufzubauen, um manuelle Arbeit zu reduzieren und Hindernisse zu beseitigen.”

Wenn Ihre Führungskraft gar nichts über Softwareentwicklung weiß, sollten Sie auf Worte wie “Pipeline” allerdings lieber verzichten und “Lebenszyklus” durch “Entwicklung” ersetzen. In der heutigen Zeit, in der Technologie für Unternehmen essenzieller Erfolgsfaktor ist, sollten Führungskräfte allerdings zumindest über die Grundlagen des Entwicklungsprozesses Bescheid wissen. Wenn Sie ihre Sprache vereinfachen, laden Sie ihre Gesprächspartner dazu ein, mehr zu lernen und vermeiden, dass sich Ihr Gegenüber eingeschüchtert fühlt.

Auch Andrew Davis, Senior Director of Research and Innovation beim DevOps-Anbieter Copado, liefert eine gute Definition: “CI/CD ist die Abkürzung für Continuous Integration und Continuous Delivery, zwei eng miteinander verbundene Praktiken, die den Goldstandard für die Zusammenarbeit von Softwareentwicklungsteams darstellen. Continuous Delivery ermöglicht schnelles und sicheres Lernen und Feedback, indem die Lücke zwischen Softwareentwicklern und Endbenutzern geschlossen wird.
Continuous Integration ist die Praxis, die Arbeit aller Entwickler mindestens täglich zusammenzuführen und automatisierte Tests zu verwenden, um Fehler schnell zu erkennen. Continuous Delivery bedeutet, dass diese Änderungen den Endbenutzern zur Verfügung gestellt werden, sobald sie fertig sind. So erhalten die Entwickler dazu schnell von echten Benutzern Feedback.”

Die Idee vom Canary Release basiert auf dem Prinzip des Kanarienvogels im Kohlebergwerk – einst ein archaisches Frühwarnsystem, um den Austritt gefährlicher Gase rechtzeitig zu erkennen.

Geht es darum, einem Business-Entscheider das Prinzip zu vermitteln, empfiehlt, Marko Anastasov, Mitbegründer von Semaphore CI/CD, einen risikobasierten Ansatz: “Tests reichen nicht aus, um alle Probleme aufzudecken. Einige tauchen erst in der Produktion auf – dann ist der Schaden aber bereits angerichtet. Canary Deployments ermöglichen uns, das Fahrwasser zu überprüfen, bevor es richtig losgeht.”

Purighalla hat zusätzlich eine Erklärung dazu parat, wie Canary Releases funktionieren: “Ein Canary Release wird verwendet, um neue Features und Funktionen für eine Untergruppe von Benutzern auf kontrollierte Weise einzuführen, bevor sie auf die gesamte Produktionsinfrastruktur und Benutzerbasis ausgerollt werden.”

Sollte das nicht ausreichen, liefert Michael Erpenbeck, Director of DevOps bei G2, zusätzlichen Kontext: “Ein Canary Release ist eine leistungsstarke Methode, um neuen Code einer wachsenden Benutzergruppe zugänglich zu machen – ohne die Risiken, die mit einem Big-Bang-Deployment verbunden sind.”

Big-Bang-Deployments waren bereits in vielen Fällen für Ausfälle, Performance-Probleme oder Defekte verantwortlich – der Begriff bildet an dieser Stelle deshalb einen willkommenen Kontrast zu Canary Releases (und anderen DevOps-Methoden, die die Deployment-Zuverlässigkeit erhöhen).

Docker und Kubernetes zu erklären, wenn kein Grundlagenwissen zu Containern, Microservices-Architekturen und Cloud-nativen Infrastrukturmustern vorhanden ist, ist eine Herausforderung. Es bietet sich deshalb an, auf eine einfache Analogie auszuweichen – wie etwa Entrepreneur Blake Davis:

Kendall Miller, Tech-Evangelist bei Fairwinds, wählt eine andere Metapher:

Wenn Ihr Gegenüber technisches Wissen mitbringt, schlägt Anastasov folgende Antwort vor: “Diese neue Generation von Tools hat die Erstellung von Cloud-nativer Software demokratisiert. Docker-Container sind jetzt die Standardmethode, um Software so zu verpacken, dass sie in jeder Cloud bereitgestellt, skaliert und dynamisch verteilt werden kann. Und Kubernetes ist die führende Plattform für den Einsatz von Containern in der Produktion.”

Wenn Ihr CFO oder ein anderer Finance-Mitarbeiter sich nach Fehlerbudgets erkundigt, müssen sie vermitteln, wie das mit der Definition von Service-Level-Zielen und dem Betrieb zuverlässiger, leistungsfähiger Systeme zusammenhängt.

In einem Blogbeitrag liefert Alex Nauda, CTO beim Plattformanbieter Nobl9, eine Definition zum Begriff: “Fehlerbudgets können als ein konzeptionelles Modell für das Verständnis des akzeptablen Risikos in Ihren Services betrachtet werden. Wenn Sie Ihr Error Budget gesprengt haben, sollten Sie sich darauf konzentrieren die Zuverlässigkeit zu verbessern.”

Wenn Sie ein Site Reliability Engineer sind, ist es von entscheidender Bedeutung, über Service-Level-Ziele und Fehlerbudgets aufzuklären – insbesondere gegenüber anspruchsvollen Führungskräften, die auf mehr Funktionen drängen, ohne dabei technische Schulden oder betriebliche Anforderungen zu berücksichtigen.

Angesichts der Vielzahl Ops-bezogener Fachausdrücke (DevOps, DevSecOps, DataOps, MLOps, ModelOps, BizOps, CloudOps, GitOps – um nur einige zu nennen) können Verwirrung stiften – oder schlimmer noch Frustration hervorrufen.

Ich nenne hier spezifisch AIOps, weil es ein gutes Beispiel dafür ist, wie unterschiedliche Definitionen eines Begriffs zu katastrophal falschen Erwartungen führen können. AIOps bedeutet nicht, dass künstliche Intelligenz den IT-Betrieb übernimmt oder Unternehmen mit einer schlecht implementierten Anwendung eine dramatisch verbesserte Leistung erzielen können. Der Hype um künstliche Intelligenz ist so groß, dass es sich empfiehlt, für realistische Erwartungen zu sorgen. KI kann den Multi-Cloud-Betrieb vereinfachen, die durchschnittliche Zeit bis zur Behebung größerer Zwischenfälle verkürzen oder die Anwendungsüberwachung verbessern. Das sind nur einige der technischen Vorteile.

Assaf Resnick, CEO von BigPanda, würde AIOps einem CEO oder CFO folgendermaßen erklären: “Als Unternehmen auf die Cloud umstellten, führte das zu einer um mehrere Größenordnungen höheren Skalierung, Datenmenge und Geschwindigkeit. Die IT-Betriebsteams hatten deshalb Mühe, Schritt zu halten. AIOps automatisiert und befähigt den IT-Betrieb, seine Arbeit zu erledigen und das Geschäft und die digitalen Dienste in der modernen Cloud-Ära am Laufen zu halten.”

Diese Definition macht deutlich, dass AIOps Unternehmen dabei unterstützt, die Auswirkungen von Betriebsstörungen einzuschränken, die Zuverlässigkeit zu verbessern und zu wachsen.

CI/CD, Canary Releases, Docker, Kubernetes und AIOps sind nur die Spitze des Fachjargon-Eisbergs – bilden aber einen guten Ausgangspunkt, um die Best Practices im Bereich DevOps für Business-Entscheider zu entmystifizieren. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.