Warum "Minimum Viable Cloud" ein Schreckgespenst ist

vPierre Agil / Agile, Cloud, Cloud Computing, Cloud Computing Provider / Cloud Computing Anbieter, DevOps, DevSecOps, Digitale Transformation Leave a Comment

Auch keine Lösung! Warum „Minimum Viable Cloud“ ein Schreckgespenst ist.

Etwa vor einem Jahr hörte ich im Rahmen einer Projektbesprechung erstmals das schreckliche Akronym “MVC“. Mein Kontakt nannte diese Abkürzung wieder und wieder und ich wusste nicht, was sie bedeutete. Ich tippte zunächst auf „Model-View-Controller“, bis ich lernte, dass MVC für “Minimum Viable Cloud” steht. Der Begriff leitet sich von „Minimum Viable Product“, kurz MVP ab, wörtlich ein „minimal überlebensfähiges Produkt“.

Inzwischen läuft  mir diese Abkürzung häufiger über den Weg und es wird Zeit, zu erklären, was sie bedeutet und warum  MVC aus meiner Sicht eine erstaunlich, schreckliche Idee ist: Zunächst ist MVC  an keiner Stelle eindeutig definiert. Dieses schwer fassbare Gespenst wird wie ein Mantra benutzt, um Sorgen bezüglich der Cloud zu beschwichtigen und daraus Beratungsprojekte abzuleiten.

Der allgemeine Konsens scheint zu sein, dass man seine Cloud-Umgebung einmalig vordefiniert und aufbaut, um  dann alle Projekte einfach dorthin zu schaufeln. Typischerweise ist das ein Einzel-Account beim Provider mit ein bis drei virtuellen Netzen (dev/test/prod), und die gesamte Architektur ist wie ein einzelnes Rechenzentrum aufgebaut.

Alle Sicherheitsgruppen, Subnetze und wichtigen Strukturen sind vordefiniert. Diese Implementierungen haben meist eine ganze Reihe virtueller Appliance-Versionen derselben Tools vor Ort im Einsatz. Es gibt durch die Einrichtung und Isolierung der Subnetze viel zu tun und daher implementiert man einige minimale IdMs (Identitätsmanagement) und Alarmierungen auf Cloud-Ebene sowie eine Menge zusätzliches Gepäck, das von bestehenden Betriebsabläufen eingesammelt wird (wie DevOps ohne Ops, weil wir für Ops einen Dienstleister beauftragt haben, den wir nicht ansprechen dürfen, weil das kostenpflichtige Change Requests auslöst).

Das funktioniert nicht, zumindest nicht für längere Zeit:

MVC zerstört die Agilität und verstärkt alte, schlechte Gewohnheiten.

Auch wenn man eine ‘freundlichere’ MVC-Implementierung gestalten will, skaliert diese nicht und bietet nicht die Sicherheitsvorteile eines nativen Cloud-Ansatzes. Mit MVC muss alles, was man implementiert, in ein vorgegebenes Raster passen. Wie in eine Zwangsjacke. Anstatt die Sicherheit an die Anforderungen des konkreten Projekts anzupassen, ist man gezwungen, das Projekt an die Sicherheit anzupassen. Das ist der falsche Weg (Anti-Pattern).

MVC führt typischerweise auch zu vielen Anlagen unterschiedlicher Sicherheits-Kontexte, die dasselbe virtuelle Netz sowie dasselbe Cloud-Konto, beziehungsweise Abonnement oder Projekt gemeinsam nutzen. Viele Berater wählen diese Lösung, weil sie anfangs scheinbar einfacher zu verwalten ist. Tatsächlich aber gestaltet sich der Weg  schwieriger, da man dann alle in Konflikt geratenden Kontexte handhaben und sauber voneinander isolieren muss.

Meine Empfehlung: Folge stattdessen dem nativen Cloud-Muster … was für „Lift and Shift“, also Verschieben,  ebenso funktioniert wie für neue Architekturen.

  • Bei diesem Ansatz arbeiten die Teams für Anwendungs- und Sicherheits-Architektur zusammen und gestalten parallel. Sie passen die Sicherheit an die Anwendung und die Erfordernisse wie KRITIS, eHealth an. Zunächst gibt es viele neue Dinge zu lernen, aber mit der Zeit beschleunigt sich der Lernprozess und Software-Architekten bauen darauf eine Bibliothek relativ standardisierter Architektur-Blaupausen auf.
  • Es ist ratsam, jedes Mal in ein sauberes Konto/Abonnement/Projekt zu implementieren. Dadurch minimiert sich die Anzahl privilegierter Benutzer, die Zugriff auf das Cloud-Konto benötigen, und so vereinfacht sich der Aufbau der Konten. Dieser Ansatz hilft beim Verkürzen von unveränderlichen und idempotenten Implementierungen.
  • Auf diesem Weg entsteht eine isolierte Umgebung, die innerhalb exakt definierter Bedingungen arbeitet. Das verringert Komplexität und schafft Sicherheit.
  • Folge: Es erhöht eine andere Art der Komplexität: die Verwaltung all dieser unterschiedlichen Umgebungen. Es gibt Organisationen, die heutzutage Tausende Cloud-Konten verwalten. Die Verwaltung verschiebt sich zu Automation, Deployment Pipelines und dem Erhalt der Sicherheitsabgrenzungen über die Konten. Die Alternative ist Komplexität innerhalb eines Kontos, die häufig zu Konflikten und schwierig durchzusetzenden Sicherheitsgrenzen führt.

Und nun kommt das Entscheidende:

Ich behaupte nicht, dass die Verwaltung nativer Cloud-Implementierungen einfacher ist, aber sie verschiebt das Management in eine Richtung, die die inhärente Sicherheit verbessert. So entstehen stärkere Schutzwälle und eine engere Kontrollausübung. Im Gegenzug stehen  Automatisierung, neue Administrationstechniken und die Einführung neuer Werkzeuge. Ich nenne es das Sicherheits-Trio oder meinen Lieblingsdreiklang bei Sicherheit: P – P – P  für Product, People, Process.

MVC scheitert auf lange Sicht – und zwar immer.

Projekte erreichen unausweichlich einen Punkt, an dem sich zu viele Dinge – quer über zu viele kollidierende Sicherheitskontexte – eine einzelne Implementierung teilen. Es scheint am Anfang einfacher, aber eher als man denkt, müssen Beteiligte  Kompromisse bei der Sicherheit eingehen. Außerdem bremst MVC die Fähigkeit, die Sicherheit für jedes einzelne Projekt richtig zu gestalten und auf das passende Niveau zu heben. Warum? Weil die Anwendungen auf einen vorkonfigurierten Satz von Regeln beschränkt sind.

Der Cloud steht eine Phase massiver Veränderungen bevor.

Besagte Phase ist sogar größer als die Einführung des Internets in Unternehmen, weil die Cloud eine tiefergehende Umstrukturierung der zugrundeliegenden Architekturen erfordert und erzwingt. Das ist aber auch eine phantastische Chance, aus Beschränkungen der Vergangenheit auszubrechen und so mehr Sicherheit und neue Optionen zu gewinnen.

Die neuen Schwerpunkte liegen auf Ausbildung, Automatisierung und Toolset. Anstatt eine MVC aufzubauen, nehmen sich Gutberatene  ein neues Cloud-Projekt und produzieren neben höherer Sicherheit auch die Möglichkeit, sich langfristig schneller in der Cloud zu bewegen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.