Menü
Ein Beitrag von Adacor

Wann DevOps für Unternehmen sinnvoll ist

DevOps Strategien für UnternehmenDevOps ist ein großes Thema in den Unternehmen. Ein Hype, der noch lange nicht vorbei ist, sondern weiter an Fahrt aufnimmt. Aber um was geht es da eigentlich genau? Sprechen wir von der bloßen Zusammenarbeit der Entwicklungs- und IT-Betriebsabteilungen in den Unternehmen, oder steckt mehr hinter dem Schachtelwort?

DevOps beginnt vor dem Code

Die genaue Erklärung ist vielschichtiger: DevOps beschreibt einen Ansatz zur Prozessverbesserung zwischen der Softwareentwicklung (Development) und der Systemadministration beziehungsweise dem IT-Betrieb (Operations). Das Ziel ist es, durch gemeinsame Anreize, Prozesse und Werkzeuge eine wirkungsvollere und wirtschaftlichere Zusammenarbeit dieser beiden Unternehmensbereiche mit dem Qualitätsmanagement zu erreichen. Dadurch sollen die Softwarequalität, die Entwicklungs- und Auslieferungsgeschwindigkeit sowie der Zusammenhalt der am Prozess beteiligten Teams verbessert werden. Diese ganzheitliche Sichtweise bringt eine enorme Dynamik in IT-bezogene Projektabläufe und so kann DevOps die IT beschleunigen.

Ich bin ein großer Fan von agilen Ansätzen, trotzdem sind mir einige komplizierte Zusammenhänge klar geworden, über die es sich nachzudenken lohnt. Sie stellen die DevOps-Kultur samt der agilen Ansätze nicht infrage, wohl aber die aktuell im Hype-Modus getakteten Werbeslogans und Herangehensweisen an das Thema.

DevOps benennt ein altes und bekanntes Problem

Die Probleme zwischen Entwicklung und Betrieb in der IT sind ein alter Hut – nur erhält das Baby durch den DevOps-Hype einen neuen Namen. Die damit verbundenen Herausforderungen können nicht automatisch durch agile Ansätze bewältigt werden. Vielmehr müssen selbst eingespielte Teams aus Entwicklern und Betriebsmitarbeitern, die plötzlich zusammen in einem Raum sitzen, mit einem neuen „Mindset“ ausgestattet werden. Das stellt sich in der Praxis häufig als schwieriges und mühevolles Unterfangen dar.

Es wird in der IT weiterhin Projekte geben, in denen es nicht gelingen wird, die Entwicklung und den Betrieb konzeptionell und organisatorisch zu einer erfolgreichen DevOps-Zusammenarbeit zu bewegen. Trotzdem müssen solche Vorhaben zukünftig beweglicher werden, um agiler und schneller auf die Business-Anforderungen im Rahmen der Digitalisierung reagieren zu können. Und dabei helfen entsprechende Ansätze und Denkweisen sicher weiter. Allein eine transparentere Kommunikation und das Stecken und Verfolgen gemeinsamer Ziele sind ein Anfang.

Das „Blame Game“ zwischen den Herstellern oder Entwicklern einer Software und den Mitarbeitern oder Kunden, die sie betreiben, muss auf andere Weise gelöst werden können, als alles wegzuwerfen und neu anzufangen.

Viele Unternehmen müssen aller Voraussicht nach von vorne anfangen

Wer eine Software entwickeln und betreiben möchte und dabei oft damit in Verbindung gebrachte Modethemen wie „continuous integration“ (fortlaufende Integration) oder „Infrastructure as Code – kurz IaC“ (Infrastruktur, die Betriebsteams statt manueller Verfahren automatisch per Code verwalten und bereitstellen können) umsetzen will, für den ist das Zusammenfinden der beiden Bereiche „Entwicklung und Betrieb“ vor der ersten Zeile Code obligatorisch.

Das „macht“ man allerdings nicht „einfach mal eben“ – beziehungsweise „schaltet“ es in einem Bestandsprojekt „nicht mal schnell an“. Vielmehr ist die Eingliederung dieser Themen die hohe Schule des gesamten DevOps-Prozesses. Häufig dreht man viele agile Iterationsrunden, bevor etwas Sinnvolles (wie eine funktionierende Applikation, die stabil betrieben wird und stündliche Releases verkraftet) herauskommt. Es ist viel initiale Projektarbeit nötig, um die erforderlichen Konzepte, Abläufe und Technologien aufeinander abzustimmen.

In den einzelnen Bereichen (Dev oder Ops) wird es weiterhin Spezialisten für den Betrieb und Spezialisten für die Entwicklung geben. Der eigentliche Betrieb wird aber von – im Bereich DevOps und einer darauf abgestimmten Technologie ausgebildeten – Experten durchgeführt werden. Das heißt, auch bei der Realisierung von DevOps werden Spezialisten gebraucht.

Themen wie „administrativer Zugriff auf die Shell“ werden dann nicht mehr diskutiert, denn sie sind im Idealfall gar nicht mehr notwendig. Die Administratoren oder die Software selbst „pflegen“ gemäß dem Cattle-/Cat-Prinzip eine Vielzahl der Systeme nicht mehr, sondern nutzen diese nur noch für ihren exakt bestimmten Zweck und für eine potenziell kurze Zeit. Ob Container, virtuelle Server oder andere Abstraktionen spielt dabei keine Rolle. Wichtig ist, dass die Applikation selbst in der Lage sein sollte, die Ressourcen zu verwalten und das Einspielen der Releases zu managen.

Was ist das Cattle-/Cat-Prinzip?

Als „Cat” werden Server mit eigenem Namen (zum Beispiel garfield.example.com) bezeichnet. Der Name dient nicht nur zur Server-Erkennung, sondern lässt auch erkennen, dass die Maschine per Hand groß gezogen und für ihre Rolle ausgewählt wurde. Wenn auf solchen Servern ein Problem entsteht, werden sie wie ein Haustier beziehungsweise ein Kätzchen sorgsam umsorgt und gepflegt, bis sie wieder gesund sind.
„Cattle”, das Nutztier, stellt das andere Ende des Spektrums dar. Hier haben die Server meistens keinen eigenen Namen, sondern nur Nummern wie web001.example.com. Die virtuellen Maschinen werden in der Regel über ein Skript angelegt und mit ihrer Konfiguration bespielt. Der Server mit der Nummer Eins ist quasi identisch mit web002.example.com und anderen Servern mit derselben Aufgabe. Wenn auf einem der Server ein Problem auftritt, wird er gelöscht und ein neuer aufgesetzt.
Eine Definition des Cat- und Cattle-Prinzips und den verschiedenen Anwendungsmöglichkeiten haben wir in unserem Blog bereits veröffentlicht.

DevOps ist kein Framework, sondern eine Kultur

Das Ziel, das mit DevOps verfolgt wird, kann von Projekt zu Projekt und Firma zu Firma stets ein anderes sein. Bei sämtlichen Überlegungen sollte man jedoch beachten, dass DevOps und die damit verbundene Herangehensweise kein Framework sind, sondern eine Kultur. Deshalb ist es wichtig, vor jedem Projekt die genaue Zielsetzung zu definieren: Was soll in welchem Maß gemeinsam von beiden Bereichen gesteuert und verwaltet werden? Wie viel darf die Implementierung kosten, um den Softwarebetrieb sicherzustellen? Sind die Anwendungen vollständig automatisiert, muss die Verwaltung der virtuellen Ressourcen und Container in die Applikation verlagert werden, oder ist (zum Beispiel aus Kostengründen) gar nicht möglich, so weit zu gehen? Hier kann es viele Abstufungen geben.

Normalerweise geht man davon aus, dass auch vor agilen Projekten eine grundsätzliche Kosten-/Nutzenprüfung steht. Meinen Erfahrungen zufolge ist das in der Praxis aber meist anders. Das Thema tritt bei vielen Unternehmen eher in den Hintergrund. DevOps und Agilität liegen im Trend, deshalb steigen viele Unternehmen in das Thema ein, ohne die Notwendigkeit zu hinterfragen. Aber nur, weil „alle“ auf den DevOps-Zug aufspringen, ist das Thema noch lange nicht für alle Unternehmen vorteilhaft oder notwendig.

Image

6 Kriterien, die Ihr Hosting-Projekt groß machen

Cloud-Lösungen bieten Unternehmen zahlreiche Vorteile. Worauf Sie achten sollten, verraten wir hier.

Weiter lesen

Normalerweise geht man davon aus, dass auch vor agilen Projekten eine grundsätzliche Kosten-/Nutzenprüfung steht. Meinen Erfahrungen zufolge ist das in der Praxis aber meist anders. Das Thema tritt bei vielen Unternehmen eher in den Hintergrund. DevOps und Agilität liegen im Trend, deshalb steigen viele Unternehmen in das Thema ein, ohne die Notwendigkeit zu hinterfragen. Aber nur, weil „alle“ auf den DevOps-Zug aufspringen, ist das Thema noch lange nicht für alle Unternehmen vorteilhaft oder notwendig.

Braucht man ohne Dev überhaupt DevOps?

Wer proprietäre Software kauft und auf seinen eigenen Systemen betreibt, hat kaum Möglichkeiten, um die Entwicklung zu beeinflussen. Bei einem solchen Szenario braucht man definitiv kein DevOps-Team. An dieser Stelle ist vielmehr eine Überprüfung der Abläufe und Prozesse der eigenen, traditionellen IT-Landschaft zu empfehlen. Vielleicht ergeben sich dabei Lösungen, um das ganze System schneller laufen zu lassen. Alternativ kann man mit der Entwicklung ganz von vorne anfangen.

Agilität ist nicht gleich DevOps

Beide Themen unterscheiden sich voneinander. Das wird in der Literatur und Praxis nicht immer deutlich. DevOps ist in der Tat eine sehr agile Kultur oder Herangehensweise im Rahmen des IT-Servicemanagements und der Entwicklung. Allerdings löst der Optimierungsansatz nicht alle Probleme der traditionellen und meist statischeren IT. Wenn man den vielen Werbephrasen glauben darf, dann ist es die „Eierlegende Wollmilchsau“ der IT. Aber das stimmt nicht. Es ist ein Teilbereich davon und eher eine Herangehensweise.
So hält Der IT-Experte Donovan Brown von Microsoft fünf Tipps bereit, wie Unternehmen mit DevOps starten können.

5 Tipps damit Unternehmen mit DevOps starten können

  1. Gehe schrittweise vor und beginnen mit DevOps in dem Bereich, wo der Schuh am meisten drückt. Anschließend widmen Sie sich dem zweitgrößten Problem Das ist besser als gleich das ganze Programm umsetzen zu wollen!
  2. Sorge dafür, dass jedes Mal, wenn ein Entwickler den Code verändert, dieser auch eingebaut wird.
  3. Stell sicher, dass die Testumgebung deckungsgleich zur Live-Umgebung ist.
  4. Finde Wege, um automatisierte Tests hinzuzufügen und führen diese mehrfach durch.
  5. Erweitern die Pipeline sukzessive und weite DevOps Schritt für Schritt aus.

Agilität in der IT und im IT-Servicemanagement

Die IT-Landschaften in den Unternehmen sind in der Regel zu groß und heterogen, um die gesamte Unternehmens-IT über einen Kamm scheren zu können. Im Vorteil sind diejenigen, die agil starten und erst einmal nur kleine, überschaubare Bereiche verändern; die zunächst Erfahrungen in agilen Methoden sammeln und die „traditionell“ gemanagte IT nicht generell und ohne Grund in Frage stellen. Diese machen trotzdem meist noch einen guten Job. Nicht jede traditionelle IT-Landschaft ist zu teuer oder zu statisch, nur weil keine agilen Methoden eingesetzt werden oder weil die Projekte nicht der DevOps Kultur folgen.
Es kann Unternehmen durchaus passieren, dass ein neues Projekt, das viele „neue“ agile Herangehensweisen beinhaltet, kulturell DevOps lebt und nahezu vollständig automatisiert ist, VMs hoch und runter fährt, stündliche Deployments macht – und sehr viel teurer als erwartet ist. Die gängigen Erfahrungen zur Kostenabschätzung im IT-Betrieb treffen nämlich nicht mehr zu. Zu hoffen ist in einem solchen Fall, dass das Ziel die Erreichung einer hohen Service-Qualität war und nicht die Reduktion von Kosten. Die Entscheider in einem Unternehmen sollten sich davon verabschieden, die IT lediglich als einen einzigen Kostenblock zu sehen, mit dem man jährlich Einsparungsrunden drehen kann. Die einzelnen, durch die IT gesteuerten Prozesse sind maßgeblicher Teil der Wertschöpfungskette und werden im Rahmen der Digitalisierung in Zukunft mehr vom Kuchen benötigen.

Fazit

Ein einzelner Artikel oder auch ein ganzes Buch über agile Methoden werden die Probleme der Unternehmen beim Thema „DevOps“ nicht ausreichend beleuchten. Meist ist jede Information auch nur ein Baustein zum Gesamtbild. Das zu zeichnen, bleibt die große Aufgabe in den Unternehmen.

Die Anforderungen an die IT wachsen weiter, vor allem im Bezug auf die Geschwindigkeit. Dabei stellt die Vorgaben selten die IT, sondern diese stammen aus Fachabteilungen oder werden durch das jeweilige Geschäftsmodell verursacht. Hier helfen schnelle Reaktionen auf die Veränderungen, eine offene Sichtweise und ein vorausschauendes Tun und Handeln. Jedem, der in der IT arbeitet, muss klar werden: Ein System ist niemals fertig. Es muss sich entwickeln beziehungsweise weiterentwickeln.

Der IT-Betrieb glich bisher immer einer Fahrschulprüfung. Solange man sich regelkonform verhielt und der Prüfer hinten auf der Rückbank still saß, machte der Schüler alles richtig. Das ändert sich gerade, und der Prüfer ruft mittlerweile recht häufig nach vorne: „Ach ja, beim Stopp-Schild können Sie nun einfach weiterfahren.“ Genauso ist es bei der Einführung von agilen Methoden oder DevOps. Das Vorgehen ändert sich, es wird schneller und beweglicher.
Neophobie ist fehl am Platz. Innovationstreiber sind im IT-Betrieb gefragt. Bei Adacor haben wir das Glück, dass unsere Entwicklungsabteilung schon früh agile organisatorische Herangehensweisen getestet und anschließend in der ganzen Firma implementiert hat. Aus dem Betrieb hat sich ein Team entwickelt, dass mit den Kollegen aus der Entwicklung zusammenarbeitet und DevOps vorbildlich lebt und vermittelt. Diese Innovationstreiber sind für unsere Entwicklung maßgeblich.
Ich arbeite schon fast zwanzig Jahre in der IT, habe selbst entwickelt und Erfahrung im Betrieb gesammelt. Mein Fazit lautet deshalb: Die Bereiche Dev und Ops gehören einfach zusammen, jetzt müssen sie noch zusammenwachsen. Dabei sollten die Softwareentwickler ihre Tätigkeit transparenter gestalten, und auch die Kollegen aus dem IT-Betrieb sollten sich gern in die Karten schauen lassen. Das wäre ein guter Start einer langen Reise.

, , , , ,


Weitere Artikel zum Thema lesen

ISO 27001 Zertifizierung – bester Schutz für IT

Biz & Trends, Cloud, Hosting, IT Security

ISO 27001 Zertifizierung – bester Schutz für IT

Aufgrund der Komplexität von Informationstechnik und der Nachfrage nach Zertifizierungen sind in den letzten Jahren zahlreiche Anleitungen, Standards und nationale Normen zur IT-Sicherheit entstanden....

weiter lesen

Taskmanagement – Verknüpfung von Kanban mit Helpdesk

Biz & Trends, Cloud, Hosting

Taskmanagement – Verknüpfung von Kanban mit Helpdesk

Warum wir unser Kanban-System mit dem Ticketsystem (OTRS) verbunden haben.

weiter lesen

Berechnung von Verfügbarkeiten von IT-Plattformen

Biz & Trends, Cloud, Hosting

Berechnung von Verfügbarkeiten von IT-Plattformen

So lässt sich die Verfügbarkeit von IT-Plattformen sinnvoll berechnen.

weiter lesen


Neueste Nachrichten von Adacor

OpenStack Cloud Module

Cloud

Von VMware zur Self Managed Cloud – OpenStack auf dem Prüfstand

Was leistet die Open-Source-Software OpenStack? Wo liegen ihre Grenzen?

weiter lesen

IT Security

EU-DSGVO stellt hohe Ansprüche an Datenschutz

Geforderte Maßnahmen der EU-DSGVO beginnen bei der Datenportabilität d.h. Wie Unternehmen informieren müssen und umfassen den Datenschutz durch Technikgestaltung.

weiter lesen

Nach der Cloud Foq-Computing

Biz & Trends

Eine Orientierung zum Fog-Computing

Nach dem Cloud-Computing kommt mit dem Fog-Computing ein neuer Trend in die IT.

weiter lesen

Diese Website verwendet Cookies. Mit der weiteren Nutzung der Website stimmen Sie unserer Datenschutzerklärung zu.
Für weitere Informationen klicken Sie bitte hier.