Was ist DevOps?

DevOps ist ein Stichwort, das vor allem von IT-Organisationen, als auch Personen, die sich mit der Modernisierung der IT auseinandersetzen, verwendet wird. Leider ist man sich in der Praxis oft nicht einig, was sich hinter dem Begriff DevOps verbirgt, weshalb ich in diesem Video das Ganze Ihnen darstellen werde. Beginnen wir zunächst einmal mit dem Ursprung des Wortes DevOps. Betrachtet man die beiden Teile des Wortes DevOps, also Development und Operations, so kann man zunächst einmal darauf schließen, dass es sich dabei um eine Rolle handelt. Schließlich sind diese beiden Teile auch Rollen von herkömmlichen IT-Organisationen. Die Frage, die sich nun also stellen könnte, handelt es sich bei DevOps um eine völlig neue Art von Rolle oder eben eine Tätigkeitsbeschreibung, was eine solche Rolle ausüben soll. Viel öfter aber auch spricht man hier letztendlich von einem Best-Practice-Model, also was sollte man tatsächlich tun, um diese beiden Aspekte entsprechend garantieren zu können. Auch sehr oft verwendet ist die Bezeichnung von DevOps für die nächste Generation des Systemadministrators, also eine Erweiterung der Fähigkeiten, die ein Systemadministrator mit sich bringen muss. Letztendlich geht es bei DevOps primär um den Software-Lebenszyklus. Betrachtet man also die tatsächliche tägliche Entwicklung von Software, wirken hier vor allem zwei Kräfte: Die Entwicklung der Anwendung und deren Betrieb. Im Rahmen immer komplexer werdender Software ist es wichtig, dass hier beide Parteien, also Entwicklung und Operations an einem Strang ziehen. Das heißt mitunter auch, dass beide Parteien Fähigkeiten zur Verfügung stellen, die mitunter dem anderen helfen können. Schließlich wissen Entwickler meist besser, wie Ihre Anwendung zu deployen ist, als Operations es tatsächlich garantieren kann. Schließlich definiert der Code meistens, wie eine Anwendung funktioniert, und für Operations kann im Normalfall immer nur eine Anleitung bereitgestellt werden. Letztendlich ist DevOps also ein Modell, in dem beide Parteien nach idealen Vorstellungen ihr Bestes zum jeweiligen anderen beitragen können. Um das aber entsprechend mit Mitteln und Methoden zu unterstützen, hat DevOps einige Meinungen darüber, wie Dinge innerhalb einer IT-Organisation getan werden sollten. Ich beginne also nun zunächst einmal mit dem Rollen-Verständnis. Letztendlich kann innerhalb von DevOps eine Rolle Entwicklung sein. Entwicklung bedeutet nicht mehr, nur noch Code für Software zu schreiben, sondern tatsächlich auch Code für Server zu schreiben. Auch die normale Systemadministration ist Teil des Begriffes DevOps. Da es aber hier auch vor allem um die Software geht, muss sichergestellt sein, dass diese performant läuft. Für diesen Zweck versteht DevOps auch hier das Rollenverständnis eines sogenannten Site Reliability Engineers, also eine Person, die sich darum kümmert, dass eine Applikation ideal bis zum Kunden kommt. Im Rahmen der modernen Methoden, die rund um die Cloud entstehen, ist DevOps auch vor allem im Bereich Cloud in Form des Cloud-Architekten wichtig. Auch diese Rolle wird oft im Rahmen von DevOps benutzt. Neben der Gestaltung der Infrastruktursicht beispielsweise für die Cloud ist es auch oft wichtig, die Gesamtplattform, also die Applikation als solches zu entwerfen. Auch zu diesem Zweck kann die Rolle DevOps beitragen. Was genau sind, also nun die Erwartungshaltungen für die Tätigkeit innerhalb des Bereiches von DevOps. Zunächst einmal wird Systemadministration nicht mehr wie üblich gemacht, sondern nach Möglichkeit komplett automatisiert. Das Ganze geht einher mit der Sicherstellung, dass Anwendungen korrekt funktionieren können, und ist der Tatsache geschuldet, dass Software immer komplexer wird und auf immer mehr Servern gehostet wird. Wie in dem Lebenszyklus so eben gesehen, ist es also wichtig, dass auch der gesamte Bereitstellungsprozess also vollkommen automatisiert ist und die Methodiken für das Deployment von Software immer gleich sind. Sollte man also nun alle manuellen Aufwände minimiert haben, ist der Softwarefortlauf durch die gesamte Kette sichergestellt. Damit all diese Dinge natürlich funktionieren können, ist es wichtig, dass im Rahmen von DevOps-Tätigkeiten auch technische Architekturen entworfen werden, die mit diesem Modell genutzt werden können. Leitet man also nun von dem Praktizieren von DevOps die Best-Practices ab, so ist zunächst einmal wichtig, dass die Automatisierung wirklich an allen Enden genutzt wird. Jede Art von Aufgabe, die vor allem wiederholt wird, sollte ein Kandidat für Automatisierung sein. Zu diesem Zweck ist es wichtig, dass hier für eine große Anzahl von verschiedenen Tools eingesetzt wird, die in ihrem jeweiligen Bereich gut operieren können. Bei solchen Tools handelt es sich einerseits um technische Tools, als auch um Vorgehensmodelle, wie Dinge tatsächlich getan werden sollten. Für diese Dinge sind natürlich nun möglich, wenn vor allem auch nicht manuelle physische Vorgänge nötig sind, wie beispielsweise bei herkömmlicher Hardware. Daher setzt DevOps auch einen hohen Grad an Virtualisierung voraus. Automatisierungen können selbstverständlich nur dann funktionieren, wenn die herkömmliche Vorgehensweise einer Struktur folgt. Das heißt also, das Ad-hoc-Zugriffe auf Server und manuelle Änderungen der Vergangenheit angehören. Damit diese Dinge in der Realität tatsächlich funktionieren können, ist es wichtig, dass die Kommunikation der Mitglieder von Teams untereinander sehr gut ist, als auch zwischen Teams und vor allem hier ein hoher Grad von Selbstbestimmung herrscht, so dass die Teams für sich entscheiden können, was die beste Lösung ist. Man sieht also, dass mit DevOps einhergehend auch kulturelle Aspekte sehr wichtig sind. Abschließend möchte ich nun mit einem der wichtigsten Bücher, das man am Markt finden kann, dem Phoenix Project. Wenn man nach Buchempfehlungen im Bereich DevOps frägt, wird das Phoenix Project oft als die DevOps-Story genannt. Dabei handelt es sich letztendlich nicht um ein technisches Buch, in dem beispielsweise Tools und Ähnliches vorgeschlagen werden, sondern viel mehr um eine Geschichte, wie eine IT-Organisation mit Problemen aus der modernen Realität umgehen kann. Das heißt also auch, dass viele Organisationen sich in diesem Buch selbst wiederfinden können, denn es geht hier um eine Firma, die letztendlich aus einer etwas älteren IT-Welt kommt, in der ein hoher Grad an Automatisierung aktuell noch nicht herrscht. Der Titel des Buches kommt dann vom Launch des sogenannten Projekts Phoenix - ein Projekt mit sehr hoch gesteckten Zielen. Und wie viele andere Projekte sind zunächst einmal die Erwartungen an dieses Projekt viel zu hoch. Da die möglichen Stakeholder, also das Business, die Komplexitäten der IT nicht hundertprozentig verstehen, setzen Sie zusätzlich sehr enge Zeitspannen, und es wird ein hoher organisationeller Druck aufgebaut. Wie also viele Projekte ist dieses von Anfang an zum Scheitern verurteilt. Trotzdem werden die Protagonisten in dem Buch das Ganze mit Hilfe von agilen Arbeitsweisen und den Prinzipen von DevOps, die in der Organisation eingeführt werden, lösen können. Es handelt sich dabei also um eine Erfolgsgeschichte, wie DevOps in der Realität funktionieren könnte. Man sieht also, dass es im Großen und Ganzen eine gewisse Unklarheit um den Begriff DevOps gibt. Ich hoffe trotzdem, dass ich Ihnen die richtigen Möglichkeiten aufgezeigt habe, was DevOps für Sie letztendlich bedeuten kann.