Was ist DevOps? Eine umfassende Einführung

DevOps ist ein Trendthema, das beliebt ist, um die Produktivität von Unternehmen zu steigern, unabhängig von der jeweiligen Branche. Jeden Tag arbeiten immer mehr Unternehmen daran, dieses disruptive Modell in ihre Organisationen einzuführen.

DevOps hat ein Hauptziel: die kontinuierliche Integration in die kontinuierliche Bereitstellung.

Dadurch werden Entwicklungs- und Betriebsprozesse schneller und ressourcenfreundlicher. Unternehmen können Geld sparen und gleichzeitig hochwertigere Softwareprodukte für den Kundenverbrauch oder den internen Gebrauch produzieren.

In diesem einführenden Artikel erklären wir die grundlegenden Konzepte von DevOps, einschließlich der Fortschritte, Best Practices, Schlüsseltopologien und der häufigsten Vorteile einer DevOps-Umgebung.

Was ist DevOps?

Traditionell gehörten die Mitarbeiter in der IT-Branche zum Entwicklungs- oder 'Dev'-Team. Ein separates Team, bekannt als IT-Betrieb oder 'Ops', unterstützte IT.

Dev- und Ops-Teams hatten getrennte Führung, Verantwortlichkeiten und Ziele zu erreichen. In vielen Unternehmen arbeiteten die Teams auf getrennten Etagen und kommunizierten selten. Diese 'Silos'-Kultur führte zu schlechter Kommunikation und Zusammenarbeit zwischen diesen Teams – eine starre Barriere zwischen ihnen, die sie nur dann überbrückten, wenn es absolut notwendig war.

Der bedeutende Wandel in der Unternehmenskultur von DevOps durchbrach erfolgreich diese Silo-Mentalität und überbrückte die Lücke zwischen Dev- und Ops-Teams, indem sie:

Arbeiten Sie zusammen
Verantwortung teilen
Übernehmen Sie die vollständige Verantwortung für die Software, die sie während ihres gesamten Softwarelebenszyklus liefern

Heutzutage wird DevOps von der IT-Branche weit verbreitet angenommen, darunter führende Technologieunternehmen wie Amazon, Facebook, Google, Netflix und BMC Software. In jüngerer Zeit beschäftigen sich Unternehmen damit, wie sie die DevOps-Prinzipien über die gesamte Organisation hinaus über die IT hinaus verbreiten können.

Kontinuierliche Integration

Kontinuierliche Lieferung

Wie sich DevOps entwickelt hat

Vor dem Jahr 2000 übernahmen die meisten IT-Branchen das klassische Wasserfallmodell, einen linearen Ansatz für die Softwareentwicklung.

Entwickler mussten viel Zeit in die Entwicklung und Integration schwerer Codestücke investieren.
QA-Ingenieure und Betriebsteams, die in Silos arbeiteten, verbrachten mehr Zeit damit, den Code zu testen.

Das Ergebnis? Eine große, manchmal jahrelange Lücke zwischen Softwareveröffentlichungen, mit häufigen Fehlerbehebungen und Softwarepatches zwischen den einzelnen Releases.

Mit der Einführung der agilen Softwaremethodik entwickelten die IT-Branchen Software iterativ und brachten sie häufig in die Produktion. Continuous Integration (CI) und Continuous Delivery (CD) gehören zu den wichtigsten Techniken, die in diesem Modell für die schnelle Bereitstellung von Software angepasst wurden. (Wir werden uns diese Konzepte gleich ansehen.)

DevOps förderte folglich die reibungslose Zusammenarbeit zwischen Entwicklungs- und Betriebsteams in jedem Schritt des Zyklus. Wir können also mit Sicherheit sagen, dass DevOps seine Wurzeln in der agilen Methodik hat.

(Erfahren Sie mehr über die Geschichte von DevOps.)

DevOps-Kultur

Beim Übergang zu einer DevOps-Kultur müssen Organisationen zwei wichtige Komponenten ändern:

Ihre traditionellen Betriebsmethoden
Ihre Denkweise

Im Allgemeinen arbeiten in einer DevOps-Kultur sowohl das Dev- als auch das Ops-Team durch häufige Kommunikation zusammen.

In einigen Organisationen übernehmen DevOps-Ingenieure sowohl Entwicklungs- als auch Betriebsarbeit. Sie beschränken ihre Verantwortlichkeiten nicht auf den definierten Umfang ihrer Arbeitsrolle. Stattdessen teilen sie die Aufgaben stets mit anderen Teams und betrachten den gesamten Entwicklungszyklus als Teil ihrer Aufgaben.

Diese Ingenieure wollen die Produktivität und die Servicequalität steigern, um ihren Kunden den größtmöglichen Mehrwert zu bieten.

Natürlich geht es bei DevOps nicht nur um Kommunikation und Zusammenarbeit. DevOps-Best Practices zielen darauf ab, Ihnen zu helfen, Software häufig und von bester Qualität zu veröffentlichen. Mit hohem Fokus auf Effizienz fördert DevOps den weitverbreiteten Einsatz von Tools zur Automatisierung manueller Aufgaben.

Werfen wir einen Blick auf gängige Praktiken und verwandte Werkzeuge jeder DevOps-Kultur.

Traditionell aktualisierten Entwickler ihren Code manuell und testeten ihn dann manuell.

Continuous Integration (CI) ist eine DevOps-Praxis, bei der Entwickler ihre Codeänderungen häufig mit dem zentralen Repository zusammenführen. Anschließend wird der Code automatisch erstellt und automatisierte Tests gegen den erstellten Code durchgeführt.

Das Hauptziel ist es, Fehler schnell zu erkennen, um die Qualität der Software zu verbessern.

Bei Continuous Delivery (CD) werden zusammengeführte Codeänderungen automatisch erstellt und in einer Testumgebung bereitgestellt. Anschließend werden automatisierte Tests gegen den bereitgestellten Code durchgeführt, um eventuelle Fehler zu identifizieren und den Entwicklern die Behebung im Voraus zu ermöglichen.

Typischerweise wird der Code schrittweise in verschiedene Testumgebungen bereitgestellt, wo er durch ein standardisiertes automatisiertes Testverfahren vor der Bereitstellung in der Produktion ein höheres Qualitätsniveau erreicht. Continuous Delivery stellt sicher, dass das Team stets einen entwicklungsreifen Code hat.

CI/CD-Tools wie Jenkins, Bamboo, Travis, TeamCity und viele andere helfen dabei, diese Aufgaben zu automatisieren.

(CI /CD untersuchen und ob kontinuierliche Bereitstellung passt.)

Kontinuierliches Testen

Die Praxis des kontinuierlichen Tests hilft, potenzielle Risiken so früh wie möglich in allen Entwicklungsphasen zu identifizieren, um die Auswirkungen auf Endnutzer zu minimieren.

Wenn beispielsweise der Code zum Build-Server bereitgestellt wird, werden automatisierte Unit-Tests durchgeführt, um Fehler im Code zu identifizieren. Wenn die Unit-Tests fehlschlagen, wird der Build abgelehnt und das Feedback an den Entwickler weitergeleitet, um den Code zu überarbeiten. Daher wird der Code nur dann in der QA-Umgebung für funktionale Tests bereitgestellt, wenn der Build die Unit-Tests besteht.

Selenium, Travis und Appium sind einige beliebte kontinuierliche Testwerkzeuge in der IT-Branche.

Kontinuierliche Überwachung

Die Anwendung, Infrastruktur, Middleware und Netzwerke werden kontinuierlich auf ihre Leistung, etwaige Fehler sowie Sicherheit und Compliance überwacht. Um Probleme zu identifizieren, überwachen die meisten Unternehmen Kennzahlen wie:

CPU- und Speichernutzung
Festplattenspeicher
Kundenaktivitäten
Sicherheitsrichtlinien

Durch die Umsetzung kontinuierlicher Überwachung werden Sie stets über Probleme in Umgebungen von der Prüfung bis zur Produktion informiert, was Ihnen hilft, eine hohe Verfügbarkeit sicherzustellen.

Beliebte Tools zur kontinuierlichen Überwachung sind Nagios, Sensu, Prometheus und viele mehr.

Infrastruktur als Code

Infrastructure as Code (IaC) ist eine Praxis, bei der Infrastruktur – virtuelle Maschinen, Load Balancer, Netzwerke usw. – mithilfe von Code konfiguriert und verwaltet wird, anstatt diese Ressourcen manuell einzurichten und zu verwalten. Dies ist zu einer wesentlichen DevOps-Praxis in Organisationen geworden, die speziell auf Cloud-Plattformen umgestiegen sind.

Zum Beispiel stellen Amazon Web Services (AWS) APIs bereit, um programmatisch mit ihrer Cloud-Infrastruktur zu interagieren. Die Verwendung von Code zur Konfigurationsdefinition hilft, den Prozess zu standardisieren, sodass Ressourcen schnell in die Cloud bereitgestellt werden können.

Microservices

Im Gegensatz zu traditionellen monolithischen Architekturen wird in der Microservices-Architektur eine einzelne Anwendung als eine Menge kleiner Services oder Komponenten aufgebaut. Diese separaten Services haben ihre eigene Funktionalität und ihre Kommunikation erfolgt über eine leichte Schnittstelle oder eine API.

Als weitgehend angepasste Architektur in der DevOps-Kultur sind Microservices:

Förderung eines unabhängigen Ressourcenmanagements innerhalb verschiedener Komponenten.
Verbessern Sie die Systemverfügbarkeit, indem Sie einen Single Point of Failure verhindern, da es keine Auswirkungen auf andere Komponenten gibt, wenn eine Komponente abstürzt.
Ermöglichen Sie DevOps-Teams, zusätzliche Komponenten mit unterschiedlichen Funktionen hinzuzufügen, ohne andere Komponenten zu beeinträchtigen.

(Verstehen Sie die Best Practices für Microservices.)

DevOps-Topologien

Die Art und Weise, wie DevOps praktiziert wird, hängt stark von der Organisation ab. Laut Matthew Skelton und Manual Pais verwenden Organisationen verschiedene Arten von Topologien oder Teamstrukturen, damit DevOps gedeihen kann. Sie definieren 9 Arten von Topologien wie folgt.

DevOps-Praktiken

Dev & Ops Zusammenarbeit

Das ist die ideale DevOps-Teamstruktur, bei der Dev- und Ops-Teams reibungslos zusammenarbeiten. Zum Beispiel:

Entwickler nehmen die Aufgaben der Betriebsteams ernst und erhalten deren Input, wenn nötig.
Betriebsteams bekommen ein gutes Verständnis der Aufgaben, die Entwicklerteams routinemäßig ausführen.

Vollständig geteilte Einsatzverantwortlichkeiten

Diese Topologie, die bei Facebook und Netflix implementiert wurde, besteht aus Entwicklerteams, in die auch Operationsteams integriert sind. Zwischen Entwicklern und Ops sieht man nur eine geringe Trennung.

Dies ist am besten geeignet für Unternehmen, die einzelne webbasierte Anwendungen anbieten.

Ops als Infrastruktur-as-a-Service

Diese Topologie eignet sich für Organisationen mit unterschiedlichen/mehreren Services, die auf Cloud-Plattformen gehostet sind, aber dennoch eine traditionelle IT-Betriebsabteilung haben, die sich wahrscheinlich nicht ändern wird. Ihr Ops-Team ähnelt dem Infrastructure as a Service (IaaS).

DevOps als externer Service

Manche Organisationen verfügen möglicherweise nicht über die Expertise oder können sich kein separates Betriebsteam leisten. Hier können die Entwicklungsteams Unterstützung von einem Dienstleister erhalten, der die Aufgaben der operativen Aspekte der Software verwaltet.

DevOps-Teams mit Ablaufdatum

Diese Struktur fungiert als temporäres Team, das darauf abzielt, Dev- und Ops-Teams zusammenzubringen. Dieses temporäre Team wird nach Erreichen des vordefinierten Ziels obsolet.

DevOps-Advocacy-Team

Diese Topologie eignet sich am besten für Teams, die sich auseinanderdriften. Das Advocacy-Team unterstützt die Dev- und Ops-Gruppen, hält sie engagiert und macht sie kontinuierlich über DevOps-Praktiken informiert.

SRE-Team

Diese in Google adaptierte Topologie besteht aus einem Site Reliability Engineering (SRE) Team. Entwickler müssen nachweisen, dass ihre Software den Standards entspricht – und das SRE-Team kann dies ablehnen, wenn das Gegenteil bewiesen ist.

(Vergleichen Sie SRE- und Ops-Teams.)

Containergesteuerte Zusammenarbeit

Containerisierung ist die Praxis, eine Anwendungsbereitstellung und Laufzeitanforderungen in einen Container zu kapseln. Dies beseitigt einige Kollaborationsabhängigkeiten zwischen Entwickler- und Betriebsteams.

Diese Struktur eignet sich für eine Organisation mit einer starken Ingenieurskultur.

(Erfahren Sie mehr über das Management von Code und Containern.)

Zusammenarbeit zwischen Entwicklung und DBA

Einige Organisationen, die mehrere Anwendungen mit großen zentralen Datenbanken haben, haben mit dieser Topologie experimentiert. Die Struktur besteht darin, dass Datenbank- (DBA)-Spezialisierungsrollen sowohl im DBA- als auch im Entwicklungsteam integriert sind, was dazu beiträgt, die Lücke zwischen beiden Parteien zu schließen.

Wichtige Vorteile von DevOps

Organisationen, die die DevOps-Kultur annehmen, sehen Verbesserungen in vielen Bereichen ihres Softwarelieferprozesses, darunter:

Verbesserung der Kommunikation und Zusammenarbeit zwischen Teams
Steigerung der organisatorischen Effizienz und Produktivität
Erhöhung der Geschwindigkeit von Softwareveröffentlichungen
Maximierung der Kundenzufriedenheit (Ihre Kunden erhalten jetzt hochwertige Software)
Sicherstellung der Systemverfügbarkeit und Zuverlässigkeit dank schnellerer und früherer Bedrohungs- und Vorfallerkennung
Förderung von Innovation, dank des Austauschs unterschiedlicher Ideen zwischen den Teams

In diesem Video teilen David Rizzo, VP Product Engineering bei BMC Software, und David Kennedy, Solutions Architect, wie Compuware sich zu DevOps entwickelte, um Innovation zu steigern, entgangene Fehler zu reduzieren und MTTR zu verbessern.

DevOps geht über ein Geschäftsmodell hinaus

Aufgrund seiner abstrakten Natur ist es schwierig, DevOps in nur wenigen Sätzen zu definieren. Wie ich bereits sagte, ist DevOps nicht nur ein Geschäftsmodell, sondern ein kultureller Wandel, der Softwareentwicklungs- und Betriebsprozesse in einen einheitlichen Workflow integriert und automatisiert, wobei der Fokus auf die schnelle Veröffentlichung hochwertiger Software liegt, die die Kundenanforderungen erfüllt.

DevOps erreicht seine Exzellenz, indem es definierte Best Practices in jeden Schritt des Softwareentwicklungslebenszyklus integriert. Organisationen sind verpflichtet, die Teamtopologie zu identifizieren, die für DevOps am besten geeignet ist, um langfristig anzustreben.

Wenn sie richtig angenommen wird, kann die DevOps-Kultur enormen Nutzen für erfolgreiche Software-Releases für Organisationen bringen.

Workflow-Orchestrierung

Mainframe-Vereinfachung

Beliebte Reiseziele

Was ist DevOps? Eine umfassende Einführung