Von 0 auf Level 5

Die Cloud optimal nutzen – ein Quick Guide über die Möglichkeiten von DevOps

Oliver Arafat

© Shutterstock / wacomka

Im Cloud Computing haben sich die Prioritäten von der reinen Migration hin zu einer optimierten Nutzung verschoben. Oliver Arafat, Head of Cloud Solution Architects bei Alibaba Cloud, erklärt, wie Unternehmen von diesem Paradigmenwechsel profitieren und welche Hindernisse es zu bewältigen gilt.

Während die Migration in die Cloud zwar eine fundamentale aber letztlich einmalige Entscheidung darstellt, ist die Optimierung der Cloud beziehungsweise der Ressourcennutzung in der Cloud ein kontinuierlicher Prozess für den es keinen „Quick Fix“ gibt. Die Frage, wie sich die Cloud bestmöglich nutzen lässt, kann nie abschließend beantwortet werden, da ihre Optimierung ein kontinuierlicher Prozess ist. Im Folgenden wird aufgezeigt, wie Möglichkeiten von DevOps in der Cloud jederzeit optimal genutzt werden und Cloud-Umgebungen automatisiert und reproduzierbar gebaut sowie gepflegt werden können – unabhängig davon, ob die Migration erst geplant oder bereits vollständig Cloud-basiert gearbeitet wird.

DevOps als Erweiterung automatisierter Operations & Maintenance (O&M)

DevOps Praktiken unterscheiden sich nach ihrem Automatisierungsgrad. Die O&M Pyramide orientiert sich in der Darstellung an den Autonomiestufen des Autonomen Fahren.

O&M Pyramid; Bildquelle: Alibaba Cloud

  • Für Level 1 (Manual O&M) gilt hierbei, dass sämtliche Aktionen und Reaktionen über die grafische Oberfläche manuell ausgeführt werden.
  • Organisationen in Stufe 2 (Semi-automatic O&M) führen im Gegensatz dazu schon einige (Re-)Aktionen über (mitgelieferte) Tools aus, wie zum Beispiel anhand eines Command Line Interfaces (CLI) welches sich auch für den Einsatz in ersten Skripten zur einfachen Automatisierung kleiner isolierter Tasks einigt.
  • Organisationen in Stufe 3 (High-automatic O&M) haben typischerweise weniger als 50 Prozent ihrer Abläufe automatisiert und verwenden oft selbst-gebaute Tools die stark an die internen Systeme gekoppelt sind und wenig von den darunter liegenden Systemen abstrahieren.
  • Teams in Level 4 (Standardized O&M) haben in der Regel mehr als 90 Prozent aller Abläufe automatisiert und setzen auf plattform-basierte und meist deskriptive Technologien wie das cloud-übergreifende Terraform, um Abläufe und Umgebungen standardisiert zu definieren und auszuführen. Die Logik, wie auf bestimmte Verhaltensweisen und Metriken eines Systems zu reagieren ist, erfolgt dabei jedoch rein regel-basiert. Optimierungen basieren auf menschlicher Ermessensgrundlage.
  • Demgegenüber steht die letzte Stufe 5 (AIOps), wo anhand des Einsatzes von maschinellem Lernen und dem Einsatz großer Datenmengen versucht wird, automatisiert Probleme und Anomalien zu erkennen und darauf adäquat zu reagieren. Cloud-Anbieter wie Alibaba Cloud stellen hierfür schon entsprechende Service-Angebote für ihre Kunden im Bereich der IT-Sicherheit bereit, die durch den Einsatz von spezialisierten Algorithmen Angriffsmuster autonom erkennen und mitigieren können.

Ein zentraler Aspekt bei der Kompatibilität von DevOps ist das sogenannte Templating. Dies kommt insbesondere bei der Verwendung von Standardized Automated O&M in Betracht. Standardized Automated O&M Produkte sind universeller einsetzbar und erreichen einen höheren Abstraktionsgrad. Nicht zuletzt deshalb bieten die meisten Cloud-Plattformen entsprechende Werkzeuge an.  Als Beispiele wären hier AWS Cloud Formation oder Resource Orchestration Service (ROS) von Alibaba Cloud zu nennen. Aber auch Multi-Cloud Werkzeuge wie Terraform finden in der Praxis eine breite Verwendung.

Wird eine entsprechende Plattform verwendet, um Ressourcen zu schaffen, erstellen Nutzer Templates. Die Schaffung neuer Ressourcen erfordert dann nur noch die Anwendung dieser Templates und keine zusätzliche Softwareentwicklung. Ist das Template einmal implementiert, können die Nutzer mit Hilfe einer Versionskontrollsoftware wie beispielsweise Git ein Template genauso effizient verwalten wie ihren Code. Darüber hinaus bieten sich sowohl beim Modifizieren als auch beim Veröffentlichen von Templates Vorteile ähnlich denjenigen aus der reinen Software-Entwicklung wie Reviewing oder Continuous Release. Die Methodiken und Prozesse von automatisiertem DevOps bauen stark auf diesen Pfeilern auf.

Welche Fähigkeiten sollte ein vollständiges DevOps System besitzen?

Setzt man voraus, dass hundertprozentige Automatisierung die ideale Form von DevOps ist, kann das Fehlen jeglicher Prozesse zu einem Hindernis in der Praxis werden. Grundsätzlich umfasst das DevOps O&M acht Phasen. Dazu zählen Plan, Code, Build, Test, Release, Deploy, Operate und Monitor – um letztendlich wieder zur Planung zurückzukehren und den Prozess von Neuem zu starten. An dieser Stelle ist es wichtig zu erwähnen, dass die oben genannten Templates auch über Einstellungen für die Überwachung und Benachrichtigungen verfügen. Dies ist dem Umstand geschuldet, dass es sich bei den Templates stets um Cloud-Produkte handelt, die grundsätzlich APIs bereitstellen. So lassen sich Bereitstellungsvorlagen vereinheitlichen und zentralisieren.

Das DevOps-System von Alibaba Cloud ermöglicht beispielsweise sowohl eine vorlagenbasierte Umgebungsbereitstellung als auch eine vorlagenbasierte O&M-Orchestrierung, die durch den dedizierten Service Operation Orchestration Service abgebildet wird. In der Branche nennt man diesen Modus auch Ops as Code, Automation as Code oder Runbook as Code. Die Produktdesignprinzipien und -ideen sind mit den Bereitstellungsvorlagen der Templates konsistent, so dass detaillierte Arbeitsschritte nicht wiederholt werden müssen.

Hindernisse bei der Implementierung von DevOps

In der Tat ist DevOps kein neues Konzept, jedoch setzen aktuell nur relativ wenige Unternehmen DevOps-Methodiken und Praktiken ein. Die Gründe dafür sind häufig auf Firmenkultur-Ebene zu suchen, liegen aber auch an den Gewohnheiten und den Vorstellungen der IT-Teams. Dabei spricht vieles für den Einsatz von DevOps. Die Vorbehalte – wenn man es so nennen möchte – gegenüber DevOps sind darin begründet, dass ein typisches DevOps Modell viel Planung und Einschätzungen hinsichtlich künftiger Entwicklungen erfordert; lange bevor eine endgültige Entscheidung über deren Einführung getroffen wird. Da sich jedoch niemals genau vorhersagen lässt, wie sich unsere Welt entwickelt, werden auch die erwähnten Planungen und Einschätzungen nie exakt ein- beziehungsweise zutreffen und eine stetige Anpassung von Prozessen im Zuge von DevOps erforderlich machen.

Auch finanzielle Einschränkungen sind mitunter fatal für die Entwicklung von DevOps. Die Buchhaltung eines Unternehmens erwartet Planbarkeit, die jedoch kontraproduktiv ist für ein Modell der flexiblen Erstellung und Freigabe von Ressourcen in der Cloud. Aus Sicht der Finanzexperten in den Unternehmen mag Planbarkeit zwar kosteneffektiver sein, aus der Sicht von DevOps O&M-Entwicklern ist jedoch eine bedarfsorientierte Lösung mit automatischer Skalierung zu bevorzugen. So bleibt abschließend festzuhalten, dass es vor allem an den Finanzabteilungen in den Unternehmen ist, die Bedürfnisse der Software-Architekten in den IT-Abteilungen zu berücksichtigen und ihnen mehr finanziellen Spielraum zu geben. Denn nur so können Unternehmen von den Möglichkeiten, die ihnen DevOps bieten kann, profitieren.

Verwandte Themen:

Geschrieben von
Oliver Arafat

Oliver Arafat ist Head of Cloud Solution Architects bei Alibaba Cloud.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: