DevSecOps: Moderne Systemarchitekturen mit Microgateways

Inhaltsverzeichnis

Die moderne Softwareentwicklung muss vielen verschiedenen Anforderungen genügen: Funktionen sollen schneller umsetzbar sein, Applikationen müssen skalieren, die Sicherheit soll garantiert sein, die Qualität muss stimmen, und das Ganze bei minimalen Kosten. In diesem Artikel geht es darum, an zwei nicht komplett fiktiven Beispielen zu zeigen, wie und warum die Transformation zu DevSecOps Entwicklerinnen und Entwickler dabei unterstützt, diese unterschiedlichen Anforderungen zu erfüllen.

Beispiel 1: Zum Erfolg gezwungen

Der Anbieter einer SaaS-Lösung findet sich völlig überraschend in der Situation, dass sein bestehendes Angebot einen zwar sehr großen, aber nach Ländern segmentierten Kunden gewinnen konnte. Die Herausforderung besteht darin, die Lösung von fünf Kundeninstanzen auf 100 hochzuskalieren und diese Instanzen nun auch global zu verteilen.

Viele moderne Applikationsarchitekturen gehen davon aus, dass die Mandantenfähigkeit ein integraler Bestandteil der Architektur ist und dass es gut und richtig ist, wenn alle Kunden sich eine hochskalierende Instanz der Applikation teilen. In diesem Fall führten die folgenden Gründe zu einem bewussten Verzicht auf eine zentralisierte Lösung:

• Gesetz: Die Trennung der Mandanten in eigene Instanzen erlaubte es, länderspezifische gesetzliche Anforderungen deutlich einfacher zu erfüllen.
• Sicherheit: Die Trennung der Mandanten in eigene Instanzen diente als Verkaufsargument und führte zu einer hohen Kundenakzeptanz.
• Softwarearchitektur: Die Architektur der Software führte zu einer Vereinfachung.
• Individuelle Anpassungen: Die Lösung musste ein sehr flexibles White Labeling anbieten, und das war in separaten Instanzen einfacher und günstiger umzusetzen.

Hürden und Entscheidungsfindung

Die bestehende Plattform basierte auf einer im eigenen Rechenzentrum gehosteten Virtualisierungslösung. Gewisse Komponenten wie die Web Application Firewall teilten sich alle Kundeninstanzen, aber die Applikationskomponenten jeder Kundeninstanz liefen auf eigenen, virtualisierten Rechnern.

Ein erster Anlauf bestand in dem Versuch, die bestehende virtualisierte Lösung zu skalieren. Schnell war jedoch ersichtlich, dass die fehlende Automatisierung und der enorm hohe Ressourcenverbrauch der Virtualisierung die ambitionierten Projektziele unerreichbar machten und auch den wirtschaftlichen Erfolg des Projekts gefährdeten.

Aus der Not entstand ein kühner Plan: Nicht mehr das eigene Rechenzentrum sollte die Plattform betreiben, sondern sie sollte in die Cloud umziehen. Als zweite Umstellung sollte das Ausrollen der Applikation selbst als Container erfolgen.

Umzug in die Cloud

Die Entscheidung, die neue Plattform vollständig in der Cloud aufzubauen, erwies sich als richtig. Aus Sicht der Kosten fand eine Verlagerung von Investitionskosten zu einem Service-Preis statt, der automatisch mit der Nutzung durch die Kunden skalierte und sich so transparent verrechnen ließ. Durch die Wahl eines geeigneten Cloudanbieters war es sehr einfach, für den globalen Großkunden lokale Instanzen anzubieten. Der nun rund um die Uhr sicherzustellende Betrieb erforderte die Rekrutierung von zusätzlichem Personal. Dank der bereitstehenden Tools der Cloud-Plattform und dem hohen Automatisierungsgrad erhöhte sich der Betriebsaufwand jedoch nur moderat. Der Umzug in die Cloud führte sogar zu Einsparungen, weil Aufbau und Wartung der Hardware- und Netzwerkinfrastruktur jetzt eingekauft und nicht mehr von eigenen Mitarbeitern zu leisten waren.

Neben der Plattform erhielt auch die Applikation eine Überarbeitung, indem sie die Migration von einem traditionellen Installer-Modell auf Container erfuhr. Das Ziel war, einen hohen Automatisierungsgrad zu erreichen, um die massiv gewachsene Anzahl von Instanzen mit der gleichen Anzahl von Mitarbeitern betreiben und warten zu können. Auch die eng getakteten Terminpläne für die Auslieferung der neuen Instanzen an die Kunden hätten ohne Automatisierung nicht eingehalten werden können.