Über den Einsatz von Cookies auf dieser Website Unsere Websites benötigen einige Cookies, um ordnungsgemäß zu funktionieren (erforderlich). Darüber hinaus können mit Ihrer Zustimmung weitere Cookies verwendet werden, um die Nutzung der Website zu analysieren, die Benutzerfreundlichkeit zu verbessern und Werbung zu schalten. Weitere Informationen finden Sie in Ihren. Durch den Besuch unserer Website erklären Sie sich mit der Verarbeitung von Informationen einverstanden, wie in der IBMDatenschutzbestimmung beschrieben. Um eine reibungslose Navigation zu ermöglichen, werden Ihre Cookie-Präferenzen über die hier aufgeführten IBM Web-Domains hinweg gemeinsam genutzt.
Was ist DevOps?
DevOps ist eine Softwareentwicklungsmethodik, die die Bereitstellung qualitativ hochwertigerer Anwendungen und Dienste beschleunigt, indem sie die Arbeit von Softwareentwicklungs- und IT-Betriebsteams kombiniert und automatisiert.
Durch gemeinsame Tools und Verfahren, einschließlich kleiner, aber häufiger Updates, wird die Softwareentwicklung effizienter, schneller und zuverlässiger.
Per Definition beschreibt DevOps, Development Operations, sowohl einen Softwareentwicklungsprozess als auch einen Wandel in der Unternehmenskultur, der die Koordination und Zusammenarbeit zwischen den Entwicklungs- und IT Operations-Teams fördert, zwei Gruppen, die traditionell getrennt voneinander oder in Silos arbeiteten.
In der Praxis gehen die besten DevOps-Prozesse und -Kulturen über die Entwicklungspraktiken und den Betrieb hinaus und beziehen die Beiträge aller an der Anwendung Beteiligten in den Lebenszyklus der Softwareentwicklung ein. Dazu gehören Plattform- und Infrastruktur-Ingenieure, Sicherheits-, Compliance-, Governance- und Risikomanagement-Teams sowie die Geschäftsleitung, Benutzer und Kunden.
Die DevOps-Prinzipien stellen den aktuellen Stand der Entwicklung des Softwarebereitstellungsprozesses in den letzten 20 Jahren dar. Der Bereitstellungsprozess hat sich von riesigen anwendungsweiten Code-Releases, die alle paar Monate oder sogar Jahre erscheinen, zu iterativen kleineren Feature- oder Funktions-Updates entwickelt, die täglich oder mehrmals täglich veröffentlicht werden.
Letztendlich geht es bei DevOps darum, die ständig steigenden Anforderungen der Softwareanwender an häufige, innovative neue Funktionen und ununterbrochene Leistung und Verfügbarkeit zu erfüllen.
Vor dem Jahr 2000 wurde die meiste Software nach der Wasserfallmethode entwickelt und aktualisiert, einem linearen Ansatz für große Entwicklungsprojekte. Software-Entwicklungsteams verbrachten Monate mit der Entwicklung umfangreicher neuer Codes, die einen Großteil oder den gesamten Lebenszyklus der Anwendung beeinflussten. Da die Änderungen so umfangreich waren, verbrachten sie noch mehrere Monate damit, den neuen Code in die Codebasis zu integrieren.
Als nächstes testeten die Qualitätssicherung (QA), Sicherheits- und Betriebsteams den Code noch weitere Monate. Das Ergebnis waren Monate oder sogar Jahre zwischen den einzelnen Softwareversionen und oft auch mehrere wichtige Patches oder Fehlerbehebungen zwischen den einzelnen Versionen. Dieser „Big Bang“-Ansatz für die Bereitstellung von Funktionen war oft durch komplexe und riskante Bereitstellungspläne, schwer zu terminierende Interlocks mit vor- und nachgelagerten Systemen und die große Hoffnung der IT-Abteilung gekennzeichnet, dass sich die geschäftlichen Anforderungen in den Monaten vor dem Produktionsstart oder der allgemeinen Verfügbarkeit (GA) nicht drastisch geändert hatten.
Um die Entwicklung zu beschleunigen und die Qualität zu verbessern, begannen Entwicklungsteams in den frühen 2000er Jahren mit der Einführung von Methoden zur agilen Softwareentwicklung. Diese Methoden sind eher iterativ als linear und konzentrieren sich auf kleinere, häufigere Aktualisierungen der Anwendungscodebasis. Die meisten dieser DevOps-Methoden sind kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD).
In CI/CD werden in regelmäßigen Abständen kleinere Teile des neuen Codes in der Codebasis zusammengeführt und anschließend automatisch in die Produktionsumgebung integriert, getestet und vorbereitet. Agile modifizierte den Big-Bang-Ansatz in eine Reihe kleinerer Snaps, die auch die Risiken aufteilten.
Je effektiver diese agilen Entwicklungspraktiken die Softwareentwicklung und -bereitstellung beschleunigten, desto mehr machten sie beispielsweise den immer noch isolierten IT-Betrieb, die Systembereitstellung, Konfiguration, Abnahmetests, Verwaltung und Überwachung als den nächsten Engpass im Lebenszyklus der Softwarebereitstellung sichtbar.
DevOps hat sich also aus Agile entwickelt. Es wurden neue Prozesse und Tools hinzugefügt, die die kontinuierliche Iteration und Automatisierung von CI/CD auf den Rest des Lebenszyklus der Softwarebereitstellung ausdehnen. Und es wurde eine enge Zusammenarbeit zwischen Entwicklung und Betrieb bei jedem Schritt des Prozesses eingeführt.
Der DevOps-Lebenszyklus (auch als Continuous Delivery Pipeline bezeichnet, wenn er linear dargestellt wird) ist eine Reihe von iterativen, automatisierten Entwicklungsprozessen oder Workflows, die innerhalb eines größeren, automatisierten und iterativen Entwicklungslebenszyklus ablaufen, um die schnelle Bereitstellung von hochwertiger Software zu optimieren. Workflow-Namen und die Anzahl der Workflows unterscheiden sich je nachdem, wen Sie fragen, aber sie enthalten oft diese acht Schritte.
Planung
In diesem Arbeitsablauf überlegen sich die Teams neue Funktionen für die nächste Version. Dabei stützen sie sich auf priorisiertes Benutzerfeedback und Fallstudien sowie auf Beiträge aller internen Stakeholders. Das Ziel der Planungsphase ist es, den Geschäftswert des Produkts zu maximieren, indem ein Backlog mit Funktionen erstellt wird, die den Produktwert erhöhen.
Codierung
Dies ist der Programmierschritt, bei dem die Entwickler neue und verbesserte Funktionen auf der Grundlage der User Stories und Work Items im Backlog programmieren und erstellen. Eine Kombination von Praktiken wie testgetriebene Entwicklung (TDD), Pair Programming und Peer Code Reviews sind weit verbreitet. Entwickler verwenden oft ihre lokalen Workstations, um den inneren Kreislauf des Schreibens und Testens von Code auszuführen, bevor sie ihn durch die Continuous Delivery Pipeline senden.
Aufbau kontinuierlicher Integration und kontinuierliche Bereitstellung
In diesem Workflow wird der neue Code in die bestehende Codebasis integriert, dann getestet und für die Veröffentlichung und Bereitstellung verpackt. Zu den üblichen Automatisierungsaktivitäten gehören das Zusammenführen von Codeänderungen in eine Masterkopie, das Prüfen dieses Codes aus einem Quellcode-Repository und die Automatisierung der Kompilierung, des Unit-Tests und der Verpackung in eine ausführbare Datei. Die bewährte Vorgehensweise besteht darin, die Ausgabe der CI-Phase für die nächste Phase in einem Binär-Repository zu speichern.
Testen
Teams verwenden Tests, häufig automatisierte Tests, um sicherzustellen, dass die Anwendung den Standards und Anforderungen entspricht. Der klassische DevOps-Ansatz beinhaltet eine diskrete Testphase, die zwischen Build und Release stattfindet.
DevOps ist jedoch so weit fortgeschritten, dass bestimmte Testelemente bei der Planung (verhaltensgesteuerte Entwicklung), der Entwicklung (Unit-Tests, Contract-Tests), der Integration (statische Code-Scans, CVE-Scans, Linting), der Bereitstellung (Smoke-Tests, Penetrationsprüfungen, Konfigurationstests), dem Betrieb (Chaos-Tests, Compliance-Tests) und beim Lernen (A/B-Tests) auftreten können.
Kontinuierliche Tests sind eine wirkungsvolle Form der Identifizierung von Risiken und Schwachstellen und bieten der IT-Abteilung die Möglichkeit, Risiken zu akzeptieren, zu mindern oder zu beseitigen. Darüber hinaus ist das Shift-Links-Testen ein Ansatz in der Softwareentwicklung, bei dem die Testaktivitäten früher in den Entwicklungsprozess verlegt werden. Dieser Ansatz sorgt für eine bessere Produktqualität, eine bessere Testabdeckung, kontinuierliche Feedbackschleifen und eine schnellere Markteinführung.
Release
Die Freigabestufe ist die letzte Phase vor dem Zugriff der Benutzer auf die Anwendung. In diesem Workflow wird die Runtime-Build-Ausgabe (aus der Integration) in einer Laufzeitumgebung bereitgestellt, in der Regel eine Entwicklungsumgebung, in der Laufzeittests für Qualität, Konformität und Sicherheit durchgeführt werden.
Wenn Fehler oder Defekte gefunden werden, haben die Entwickler die Chance, die Probleme abzufangen und zu beheben, bevor die Benutzer sie sehen. In der Regel gibt es Umgebungen für die Entwicklung, für Tests und für die Produktion, wobei für jede Umgebung zunehmend strengere Qualitätskriterien gelten. Wenn die Entwickler alle identifizierten Probleme behoben haben und die Anwendung alle Anforderungen erfüllt, bestätigt das Betriebsteam, dass sie einsatzbereit ist und integriert sie in die Produktionsumgebung.
Bereitstellen
Die Bereitstellung ist der Zeitpunkt, an dem das Projekt in eine Produktionsumgebung überführt wird, in der die Benutzer auf die Änderungen an der Anwendung zugreifen können. Die Infrastruktur wird eingerichtet und konfiguriert (oft unter Verwendung von Infrastruktur als Code) und der Anwendungscode wird bereitgestellt. Eine bewährte Methode für die Bereitstellung in einer Produktionsumgebung ist es, zunächst eine Untergruppe von Endbenutzern und dann schließlich alle Benutzer einzubeziehen, sobald die Stabilität hergestellt ist.
Betreiben
Wenn die Bereitstellung von Funktionen in einer Produktionsumgebung als „Tag 1“ bezeichnet wird, dann beginnen die Operationen von „Tag 2“, sobald die Funktionen in der Produktion laufen. Durch die Überwachung der Leistung, des Verhaltens und der Verfügbarkeit von Funktionen können Sie sicherstellen, dass die Funktionen für die Benutzer einen Mehrwert bieten.
In dieser Phase überprüfen die Teams, ob die Funktionen reibungslos funktionieren und ob es keine Serviceunterbrechungen gibt. Sie stellen sicher, dass das Netzwerk, der Speicher, die Plattform, die Rechenleistung und die Sicherheitsvorkehrungen in Ordnung sind. Wenn Probleme auftreten, identifizieren die Betriebsteams den Vorfall, benachrichtigen die zuständigen Mitarbeiter, beheben die Probleme und wenden Korrekturen an.
Überwachen
Dabei handelt es sich um das Sammeln von Rückmeldungen von Benutzern und Kunden zu Features, Funktionen, Leistung und Geschäftswert, die in die Planung von Verbesserungen und Features für die nächste Version einfließen. Dazu gehören auch alle Lern- und Backlog-Elemente aus den Operations-Aktivitäten, die Entwicklern helfen können, bekannte Vorfälle proaktiv zu verhindern. Dies ist der Punkt, an dem der „Wraparound“ zur Planungsphase erfolgt, der die kontinuierliche Verbesserung vorantreibt.
Es gibt zwei weitere wichtige kontinuierliche Workflows im Lebenszyklus:
Während Wasserfall-Methoden und agile Implementierungen Sicherheitsabläufe nach der Auslieferung oder Bereitstellung „anheften“, ist DevOps bestrebt, die Sicherheit von Anfang an (Planung) einzubeziehen, wenn Sicherheitsprobleme am einfachsten und am kostengünstigsten zu lösen sind, und während des gesamten restlichen Entwicklungszyklus kontinuierlich zu betreiben. Dieser Sicherheitsansatz wird als „Shifting Left“ bezeichnet. Einige Unternehmen hatten weniger Erfolg als andere, was zum Anstieg von DevSecOps (Entwicklung, Sicherheit und Betrieb) führte.
Es ist außerdem am besten, die regulatorische Governance, Risk and Compliance (GRC) frühzeitig sowie während des gesamten Entwicklungslebenszyklus anzugehen. Regulierte Branchen sind oft verpflichtet, ein bestimmtes Maß an Observability, Rückverfolgbarkeit und Zugriff auf die Bereitstellung und Verwaltung von Features in ihrer Betriebsumgebung zu gewährleisten.
Dies erfordert die Planung, die Entwicklung, das Testen und die Durchsetzung von Richtlinien in der Kontinuierlichen Bereitstellung-Pipeline und der Laufzeitumgebung. Die Überprüfbarkeit von Compliance-Maßnahmen ist wichtig, um die Einhaltung durch externe Prüfer nachzuweisen.
Unternehmensleiter sind sich im Allgemeinen einig, dass DevOps-Methoden ohne eine DevOps-Kultur, d. h. einen anderen organisatorischen und technischen Ansatz für die Softwareentwicklung, nicht funktionieren.
Auf organisatorischer Ebene erfordert DevOps eine kontinuierliche Kommunikation, Zusammenarbeit und gemeinsame Verantwortung aller an der Softwarebereitstellung Beteiligten. Dazu gehören natürlich Softwareentwicklungs- und IT-Betriebsteams, aber auch Sicherheits-, Compliance-, Governance-, Risiko- und Line-of-Business-Teams, um schnell und kontinuierlich innovativ zu sein und von Anfang an auf Qualität zu setzen.
Normalerweise lässt sich dies am besten erreichen, indem Silos abgebaut und das Personal in funktionsübergreifende, autonome DevOps-Teams umorganisiert werden, die von Anfang bis Ende (von der Planung bis zum Feedback) an Projekten arbeiten können, ohne Übergaben an andere Teams vornehmen zu müssen oder auf die Genehmigung anderer Teams warten zu müssen. Im Rahmen der agilen Entwicklung sind gemeinsame Verantwortlichkeit und Zusammenarbeit die Grundlage für einen gemeinsamen Produktfokus mit wertvollen Ergebnissen.
Auf technischer Ebene erfordert DevOps ein Engagement für die Automatisierung, die Projekte innerhalb und zwischen Workflows in Bewegung hält. Es erfordert auch Feedback und Messungen, die es den Teams ermöglichen, die Zyklen kontinuierlich zu beschleunigen und die Softwarequalität und -leistung zu verbessern.
Die Förderung einer Kultur der Zusammenarbeit und die Beseitigung von Silos bringt die Arbeit von Entwicklern und Betriebsteams näher zusammen, was die Effizienz steigert und die Workloads durch die Kombination von Workflows verringert. Da sich Entwickler und Betriebsteams viele Aufgaben teilen, gibt es im Verlauf der Projekte weniger Überraschungen. DevOps-Teams wissen genau, in welcher Umgebung der Code läuft, während sie ihn entwickeln.
DevOps-Teams liefern neuen Code schneller durch verstärkte Zusammenarbeit und die Erstellung von gezielteren (und häufigeren) Releases durch den Einsatz einer Microservices-Architektur. Dieser Prozess bringt Verbesserungen, Innovationen und Fehlerbehebungen schneller auf den Markt.
Außerdem können sich Unternehmen schneller an Marktveränderungen anpassen und die Kundenbedürfnisse besser erfüllen, was zu einer höheren Kundenzufriedenheit und einem Wettbewerbsvorteil führt. Mit kontinuierlicher Bereitstellung (Continued Delivery) und kontinuierlicher Integration (Continuous Integration) kann der Software-Release-Prozess automatisiert werden.
Continuous Delivery und Continuous Integration umfassen automatisierte Tests, um die Qualität und Zuverlässigkeit von Software- und Infrastruktur-Updates sicherzustellen. Überwachung und Protokollierung verifizieren die Leistung in Echtzeit.
Die Automatisierung, einschließlich der Infrastruktur, wie z. B. des Codes, kann bei der Verwaltung von Entwicklung, Tests und Produktion helfen und eine schnellere Skalierung mit größerer Effizienz ermöglichen.
DevSecOps integriert die kontinuierliche Integration, Lieferung und Bereitstellung in den Entwicklungsprozess, so dass die Sicherheit von Anfang an integriert ist und nicht nachgerüstet werden muss. Teams bauen Sicherheitstests und Audits in ihre Workflows ein, indem sie Infrastruktur als Code verwenden, um die Kontrolle zu behalten und die Einhaltung der Vorschriften zu verfolgen.
Ein DevOps-Ansatz kann dazu beitragen, die Arbeitszufriedenheit zu verbessern, indem er banale, sich wiederholende Aufgaben automatisiert und es den Mitarbeitern ermöglicht, sich auf erfreulichere Aufgaben zu konzentrieren, die den Geschäftswert steigern.
Die Anforderungen von DevOps und der DevOps-Kultur erfordern Tools, 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:
Mit Projektmanagement-Tools können Teams ein Backlog mit User Stories (Anforderungen) erstellen, die die Codierungsprojekte bilden, diese in kleinere Aufgaben unterteilen und die Aufgaben bis zur Fertigstellung verfolgen. Viele Tools unterstützen agile Projektmanagementpraktiken wie Scrum, Lean und Kanban, die Entwickler in DevOps einbringen. Zu den gängigen Open-Source-Optionen gehören GitHub Issues und Jira.
Dabei handelt es sich um versionskontrollierte Programmierumgebungen, die es mehreren Entwicklern ermöglichen, an der gleichen Codebasis zu arbeiten. Code-Repositories sollten in CI/CD-, Test- und Sicherheitstools integriert werden, damit Code, wenn er in das Repository übertragen wird, automatisch zum nächsten Schritt übergehen kann. Zu den Open-Source-Code-Repositories gehören GitHub und GitLab.
Dabei handelt es sich um Tools, die das Auschecken, Erstellen, Testen und die Bereitstellung von Code automatisieren. Jenkins ist das beliebteste Open-Source-Tool in dieser Kategorie. Viele frühere Open-Source-Alternativen, wie CircleCI, sind nur noch in kommerziellen Versionen erhältlich.
Bei Continuous Deployment (CD) Tools bewegt sich Spinnaker zwischen den Code-Ebenen Anwendung und Infrastruktur. ArgoCD ist eine weitere beliebte Open-Source-Lösung für Kubernetes-natives CI/CD.
Dazu gehören Software-Tools, Bibliotheken und Best Practices für die Automatisierung von Unit-, Vertrags-, Funktions-, Leistungs-, Usability-, Penetrations- und Sicherheitstests. Die besten dieser Tools unterstützen mehrere Sprachen. Einige nutzen künstliche Intelligenz (KI), um Tests als Reaktion auf Codeänderungen automatisch neu zu konfigurieren. Die Auswahl an Tools und Frameworks zum Testen ist groß und vielfältig. Beliebte Open-Source-Frameworks zur Testautomatisierung sind Selenium, Appium, Katalon, Robot Framework und Serenity (früher bekannt als Thucydides).
Konfigurationsmanagement-Tools (auch bekannt als Infrastruktur-als-Code-Tools) ermöglichen es DevOps-Ingenieuren, eine vollständig versionierte und vollständig dokumentierte Infrastruktur durch die Ausführung eines Skripts zu konfigurieren und bereitzustellen. Zu den Open Source Optionen gehören Ansible (Red Hat®), Chef, Puppet und Terraform. Kubernetes erfüllt dieselbe Funktion für containerisierte Anwendungen.
Überwachungstools helfen DevOps-Teams, Systemprobleme zu erkennen und zu beheben. Sie sammeln und analysieren auch Daten in Echtzeit, um zu erkennen, wie sich Codeänderungen auf die Anwendungsleistung auswirken. Zu den Open-Source-Überwachungstools gehören Datadog, Nagios, Prometheus und Splunk.
Diese Tools sammeln Feedback von den Benutzern, entweder durch Heatmapping (Aufzeichnung der Benutzeraktionen auf dem Bildschirm), Umfragen oder Self-Service-Problem-Ticketing.
Cloudnativ ist ein Ansatz zur Entwicklung von Anwendungen, die grundlegende Cloud Computing-Technologien verwenden. Cloud-Plattformen ermöglichen eine konsistente und optimale Anwendungsentwicklung, Bereitstellung, Verwaltung und Leistung in öffentlichen, privaten und Multicloud-Umgebungen.
Heutzutage sind cloudnative Anwendungen in der Regel:
- Erstellt durch die Verwendung von Microservices: Lose gekoppelte, unabhängig voneinander einsetzbare Komponenten, die über einen eigenen, in sich geschlossenen Stack verfügen und über REST-APIs, Event-Streaming oder Message-Broker miteinander kommunizieren.
- Bereitgestellt in Containern: Ausführbare Codeeinheiten, die den gesamten Code, die Laufzeiten und die Betriebssystemabhängigkeiten enthalten, die zur Ausführung der Anwendung erforderlich sind. Für viele Unternehmen sind Container ein Synonym für Docker-Container, es gibt jedoch auch andere Container.
- Betrieben (in großem Umfang) mit Kubernetes: Eine Open-Source-Container-Orchestrierungsplattform zur Planung und Automatisierung der Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen.
In vielerlei Hinsicht sind cloudnative Entwicklung und DevOps wie geschaffen füreinander. Die Entwicklung und Aktualisierung von Microservices, d. h. die iterative Bereitstellung kleiner Codeeinheiten für eine kleine Codebasis, passt beispielsweise perfekt zu den schnellen Veröffentlichungs- und Verwaltungszyklen von DevOps. 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 derzeitigen Microservices-Anwender erwarten, dass sie mehr Zeit, Geld und Aufwand in die Architektur investieren werden, und 56 % der Nicht-Anwender werden Microservices wahrscheinlich innerhalb der nächsten zwei Jahre einführen.
Durch die Paketierung und dauerhafte Fixierung 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. Die Kubernetes-Orchestrierung führt die gleichen kontinuierlichen Konfigurationsaufgaben für containerisierte Anwendungen aus wie Ansible, Puppet und Chef für nicht containerisierte Anwendungen.
Die meisten führenden Cloud Computing-Anbieter wie AWS, Google, Microsoft Azure und IBM Cloud® bieten eine Art verwaltete DevOps-Pipeline-Lösung an.
DevSecOps ist DevOps, das die Sicherheit kontinuierlich in den gesamten DevOps-Lebenszyklus integriert und automatisiert – von der Planung bis zum Feedback und wieder zurück zur Planung.
Man könnte auch sagen, dass DevSecOps das ist, was DevOps von Anfang an sein sollte. 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 der Sicherheitsautomatisierung in den DevOps-Lebenszyklus (ein technisches Problem). Die Sicherheit wurde als das Team von Nein und als teurer Engpass in vielen DevOps-Praktiken wahrgenommen.
DevSecOps entstand aus dem Bestreben, die Sicherheit zu integrieren und zu automatisieren, wie es ursprünglich beabsichtigt war. Bei DevSecOps ist die Sicherheit ein wichtiger Bestandteil und Stakeholder neben der Entwicklung und dem Betrieb und bringt die Sicherheit mit einem Produktfokus in den Entwicklungsprozess ein.
Site Reliability Engineering (SRE) setzt Softwaretechniken ein, um Aufgaben des IT-Betriebs zu automatisieren, wie z. B. die Verwaltung von Produktionssystemen, Änderungsverwaltung, Vorfallreaktion und sogar Notfallreaktion, die Systemadministratoren andernfalls manuell durchführen würden. SRE versucht, den klassischen Systemadministrator in einen Ingenieur zu verwandeln.
Das Ziel von SRE ähnelt dem von DevOps, ist aber spezifischer: SRE zielt darauf ab, den Wunsch eines Unternehmens nach schneller Anwendungsentwicklung mit der Notwendigkeit in Einklang zu bringen, die in Service Level Agreements (SLAs) mit den Kunden festgelegten Leistungs- und Verfügbarkeitsniveaus einzuhalten.
Ingenieure für Standortzuverlässigkeit erreichen dieses Gleichgewicht, indem sie ein akzeptables Niveau des durch Anwendungen verursachten Betriebsrisikos, das so genannte Fehlerbudget, festlegen und die Abläufe automatisieren, um dieses Niveau zu erreichen.
In einem funktionsübergreifenden DevOps-Team kann SRE als Brücke zwischen Entwicklung und Betrieb dienen. SRE stellt die Metriken und Automatisierungstools zur Verfügung, die Teams benötigen, um Codeänderungen und neue Funktionen so schnell wie möglich durch die DevOps-Pipeline zu leiten, ohne die Bedingungen der SLAs des Unternehmens zu verletzen.
Da die Bandbreite der automatisierbaren Aufgaben zunimmt, werden DevOps immer mehr Funktionen hinzugefügt, wodurch mehrere Variationen von DevOps entstehen. Und da DevOps seine vielen Vorteile unter Beweis stellt, steigen die Unternehmensinvestitionen.
Laut Verified Market Research wurde der DevOps-Markt 2023 auf 10,96 Milliarden USD geschätzt und wird bis 2031 voraussichtlich 21,13 Milliarden USD erreichen, was von 2024 bis 2031 mit einer jährlichen Wachstumsrate von 21,23 % wachsen wird.
Um den Erfolg von DevOps sicherzustellen, setzen Unternehmen zunehmend auf:
Künstliche Intelligenz für den IT-Betrieb integriert KI und maschinelles Lernen, um den IT-Betrieb zu automatisieren und zu optimieren und eine schnelle Analyse riesiger Datenmengen zu ermöglichen.
BizDevOps bringt Geschäftsbereiche dazu, am Softwareentwicklungsprozess sowie an der Entwicklung und dem Betrieb zusammenzuarbeiten. Dieser auch als DevOps 2.0 bezeichnete Kulturwandel beschleunigt den Prozess und führt zu stärkeren Lösungen, die mit den Zielen der Geschäftseinheit übereinstimmen.
Eine weitere Möglichkeit zur Steigerung der Effizienz ist die Containerisierung, bei der eine App und ihre Abhängigkeiten in einem optimierten, portablen Paket gekapselt werden, das auf nahezu jeder Plattform läuft.
Das Hinzufügen weiterer Sicherheitsfunktionen gleich zu Beginn der Entwicklung trieb DevSecOps voran. Sicherheit ist nicht länger Nebensache.
GitOps konzentriert sich auf die Speicherung von Anwendungscode in einem Git-Repository, sodass er versionskontrolliert, für mehrere Teammitglieder verfügbar sowie vollständig nachvollziehbar und überprüfbar ist. Diese Maßnahmen tragen zur Steigerung der Effizienz, Zuverlässigkeit und Skalierbarkeit bei.
Während herkömmliche Überwachungs-Tools für Transparenz sorgen, bieten Überwachungsplattformen ein tieferes Verständnis der Leistung eines Systems und, was noch wichtiger ist, den Kontext – das Warum hinter der Leistung. Zusätzlich zu diesem umfassenden Verständnis ermöglicht die Observability allen Stakeholdern den Zugriff auf die Daten, die sie für die Entwicklung von Lösungen und die Erstellung besserer Anwendungen benötigen.
Serverless ist ein Modell für die Entwicklung und Ausführung von Cloud-Anwendungen, mit dem Entwickler Anwendungscode erstellen und ausführen können, ohne Server oder Backend-Infrastruktur bereitstellen oder verwalten zu müssen. In serverlosen Architekturen schreiben Entwickler Anwendungscode und stellen ihn in Containern bereit, die von einem Cloud-Service-Anbieter verwaltet werden.
Weiterführende Lösungen
Nutzen Sie leistungsstarke DevOps-Software für die Erstellung, Bereitstellung und Verwaltung von sicherheitsrelevanten, cloudnativen Anwendungen auf mehreren Geräten, in verschiedenen Umgebungen und Clouds.
Automatisieren Sie Ihren Softwarebereitstellungsprozess für mehr Produktivität und betriebliche Effizienz.
Transformieren Sie geschäftskritische Anwendungen für Hybrid-Cloud-Umgebungen mithilfe von Stabilität, Sicherheit und Agilität.
Führen Sie Innovationen schneller durch, senken Sie die Betriebskosten und transformieren Sie den IT-Betrieb (ITOps) in einer sich verändernden Landschaft mit einer AIOps-Plattform, die Transparenz über Leistungsdaten und Abhängigkeiten in verschiedenen Umgebungen bietet.
Ressourcen
Lesen Sie, wie die Modernisierung Ihrer Mainframe-Anwendungsumgebungen zu besseren Geschäftsergebnissen führt.
Greifen Sie auf einen exklusiven Gartner®-Analystenbericht zu und erfahren Sie, wie KI für die IT die Geschäftsergebnisse verbessert, zu höheren Umsätzen führt und sowohl Kosten als auch Risiken für Unternehmen senkt.
In diesem IBM Redpaper werden Strategien und architektonische Lösungen erörtert, die Ihre Mainframe-Anwendungsmodernisierung durch die Nutzung von Hybrid-Cloud-Umgebungen beschleunigen können. Informationen zur Modernisierung von Enterprise DevOps finden Sie insbesondere in Kapitel 5.
Erfahren Sie mehr über Wazi Deploy, das das umfangreiche Entwicklungstoolset von IBM® Developer for z/OS® Enterprise Edition um eine Open-Source-basierte, skriptgesteuerte Option zur Anwendungsbereitstellung ergänzt.
Erforschen Sie ein Mehrwertprogramm für die frühe Einführung, das darauf abzielt, mit Kunden in bestimmten Phasen zusammenzuarbeiten, die unserer Meinung nach für jede DevOps-Umstellung notwendig sind.
Treten Sie der DevSecOps Community bei, um über die neuesten Z-Trends und -Themen auf dem Laufenden zu bleiben.