Das minimal überlebensfähige Produkt

Warum „Minimum Viable Cloud“ ein Schreckgespenst ist

| Autor / Redakteur: Pierre Gronau* / Florian Karlstetter

Auch keine Lösung! Warum „Minimum Viable Cloud“ ein Schreckgespenst ist erklärt Pierre Gronau in einem Gastbeitrag.
Auch keine Lösung! Warum „Minimum Viable Cloud“ ein Schreckgespenst ist erklärt Pierre Gronau in einem Gastbeitrag. (Bild: Gronau IT Cloud Computing GmbH)

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. Zunächst tippte ich 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 ist mir ein Anliegen zu erklären, was sie bedeutet und warum MVC aus meiner Sicht eine erstaunlich, schreckliche Idee ist: Zunächst ist der Begriff 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 implementieren IT-Architekten einige minimale IdMs (Identitätsmanagement) und Alarmierungen auf Cloud-Ebene sowie eine Menge zusätzliches Gepäck, das von bestehenden Betriebsabläufen eingesammelt wird. Das sind zum Beispiel 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. So funktioniert das nicht, zumindest nicht für längere Zeit: MVC zerstört die Agilität und verstärkt alte, schlechte Gewohnheiten.

Auch wenn Kundige eine ‘freundlichere’ MVC-Implementierung gestalten wollen, 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, sind Architekten 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 Beteiligte dann alle in Konflikt geratenden Kontexte handhaben und sauber voneinander isolieren müssen.

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

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.

Pierre Gronau: Zukunftsberater, Innovationsmanager, Architekt und Sicherheitslotse.
Pierre Gronau: Zukunftsberater, Innovationsmanager, Architekt und Sicherheitslotse. (Bild: Gronau IT Cloud Computing GmbH)

Der Autor

Pierre Gronau ist Gründer und Inhaber der Gronau IT Cloud Computing GmbH mit Firmensitz in Berlin. Seit 20 Jahren arbeitet er für namhafte Unternehmen als Senior IT-Berater mit umfangreicher Projekterfahrung. Zu seinen Kompetenzfeldern gehören Server-Virtualisierungen, moderne Cloud- und Automationslösungen sowie Datensicherheit und Datenschutz.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45228439 / Deployment)