DevOps

Bei DevOps handelt es sich um eine Kombination aus klassischer Software-Entwicklung (Development) und dem Betrieb von Computersystemen (Operations).
Dank einer Leseprobe am Kindle konnte ich Einblick in das gleichnamige Buch erhalten:

Laut Inhaltsverzeichnis befassen sich von über 400 Seiten gerade Mal vier mit DevOps selber – den Rest nehme hauptsächlich (agile) Entwicklungsmethoden ein.
Die Kernaussage der vier Seiten ist, dass Development und Operations als zusammengehöriges "Deployment" definiert wird.
Ein dritter Teil der hier noch hineinspielt ist die Qualitätssicherung. Nach dem Inhaltsverzeichnis überwiegt aber trotzdem Development (oder es wird QS einfach als Teil von Dev betrachtet).
Dann werden noch die bisherigen Vorurteile und Klischees bedient – übersetzt in etwa (gekürzt):

• Dev interessiert sich meist kaum für die Auswirkungen ihres Codes auf Ops. Sie verteilen ihren Code ohne Ops in Architekturentscheidungen miteinzubeziehen.
• Dev kommunizieren nötige Konfigurationsänderungen nicht ausreichend.
• Dev verwenden Konfigurationsänderungen auf ihren lokalen Maschinen, dokumentieren diese aber nicht ausreichend fürs Produktivsystem. Daher ist es schwierig, diese Änderungen ins Produktivsystem zu bekommen.
• Devs verwenden Tools für schnelle Entwicklungen: für schnelle Reaktion auf Code-Änderungen, für niedrigen Speicherverbrauch, etc. Die Werkzeuge sind aber sehr unterschiedlich zu dem was in einem Produktivsystem zur Verfügung steht.
• Devs arbeiten auf ihren Desktops. Aber Ops muss den Code auf Server-Betriebsysteme verteilen.
• Verteilte Systeme lassen sich am Desktop kaum abbilden.
• Dev wird von funktionalen Anforderungen getrieben, die normalerweise direkt mit der Geschäftslogik zusammenhängenOps werden von nicht funktionalen Anforderungen getrieben wie Verfügbarkeit, Stabilität und Performance
• Ops versucht Risken zu reduzieren indem Änderungen vermieden werden
• Werden laufende Änderungen vermieden, aber die Menge an Änderungen bleibt konstant, dann wird jede Änderung größer
• Größere Änderungen bedeuten mehr Risiko
• Ops kann sich nicht der nötigen Umgebung bewusst sein, weil sie die Interna des Codes nicht kennen
• Dev kann den Code nicht optimal an die Produktivumgebung anpassen, weil sie diese nicht genau kennen

Die Verwendung agiler Methoden, für jedes einzelne Projekt, bedeutet, dass sich nicht verschiedene Software-Projekte einen Server teilen können. Das kann nur mehr mit massiver Virtualisierung und Automatisierung funktionieren.