DevOps beschleunigt die Bereitstellung qualitativ hochwertigerer Software, indem die Prozesse zwischen Softwareentwicklung und operationalen IT-Teams kombiniert und automatisiert werden.
DevOps beschreibt – per definitionem – sowohl einen Softwareentwicklungsprozess als auch einen Kulturwandel im Unternehmen, der die Lieferung qualitativ hochwertigerer Software beschleunigt, indem die Prozesse zwischen Teams in der Softwareentwicklung und im IT-Betrieb kombiniert und automatisiert werden – also von zwei Gruppen, die traditionell getrennt voneinander oder in Silos gearbeitet haben.
In der Praxis gehen die besten DevOps-Prozesse und -Kulturen über die Entwicklung und den Betrieb hinaus. Sie beziehen die Beiträge aller an der Anwendung Beteiligten – einschließlich Plattform- und Infrastruktur-Engineering, Sicherheit, Compliance, Governance, Risikomanagement, Geschäftsleitung, Endbenutzer und Kunden – in den Lebenszyklus der Softwareentwicklung mit ein.
DevOps stellt den aktuellen Stand der Evolution der Software-Bereitstellungszyklen in den letzten 20+ Jahren dar: von riesigen anwendungsweiten Code-Releases im Abstand von einigen Monaten oder sogar Jahren zu iterativen kleineren Feature- oder Funktions-Updates, die täglich oder sogar mehrmals täglich veröffentlicht werden.
Letztlich geht es bei DevOps darum, die ständig steigenden Anforderungen der Software-Anwender an häufige, innovative neue Funktionen und ununterbrochene Leistung und Verfügbarkeit zu erfüllen.
Bis kurz vor dem Jahr 2000 wurde der Großteil der Software nach der Wasserfallmethode entwickelt und aktualisiert, d. h. nach einem linearen Ansatz für groß angelegte Entwicklungsprojekte. Teams in der Softwareentwicklung verbrachten normalerweise Monate damit, große Mengen an neuem Code zu entwickeln, der den Großteil oder die gesamte Anwendung betraf. Da die Änderungen so umfangreich waren, verbrachten sie mehrere weitere Monate damit, diesen neuen Code in die Codebasis zu integrieren.
Als nächstes verbrachten die Teams für Qualitätssicherung (QA), Sicherheit und Betrieb weitere Monate damit, den Code zu testen. Dadurch lagen Monate oder sogar Jahre zwischen den einzelnen Software-Releases und oft mussten zwischen den Releases auch mehrere wichtige Patches oder Fehlerbehebungen bereitgestellt werden. Und dieser „Big Bang“-Ansatz, d. h. die Strategie für die „urknallartige“ Bereitstellung von Features, war oft von komplexen und riskanten Implementierungsplänen, von einem schwer zu terminierenden Ineinandergreifen von vorgelagerten und nachgelagerten Systemen, und der „großen Hoffnung“ der IT-Abteilung gekennzeichnet, dass sich die Geschäftsanforderungen in den Monaten vor dem Produktionsstart nicht drastisch geändert hatten.
Um die Entwicklung zu beschleunigen und die Qualität zu verbessern, begannen Entwicklungsteams damit, agile Softwareentwicklungsmethoden einzusetzen, die eher iterativ als linear sind und sich auf kleinere, häufigere Aktualisierungen der Anwendungscodebasis konzentrieren. Die wichtigsten dieser Methoden sind CI/CD, d. h. Continuous Integration (Kontinuierliche Integration) und Continuous Delivery (Kontinuierliche Bereitstellung). Im Rahmen von CI/CD werden kleinere Teile des neuen Codes alle ein bis zwei Wochen in die Codebasis eingebunden und dann automatisch integriert, getestet und für die Bereitstellung in der Produktionsumgebung vorbereitet. Agile Softwareentwicklung entwickelte den „Big Bang“-Ansatz in mehrere „kleinere Vorfälle“, wodurch auch die Risiken aufgeteilt werden.
Je effektiver diese agilen Entwicklungspraktiken die Softwareentwicklung und -bereitstellung beschleunigten, desto mehr entlarvten sie den noch isolierten IT-Betrieb – Systembereitstellung, Konfiguration, Abnahmetests, Management, Überwachung – als nächsten Engpass im Lebenszyklus der Softwarebereitstellung.
DevOps hat also seinen Ursprung in der agilen Softwareentwicklung. Es wurden neue Prozesse und Tools hinzugefügt, die die kontinuierliche Iteration und Automatisierung von CI/CD auf den Rest des Lebenszyklus der Softwarelieferung ausweiteten. Und es wurde die enge Zusammenarbeit zwischen Entwicklungs- und Betriebsteams bei jedem Schritt des Prozesses eingeleitet.
Der DevOps-Lebenszyklus (manchmal auch als „Continuous-Delivery-Pipeline“, also Pipeline für kontinuierliche Bereitstellung bezeichnet, wenn er linear dargestellt wird) ist eine Reihe von iterativen, automatisierten Entwicklungsprozessen oder Workflows, die im Rahmen eines größeren, automatisierten und iterativen Entwicklungszyklus ausgeführt werden, der wiederum die schnelle Bereitstellung von qualitativ hochwertiger Software optimieren soll. Der Name und die Anzahl der Workflows können variieren, je nachdem, wen Sie fragen, aber in der Regel geht es im Wesentlichen um die folgenden sechs Workflows:
Zwischen diesen Workflows laufen drei weitere wichtige kontinuierliche Workflows ab:
Kontinuierliches Testen: Klassische DevOps-Lebenszyklen umfassen eine diskrete „Test“-Phase, die zwischen den Schritten der Integration und der Bereitstellung stattfindet. DevOps ist jedoch nun so weit entwickelt, dass bestimmte Elemente des Testens bereits während der Planung (verhaltensgesteuerte Entwicklung), Entwicklung (Komponententests, Vertragstests), Integration (statische Codescans, CVE-Scans, Linting), Bereitstellung (Rauchtests, Penetrationstests, Konfigurationstests), Operationen (Chaos-Tests, Konformitätsprüfung) und Lernen (A/B-Tests) durchgeführt werden können. Testen ist ein sehr effektives Werkzeug zur Identifizierung von Risiken und Schwachstellen und bietet der IT die Möglichkeit, Risiken entweder zu akzeptieren, zu mindern oder zu beseitigen.
Sicherheit: Während Wasserfallmethoden und agile Implementierungen Sicherheitsabläufe nach der Bereitstellung oder Implementierung „anheften“, ist DevOps bestrebt, Sicherheit von Anfang an (Planung) – wenn Sicherheitsprobleme am einfachsten und am kostengünstigsten zu lösen sind – und kontinuierlich während des gesamten Entwicklungszyklus zu integrieren. Dieses Sicherheitskonzept wird als Linksverschiebung bezeichnet (was leichter zu verstehen ist, wenn Sie sich die Abbildung 1 ansehen). Einige Unternehmen hatten mit diesem Ansatz weniger Erfolg als andere, was zur Entstehung von DevSecOps führte (siehe unten).
Compliance. Regulatorische Compliance (Governance und Risiko) wird idealerweise ebenfalls frühzeitig und während des gesamten Entwicklungslebenszyklus berücksichtigt. Regulierte Branchen sind oft verpflichtet, ein bestimmtes Maß an Beobachtbarkeit, Nachvollziehbarkeit und Zugriff darauf zu gewährleisten, wie Funktionen in ihrer Laufzeitumgebung innerhalb der betrieblichen Abläufe bereitgestellt und verwaltet werden. Dies erfordert Planung, Entwicklung, Testen und Durchsetzung von Richtlinien in der Pipeline für die kontinuierliche Lieferung und in der Laufzeitumgebung. Die Überprüfbarkeit von Compliance-Maßnahmen ist äußerst wichtig, um die Einhaltung von Compliance-Vorschriften gegenüber externen Prüfern beweisen zu können.
Es ist allgemein anerkannt, dass DevOps-Methoden nicht ohne ein Bekenntnis zur DevOps-Kultur funktionieren können, die sich als ein völlig anderer organisatorischer und technischer Ansatz zur Softwareentwicklung zusammenfassen lässt.
Auf organisatorischer Ebene erfordert DevOps eine kontinuierliche Kommunikation, Zusammenarbeit und gemeinsame Verantwortung aller an der Softwarebereitstellung Beteiligten, d. h. der Softwareentwicklungs- und IT-Betriebsteams, aber auch der Sicherheits-, Compliance-, Governance-, Risiko- und Geschäftsleitungsteams, um schnelle und kontinuierliche Innovationen zu erzielen und die Qualität der Software von Anfang an zu gewährleisten.
In den meisten Fällen lässt sich dies am besten erreichen, indem man diese Silos aufbricht und sie in funktionsübergreifende, autonome DevOps-Teams umorganisiert, die von Anfang bis Ende – von der Planung bis zum Feedback – an Code-Projekten arbeiten können, ohne Übergaben an andere Teams vorzunehmen oder auf deren Genehmigungen warten zu müssen. Im Kontext der agilen Entwicklung sind die gemeinsame Verantwortlichkeit und die Zusammenarbeit die Grundlage für einen gemeinsamen Produktfokus, der zu einem wertvollen Ergebnis führt.
Auf technischer Ebene erfordert DevOps ein Engagement für die Automatisierung, die Projekte innerhalb und zwischen Workflows in Bewegung hält. Außerdem sind Feedback und Messungen erforderlich, die es den Teams ermöglichen, die Zyklen kontinuierlich zu beschleunigen und die Softwarequalität und -leistung zu verbessern.
Die Anforderungen von DevOps und der DevOps-Kultur erfordern den Einsatz von Werkzeugen, die asynchrone Zusammenarbeit unterstützen, DevOps-Workflows nahtlos integrieren und den gesamten DevOps-Lebenszyklus so weit wie möglich automatisieren. Zu den Kategorien von DevOps-Tools gehören:
Cloudnativ ist ein Ansatz für die Erstellung von Anwendungen, die grundlegende Cloud-Computing-Technologien nutzen. Das Ziel bei der cloudnativen Vorgehensweise ist es, eine konsistente und optimale Anwendungsentwicklung, -bereitstellung, -verwaltung und -leistung in öffentlichen, privaten und Multicloud-Umgebungen zu ermöglichen.
Heute werden cloudnative Anwendungen in der Regel:
In vielerlei Hinsicht sind cloudnative Entwicklung und DevOps wie füreinander geschaffen.
Beispielsweise eignet sich die Entwicklung und Aktualisierung von Microservices – d. h. die iterative Bereitstellung kleiner Codeeinheiten an eine kleine Codebasis – perfekt für die schnellen Release- und Verwaltungszyklen von DevOps. Und es wäre schwierig, die Komplexität einer Microservices-Architektur ohne DevOps-Bereitstellung und -Betrieb zu bewältigen. Eine kürzlich von IBM durchgeführte Umfrage unter Entwicklern und IT-Führungskräften ergab, dass 78 % der aktuellen Microservices-Benutzer erwarten, den Zeit-, Geld- und Arbeitsaufwand, den sie in die Architektur investiert haben, zu erhöhen. 56 % der Nichtbenutzer werden wahrscheinlich innerhalb der nächsten zwei Jahre Microservices einführen.
Durch die Paketierung und dauerhafte Festlegung aller Betriebssystemabhängigkeiten ermöglichen Container schnelle CI/CD- und Bereitstellungszyklen, da die gesamte Integration, das Testen und die Bereitstellung in der gleichen Umgebung stattfinden. Und die Kubernetes-Orchestrierung führt die gleichen kontinuierlichen Konfigurationsaufgaben für containerisierte Anwendungen aus, wie sie Ansible, Puppet und Chef für nicht containerisierte Anwendungen ausführen.
Die meisten führenden Cloud-Computing-Anbieter – darunter AWS, Google, Microsoft Azure und IBM Cloud – bieten eine Art verwaltete DevOps-Pipeline-Lösung an.
DevSecOps ist DevOps, das die Sicherheit während des gesamten DevOps-Lebenszyklus kontinuierlich integriert und automatisiert – von Anfang bis Ende, von der Planung bis zum Feedback und wieder zurück zur Planung.
Man kann es auch so ausdrücken: DevSecOps ist das, was DevOps von Anfang hätte sein sollen. Zwei der ersten großen (und eine Zeit lang unüberwindbaren) Herausforderungen bei der Einführung von DevOps waren jedoch die Integration von Sicherheitsexpertise in funktionsübergreifende Teams (ein kulturelles Problem) und die Implementierung von Sicherheitsautomatisierung in den DevOps-Lebenszyklus (ein technisches Problem). Sicherheit wurde als das „Team der Neinsager“ und als teurer Engpass in vielen DevOps-Verfahren wahrgenommen.
DevSecOps entstand daher als ein gezielter Versuch, Sicherheit zu integrieren und zu automatisieren, so wie es ursprünglich beabsichtigt war. In DevSecOps ist die Sicherheit ein „Bürger erster Klasse“ und ein Stakeholder auf gleicher Stufe wie Entwicklung und Betrieb und bringt das Element Sicherheit mit einem Produktfokus in den Entwicklungsprozess ein.
Sehen Sie sich „Was ist DevSecOps?“ an, um mehr über DevSecOps-Grundsätze, Vorzüge und Anwendungsfälle zu erfahren:
Beim Site Reliability Engineering (SRE) werden Softwaretechniken eingesetzt, um Aufgaben des IT-Betriebs zu automatisieren – z. B. die Verwaltung von Produktionssystemen, das Änderungsmanagement, die Reaktion auf Vorfälle und sogar die Reaktion auf Notfälle – die ansonsten von Systemadministratoren manuell durchgeführt würden. SRE zielt darauf ab, den klassischen Systemadministrator zu einem Ingenieur zu machen.
Das ultimative Ziel von SRE ähnelt dem von DevOps, ist aber spezifischer: SRE soll den Wunsch eines Unternehmens nach schneller Anwendungsentwicklung mit der Notwendigkeit in Einklang bringen, die in Service Level Agreements (SLAs) mit Kunden und Endbenutzern festgelegten Leistungs- und Verfügbarkeitsniveaus zu erfüllen.
Ingenieure für Standortzuverlässigkeit erreichen dieses Gleichgewicht, indem sie ein akzeptables Niveau des durch Anwendungen verursachten Betriebsrisikos – genannt „Fehlerbudget“ – festlegen und die Abläufe so automatisieren, dass dieses Niveau eingehalten wird.
In einem funktionsübergreifenden DevOps-Team kann SRE als Brücke zwischen Entwicklung und Betrieb dienen, indem es die Metriken und die Automatisierung zur Verfügung stellt, die das Team benötigt, um Code-Änderungen und neue Features so schnell wie möglich durch die DevOps-Pipeline zu pushen, ohne aber die Bedingungen der SLAs des Unternehmens zu „verletzen“.
Erkunden Sie das umfassende Portfolio an Integrations-, KI- und Automatisierungsfunktionen, mit denen Sie den gewünschten ROI erzielen können.
Erfahren Sie, wie Sie mit IBM® Cloud Pak for Watson AIOps einen proaktiven IT-Betrieb erreichen können.
Leistungsstarke DevOps-Software zum Erstellen, Bereitstellen und Betrieb von sicherheitsrelevanten, cloudnativen Anwendungen für mehrere Geräte, Umgebungen und Clouds.