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.

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

Weiter →

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. Dies ist etwas, was in einer relationalen (SQL-) Datenbank praktisch unmöglich ist. Hier müsste die Tabelle in die hineingeschrieben werden soll, erst noch vorher erweitert werden.

Die ZF in Friedrichshafen AG ist ein weltweit aktiver Technologiekonzern aus der Automotivebranche und einer der größten Automobilzulieferer der Welt. Lag der Schwerpunkt vor allem auf Motoren, Lenkungssysteme und Getriebe für die Straßen- und Luftfahrzeuge sowie Schiffe ist ihr Portfolio um das Thema Autonomes-Fahren erweitert worden.

Datenmanagement für die ComputerVision

Für das Autonome Fahren sind kamerabasierte Fahrassistenzsysteme (Advanced Driver Assistance Systems - ADAS) sehr wichtig. YOTRON unterstützte das Entwicklerteam für kamerabasierte Assistenzsysteme mit ihrem KnowHow beim Datenmanagement.