Modernes DevOps ohne Infrastructure as Code (IaC) ist kaum möglich. In DevOps (Development und Operations) harmonisieren die beiden klassischen IT-Aufgaben Entwicklung der Software und Administration der Infrastruktur. In DevOps kann man beides nicht mehr voneinander trennen. Die alte klassische Vorgehen mit der klaren Trennung zwischen der IT-Administration, die Sie sich um den Kauf und den Betrieb der Infrastruktur kümmerte, und der Entwicklung, die für die Software oder Lösung (Solution) verantwortlich ist, verschmelzen.

Das Deployen neuer Releases war früher mit einem hohen zeitlichen Aufwand verbunden. Der Download, das Bauen, das Testen und das Ausliefern neuer Releases für die klasssichen Umgebungen Entwicklung, Staging (Abnahme) und Produktion hatte je nach System eine umfangreiche Anzahl an Schritten zur Folge.

Schritte bei einem Releasewechsel

Ein Releasewechsel bedeutet im allgemeinen

1. Umbau der Releaseumgebung im lokalen System, d.h. Download der neuen Releases, Anpassung der Konfiguration, Update einer Datenbank, Anpassung ergänzender Module wie WebProxy (Apache, Nginx), Docker usw.

• Umbau der Stagingumgebung, d.h. Wegwerfen der alten Infarstruktur, manueller Neuaufbau der neuen Infrastruktur mit den geänderten Releases, Konfigurationen, Datenbanken, zusätzlichen Modulen
• Funktions-, Performanz- und Integrationstests auf der Stagingumgebung mit späterer Abnahme
• Wenn Abnahme nicht erfolgt, Wiederholen vom ersten Schritt an, mit den notwendigen abnahmeverhinderten Änderungen
• Wenn Abnahme erfolgt, Umbau der Produktivumgebung, d.h. Wegwerfen der alten Infrastruktur, manueller Neuaufbau der neuen Infrastruktur mit den geänderten Releases, Konfigurationen, Datenbanken, zusätzlichen Modulen
• Funktions-, Performanz- und Integrationstests in Produktion vor Freigabe an den Kunden
• Wenn bereits vor der Freigabe in Produktion Probleme auftreten beginnt man wieder von Anfang an

Diese Darstellung der einzelnen Schritte stellt sicherlich ein theoretisches Konstrukt dar, das im Zuge agiler Vorgehensweisen auch veränderbar sind. Faktisch ist es aber so, dass auch agile Methoden diese Schritte implizit mit umfasst, diese sind nur mit in den Entwicklungsprozess integriert.

Effective DevOps ist heute kaum mehr aus der modernen IT wegzudenken. Die alten Konzepte basieren häufig auf monolithischen Applikationen in der sich dann eine oder mehrere Personen als Experte(n) auskannten. Die Auseindersetzung mit den klassischen onPremises-Architekturen, wie Server, Netzwerke und Firewalls usw. war häufig nicht notwendig, da sich die klassischen Administratoren darum kümmerten. Die meisten Monolithen hatten einen großen Nachteil. Diese konnten nur vertikal Skalieren, d.h. bei Ressourcen- oder Performanzproblemen wurde das Problem mit noch größeren Maschinen gelöst. Dies bdeutete mehr CPU, mehr RAM, mehr Speicher. Jede Erweiterung bedeutete einen hohen zeitlichen Aufwand durch Abstimmung, Klärung der Kostenübernahme, Bestellung, Lieferung, Einbau und Installation/Migration.