DevOps richtig umsetzen

Warum die Zeit für das Spring Boot der Infrastruktur-Automatisierung gekommen ist

Philipp Strube
DevOps-Initiative

© Shutterstock / Wright Studio

Warum scheitern so viele DevOps-Initiativen und wie können bestehende Organisationsstrukturen auf funktionsübergreifende DevOps-Teams umgestellt werden?

Gartner prognostiziert​, dass bis 2022 75% der DevOps-Initiativen die Erwartungen von Organisationen aufgrund von Problemen Neues zu lernen und die Veränderungen umzusetzen nicht erfüllen werden. Aber DevOps-Initiativen sind wichtig für Unternehmen, weil sie Fähigkeiten ermöglichen, die kritisch sind, um für den zukünftigen Wettbewerb gewappnet zu sein. Ohne die sprichwörtliche Mauer abzureißen, die die IT zwischen Entwicklung und Betrieb errichtet hat, ist es aussichtslos, dass Unternehmen digitale Dienste bereitstellen können, wie wir alle sie als Kunden heutzutage erwarten.

Aber bevor wir uns damit befassen können, wie ein Framework für Infrastrukturautomatisierung Ihrer DevOps-Initiative zum Erfolg verhelfen kann, müssen wir zunächst einmal genauer untersuchen, warum so viele dieser Initiativen scheitern.

Warum scheitern so viele DevOps-Initiativen?

In den letzten zwei Jahren habe ich bei ​Container Solutions​ mit Teams aus Branchen von Stahl bis Fintech und von Landwirtschaft bis Telekommunikation an verschiedenen Aspekten ihrer Cloud-Native-Transformationen gearbeitet. Die Einführung von DevOps-Prinzipien ist immer ein großer Teil einer solchen Transformation. Am schwierigsten ist es für Unternehmen dabei wahrscheinlich, ihre bestehende Organisationsstruktur auf funktionsübergreifende DevOps-Teams umzustellen.

Aber Unternehmen brauchen diese Veränderungen, weil die Nutzung digitaler Dienste für die Mehrheit der Verbraucher bereits zum Alltag gehört. Dies verursacht enormen Druck bei den Teams. Die erforderlichen Veränderungen sind, insbesondere aus der Sicht von traditionellen Betriebs-Teams gewaltig. Es ändert sich dabei scheinbar alles. Team-Zusammensetzung, Arbeitsablauf, Verantwortlichkeiten und Werkzeuge. Und vergessen Sie nicht, dass diese Umstellungen selten auf der grünen Wiese geschehen. Die Teams in diesen Initiativen werden oft gebeten, weiterhin bestehende Systeme zu unterstützen aber gleichzeitig die neuen Herangehensweisen zu lernen.

Für den Einzelnen bringt dieser Wandel eine Menge Unsicherheit mit sich. Es wird vielleicht nicht immer offen zugeben – oder schlimmer noch, es wird hinter Feindseligkeit verborgen – aber Selbstzweifel sind weit verbreitet und auch absolut verständlich. Die Mitarbeiter fragen sich, ob sie persönlich in dieser neuen Welt Erfolg haben werden, und haben Angst davor, was dies für ihre Karrieren bedeutet.

Und zusätzlich zu dem hohen Druck und den Selbstzweifeln, immer überschattet von der „sie gegen uns“-Mentalität, die die alte IT jahrelang gepflegt hat, werden Menschen mit einem traditionellen IT-Betriebshintergrund gebeten, mehr wie „sie“ zu arbeiten.

Anwendungsteams und Plattformteams

Erstens ist es entscheidend, die „sie gegen uns“-Mentalität los zu werden. Ich erkläre das gerne so, dass alle Teams funktionsübergreifende DevOps-Teams sind. Aber einige arbeiten an Anwendungen und andere auf der Plattformebene.  Aber dennoch, während Anwendungsteams Spring Boot oder ähnliche Frameworks verwenden, um schnell voranzukommen, haben Plattformteams nur Low-Level-Tooling zur Verfügung, um die Infrastruktur und Automatisierung aufzubauen.  Dieser Mangel an ausgereiften Werkzeugen in Verbindung mit dem hohen Druck und der Notwendigkeit, neue Fähigkeiten zu erlernen, fügt der Mischung ein sehr starkes und kontraproduktives Gefühl hinzu. Das Gefühl, ungerecht behandelt zu werden. Es ist schwer, sich nicht ungerecht behandelt zu fühlen, wenn von Ihnen erwartet wird, dass Sie genauso schnell wie Ihre Kollegen in der Anwendung vorankommen, obwohl Ihnen dazu nur deutlich weniger ausgereifte Werkzeuge zur Verfügung stehen.

Es ist, als ob das eine Team einen 3D-Drucker zur Verfügung hat, um ein Haus zu drucken, und das andere Team nur einen Haufen Metallteile erhält, um zuerst den Bagger zusammenzubauen, bevor sie das Loch für das Fundament damit graben können.

Anwendungsframeworks und Plattformframeworks

Die Abstraktionsschicht zwischen Anwendungen und Infrastruktur ist das Betriebssystem. Doch Betriebssysteme sind eine schwache Abstraktion, was dazu führt, dass Anwendungsanforderungen in die Plattformebene durchsickern. Dies führt dazu, dass die Infrastrukturkonfiguration selbst zwischen den verschiedenen Layern der selben Anwendung oft nicht genügend Gemeinsamkeiten hat, damit Plattformteams von wiederverwendbaren Frameworkkomponenten profitieren können.

Container verbessern zwar nicht die Eigenschaften von Betriebssystemen als Abstraktionsschicht, aber sie beheben dieses Problem dennoch, indem sie zwei getrennte Betriebssystem-Instanzen für Anwendungs- und Plattformebene ermöglichen.  Darüber hinaus befindet sich Kubernetes genau an der Grenze zwischen Anwendungs- und Plattformebene und bietet eine robuste API, wodurch Teams klare Verantwortlichkeiten haben und sich nicht gegenseitig behindern.  Die Tatsache, dass damit zum ersten Mal eine starke Abstraktionschicht zwischen Anwendungs- und Plattformebene existiert markiert einen Paradigmenwechsel der es Plattformteams ermöglicht, erstmals ebenfalls von Frameworks zu profitieren.  Ich bin davon überzeugt, dass jetzt nicht nur die Zeit für ein solches Framework gekommen ist, sondern dass dies auch mehr DevOps-Initiativen zum Erfolg verhelfen würde.

Wie kann ein solches Framework Ihrer DevOps-Initiative zum Erfolg verhelfen?

Frameworks sind in der Anwendungsentwicklung allgegenwärtig, weil sie Teams helfen, sowohl bei der Erstellung neuer Anwendungen als auch bei der Wartung dieser Anwendungen schnell Fortschritte zu machen.  Wenn diese Vorteile von Frameworks endlich auch auf der Plattformebene verfügbar wären würde dies verhindern, dass Teams sich ungerecht behandelt fühlen. Auf diese Weise würde das Spielfeld mit der Anwendungsebene ausgeglichen. Die starken Emotionen herauszunehmen würde endlich eine rein rationale Zusammenarbeit ermöglichen und damit die wahrscheinlich größte Ursache von Konflikten beseitigen.

Aber Frameworks, die auf wiederverwendbaren Komponenten basieren, ermöglichen es den Teams auch, diese Komponenten zu verwenden, ohne deren Umsetzung vollständig verstehen zu müssen. Dies ermöglicht den Teams, Fortschritte zu machen, auch wenn die Technologien für sie noch neu ist. Außerdem können die Verwendung des Frameworks und übliche Anwendungsfälle dokumentiert werden. Dies ist eine erstklassige Wissensquelle für Teams, um sich die neuen Fähigkeiten und Kenntnisse anzueignen, die sie benötigen, um den DevOps-Initiativen ihrer Unternehmen zum Erfolg zu verhelfen.  Nicht zuletzt fördern Frameworks eine User-Community von Menschen, die an den gleichen Herausforderungen arbeiten und sich gegenseitig helfen können. Sei es durch den Austausch von Erfahrungen in Form von Blog-Beiträgen und Konferenzvorträgen, durch das Schreiben von Anleitungen und Tutorials oder durch die Verfügbarkeit von spezialisierten Beratern.  Frameworks haben das Potenzial, Ihrer DevOps-Initiative zum Erfolg zu verhelfen, denn sie helfen, zwei der größten Gründe für das Scheitern zu vermeiden.

Erstens, das Gefühl ungerecht behandelt zu werden, weil man die gleichen hohen Erwartungen wie Anwendungsteams erfüllen soll, obwohl die Werkzeuge die man dafür zur Verfügung hat, nicht ansatzweise so ausgereift sind.  Und zweitens die Unsicherheit, ob Sie persönlich Erfolg haben werden. Ein Framework gibt jedem im Team das Vertrauen und die Zuversicht etwas beizutragen, auch wenn sie sich gerade erst in das neue Thema einarbeiten.

Glücklicherweise ist dies mehr als nur Theorie

Wenn Sie jetzt denken, das klingt alles großartig, wenn es ein solches Framework nur gäbe, habe ich gute Nachrichten für Sie.

Ich habe in den letzten anderthalb Jahren an einem solchen Framework gearbeitet. Kubestack ist ein open-source ​GitOps-Framework​ für die Infrastruktur-Automatisierung, basierend auf Terraform und Kustomize. Es wurde für Teams entwickelt, die eine auf Kubernetes basierende Infrastruktur automatisieren wollen und die Automatisierung nicht neu erfinden wollen. Betrachten Sie es vereinfacht so: Kubestack ist für Terraform und Infrastruktur-Automatisierung, was Spring Boot für Java und Cloud-basierte Anwendungsentwicklung ist.

Das Framework unterstützt alle drei großen Cloud-Anbieter und wurde von meinen Kollegen und mir bereits bei einer Reihe von Kundenprojekten verwendet. Kubestack ist vollständig dokumentiert, verfügt über eine umfassende Schritt-für-Schritt-Anleitung, um Benutzern den Einstieg zu erleichtern, und umfasst sogar eine ​lokale GitOps-Entwicklungsumgebung​, ganz wie man sie von Anwendungsframeworks gewohnt ist. So können Sie Kubestack ausprobieren und mehr über Infrastruktur-Automatisierung mit GitOps lernen, ohne dafür erst aufwendig ein Testsystem provisionieren zu müssen.  Für Fragen gibt es einen ​#kubestack-Channel​ auf dem ​Kubernetes-Community Slack​ und die Möglichkeit Issues im GitHub ​Repository​ zu öffnen.

Verwandte Themen:

Geschrieben von
Philipp Strube
Philipp Strube
Philipp ist Cloud-Native, seit er 2008 das Studium abgebrochen hat, um den PaaS Anbieter cloudControl zu gründen und Entwicklern dabei zu helfen schneller bessere Software zu entwickeln. Seitdem hat Philipp an IaaS bei Exoscale und Enterprise Kubernetes bei CoreOS gearbeitet. Zuletzt hat er bei Container Solutions Unternehmen dabei geholfen Cloud Native zu verstehen und einzuführen. Philipp entwickelt das Open-Source Framework Kubestack. Kubestack ist ein GitOps Framework, dass aufbauend auf Terraform und Kustomize Teams dabei hilft Infrastruktur zu automatisieren ohne dabei das Rad neu erfinden zu müssen.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: