Da Unternehmen DevOps für die kontinuierliche Entwicklung, Bereitstellung und Integration von Geschäftsfunktionen nutzen, ist eine sorgfältige Steuerung unerlässlich.
Unternehmen verabschieden sich von der traditionellen Wasserfall- und Kaskaden-Softwareentwicklung, bei der Code über definierte Zeiträume hinweg erstellt und mit der Verwaltung von Betriebssystemen und Anwendungen kombiniert wird, und setzen stattdessen auf agilere Ansätze.
Angesichts des steigenden Bedarfs an schneller funktionaler Bereitstellung durch Continuous Integration, Continuous Development und Continuous Delivery (CI/CD) erwägen viele Unternehmen die Einführung eines DevOps-Prozesses.
DevOps zielt darauf ab, Entwicklungs-, Test- und Betriebsteams zusammenzubringen, um den Austausch von Code und funktionalen Anwendungen zwischen diesen drei Bereichen zu optimieren.
Der Prozess erfordert jedoch ein hohes Maß an Kontrolle mit den richtigen Feedbackschleifen, um einen reibungslosen Ablauf zu gewährleisten und den größtmöglichen Nutzen für das Unternehmen bei minimalen negativen Auswirkungen zu erzielen.
Entwicklergesteuerter Wechsel
Das Problem für Unternehmen besteht darin, dass DevOps rasant wächst – und zwar von unten nach oben, anstatt von oben nach unten gesteuert zu werden.
DevOps zielt darauf ab, Entwicklungs-, Test- und Betriebsteams zusammenzubringen, um den Austausch von Code und funktionalen Anwendungen zwischen diesen drei Bereichen zu optimieren. Viele DevOps-Tools sind als Open-Source-Software verfügbar – es gibt also keine Hürden für einzelne Mitarbeiter, ein Tool ihrer Wahl herunterzuladen und sofort einzusetzen.
Für viele Entwickler und Betriebsmitarbeiter ist dies eine zu gute Gelegenheit, um sie auszuschlagen. Entwickler suchen schon lange nach nachgelagerten Systemen, die sie in ihre bestehenden integrierten Entwicklungsumgebungen (IDEs) integrieren können, seien es kommerzielle Systeme wie IBM Rational Software Architect oder Microsoft Visual Studio oder Open-Source-Systeme wie Eclipse oder Anjuta, oder Software-Projektmanagement-Software wie Atlassian Jira Software oder CA PPM.
Dies hat zu einer verstärkten Nutzung von [Tools wie Jenkins]( geführt.https://searchitoperations.techtarget.com/tip/Secure-Jenkins-for-fast-and-safe-app-deliveryChef und Puppet werden von Entwicklern und Betriebspersonal eingesetzt. Jenkins bietet automatisierte Prozesse für die Softwareversionierung – inklusive Plugins für gängige Versionsverwaltungssysteme wie Perforce, CVS, Subversion, Git und Accurev – sowie optimierte Prozesse für Continuous Delivery. Chef und Puppet konzentrierten sich ursprünglich stärker auf den Betriebsbereich (Ops) von DevOps und nutzten Konfigurationsmanagement-Prinzipien, um Funktionspakete zu erstellen, die anschließend automatisch in der Betriebsumgebung bereitgestellt werden können.
Erweiterte Optionen
Die Leistungsfähigkeit dieser Tools hat sich seit ihrer Markteinführung 2005 (Puppet), 2009 (Chef) und 2011 (Jenkins, im Wesentlichen eine Weiterentwicklung des Hudson-Projekts von Sun aus dem Jahr 2004, heute Oracle) deutlich verbessert.
Ihre Funktionen überschneiden sich heute viel stärker als noch vor wenigen Jahren, und der Bedarf an zusätzlichen Einzeltools für eine vollständige DevOps-Umgebung ist deutlich geringer.
Die verstärkte Unterstützung von Teamarbeit und umfassenden Feedbackschleifen führt dazu, dass die ursprünglich als Einzelnutzer-Tools konzipierten Lösungen nun Gruppen umfassend unterstützen – selbst über verteilte Standorte und unternehmensübergreifende Teams wie Freelancer und Berater.
Neben diesen drei Branchenriesen gibt es weitere Tools unter verschiedenen Open-Source-Lizenzen, die denselben Anwendungsbereich abdecken, wie beispielsweise Ansible und Salt, sowie in Container-Management-Systeme wie Docker und Kubernetes integrierte Tools. Für einen in Ubuntu integrierten, unternehmensweiten Ansatz bietet Canonical seine eigene Distribution von **[Kubernetes via JuJu](https://www.computerweekly.com/blog/Open-Source-Insider/AppScale-FastStart-for-Google-Compute-Engine-AWSKubernetes entwickelt sich rasant zu einer treibenden Kraft im Bereich der Container-Orchestrierung und ist in DevOps-Umgebungen einsetzbar. Es wird von der Cloud Native Computing Foundation (CNCF) unterstützt, deren Mitglieder unter anderem Amazon Web Services (AWS), Google, Microsoft, IBM, Intel und Twitter sind.
Cloud Foundry ist ein weiteres Open-Source-System, das – wie die meisten der genannten Open-Source-Tools – auch als kommerziell unterstützte Version erhältlich ist. Es bietet Automatisierungsfunktionen, die sich ideal für DevOps eignen und umfassende Unterstützung für vorgelagerte und nachgelagerte Systeme gewährleisten. Obwohl Cloud Foundry ebenfalls Mitglied der CNCF ist, gibt es zwar Überschneidungen mit Kubernetes, sein Anwendungsbereich geht jedoch weit über containerisierte Umgebungen hinaus. Ein separates Projekt innerhalb von Cloud Foundry, KuBo (Kubernetes on BOSH), bietet einen integrierten Cloud Foundry/Kubernetes-Stack für die Arbeit mit heterogenem Anwendungscode, virtuellen Maschinen (VMs) oder Containerumgebungen.
Zu viele Tools
Wenn Entwickler und Systemadministratoren eigene Wege gehen und dadurch eine Vielzahl unterschiedlicher Tools in der IT-Umgebung zum Einsatz kommt, kann dies für Unternehmen problematisch werden. Es gibt zwei Lösungsansätze:
Erstens: Vorgaben machen. Man legt ein einheitliches Toolset fest und gibt klare Regeln vor – alle Entwickler und Systemadministratoren müssen dasselbe verwenden. Leider ist dieser Ansatz zum Scheitern verurteilt. Schließlich haben Sie es hier mit Entwicklern und Systemadministratoren zu tun. Schauen Sie sich nur einmal die Schublade ihres Schreibtisches an: Dort finden sich unzählige CDs und USB-Sticks mit nicht genehmigter Software, die sie im Alltag nutzen. Sie mögen zwar die Notwendigkeit eines einheitlichen Tools befürworten, aber sobald Sie nicht mehr hinschauen, arbeiten sie wahrscheinlich wieder nach ihren eigenen Vorstellungen.
Unternehmen wiegen sich dann in falscher Sicherheit: Nachdem sie alle angewiesen haben, ihren Anweisungen zu folgen, gehen sie davon aus, dass diese auch gelten. Dann geht etwas schief, und die forensische Nachanalyse des Vorfalls deckt die Probleme auf: unzusammenhängende Funktionsinseln ohne einheitliche Kontrollmechanismen.
Zweitens: Seien Sie pragmatisch: Akzeptieren Sie, dass es bereits zu spät ist, die Fehler zu beheben, und finden Sie einen Weg, aus dem chaotischen Sammelsurium individuell genutzter Tools eine unternehmensgerechte Lösung zu entwickeln.
Viele Open-Source-Tools können dank der zunehmenden Verwendung von Plug-ins oder offenen Programmierschnittstellen (APIs) Eingaben von anderen Open-Source-Tools mit angemessener bis hoher Genauigkeit verarbeiten.
Wenn ein höheres Maß an Kontrolle und umfassender Support für Unternehmen erforderlich sind, bietet ein Abonnement mit vollem Support für eine der Open-Source-Software-Distributionen – wie beispielsweise CloudBees mit seiner Unterstützung für Jenkins und seinen zusätzlichen Komponenten – die gewünschte „Unternehmensfähigkeit“.
Offene Systeme bieten Langlebigkeit
Darüber hinaus sind kommerzielle Systeme verfügbar, die ein hohes Maß an Offenheit für die Unterstützung bestehender Tools ermöglichen. Ein Beispiel hierfür ist CA Automic, das einen guten automatisierten Ansatz zur Optimierung von DevOps-Prozessen bietet und gleichzeitig verschiedene zugrundeliegende Tools offen integriert.
Die Möglichkeit solcher Systeme, den Austausch verschiedener zugrundeliegender Tools zu ermöglichen, ist ein entscheidender Punkt: Vor fünf Jahren sprachen nur wenige über **[Chef und Puppet](https://searchitoperations.techtarget.com/tip/How-the-Puppet-architecture-manipulates-configurationsKubernetes wurde erst vor drei Jahren veröffentlicht. Wie wird der Markt in fünf Jahren aussehen? Wenn das übergeordnete System ein geschlossenes System mit festen Verknüpfungen zu definierten Tools ist, könnten Sie den Anschluss verlieren. Ist es hingegen offen und ermöglicht die flexible Integration neuer Tools, können Sie diese bei Bedarf einbinden.
Es gibt zahlreiche weitere Unternehmen im DevOps-Bereich. HashiCorp beispielsweise bietet verschiedene Tools wie Terraform und Vagrant an, die den Betrieb einer DevOps-Umgebung vereinfachen. Perforce hat sein Kerngeschäft der Versionskontrolle erweitert und mit Helix ein breites Spektrum an DevOps-Funktionen auf den Markt gebracht.
Im Bereich der sich weiterentwickelnden Konfigurationsmanagement-Software für ältere Systeme bietet BMC die Automatisierungssuite BladeLogic an. Modernisiert für Cloud Computing und Container, bietet BladeLogic Server Automation – insbesondere in Kombination mit anderen BMC-Produkten wie Atrium Orchestrator, Control-M Automation und dem TrueSight-Portfolio – umfassende DevOps-Funktionalität.
Die modulare Infrastruktur von HPE überbrückt die Kluft zwischen Hardware und Software. Logische Plattformen lassen sich einfach konfigurieren und physische, virtualisierte oder containerisierte Software mithilfe von OneView bereitstellen.
Selbstverständlich gibt es auch Cloud-basierte DevOps-Optionen. IBM bietet über seine BlueMix-Plattform ein breites Spektrum an Funktionen. AWS, Google und Microsoft stellen Tools direkt auf ihren Plattformen bereit, während viele der bereits erwähnten Tools auch per Self-Service auf ihren Cloud-Plattformen implementiert werden können.
DevOps entwickelt sich zu einem wichtigen Instrument, um Unternehmen ihre Wünsche und Bedürfnisse zu erfüllen: die kontinuierliche Entwicklung neuer Funktionen, die bei Bedarf schnell bereitgestellt werden können. Wichtig: Es sollte eigentlich „BusDevOps“ heißen – die Bedürfnisse und Wünsche müssen vom Unternehmen und nicht von den Entwicklern diktiert werden.
Um das volle Potenzial einer solchen BusDevOps-Umgebung auszuschöpfen, sind ausgefeilte Tools erforderlich – und diese lassen sich wahrscheinlich nicht durch präskriptive oder proskriptive Regeln realisieren. Seien Sie pragmatisch: Stellen Sie übergreifende Systeme bereit, die Ordnung in das bestehende Chaos bringen und Entwicklern sowie Systemadministratoren ermöglichen, so zu arbeiten, wie es für sie sinnvoll ist.
Quelle: https://www.computerweekly.com
