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 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.

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.

Um eine MongoDB auf Geschwindigkeit zu bekommen ist das Thema Ressourcen nicht zu unterschätzen. Zum Beispiel: In der BestPractice benötigt man im Sharding (d.h. die Verteilung der Daten auf verschiedene Knoten in einem Cluster) eine Computereinheit je Knoten („Shard“). Wenn man noch eine Replikation einplant, so kommt man schnell auf eine nicht unerhebliche Anzahl von Computereinheiten. Abbildung: Beispiel einer hochverfügbaren MongoDB Architektur mit drei Zonen, drei Replikation-Sets zwei Konfigurations Servern, zwei Routern und ein Applikationsserver für Compass und den Opsmanager auf AWS-Instanzen

Ein großer Vorteil der MongoDB ist ihre Schemafreiheit. Mit Schemafreiheit ist gemeint, dass eine Datenbank nicht vorher langwierig „modelliert“ werden muss, wie bei einer „normalen“ SQL-Datenbank. Das Anlegen von Tabellen mit Attributen und Typen (Textwerte, Kommazahlen, Ganzzahlen usw.) entfällt bei der MongoDB. Zwar kennt auch die MongoDB Tabellen („collections“), diese werden aber dynamisch per Import eines JSON-Dokuments angelegt. Theoretisch ist es daher möglich in die gleiche Collection JSON-Dokumente von unterschiedlichster Struktur ohne irgendeine Vorbereitung abzulegen.