Die überraschende Wahrheit über die digitale Transformation: Cloud-Chaos

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Dies ist der zweite Blogbeitrag einer Reihe über die Herausforderungen der digitalen Transformation.

• Die überraschende Wahrheit über die digitale Transformation

Cloud-Chaos.

Irgendein cleverer Ingenieur merkt gerade an, dass diese Formulierung redundant ist. Schließlich ist die Cloud das reinste Chaos: Es mangelt an Governance, und bei der Absicherung von Anwendungen, die ohne klar definierten Zeitplan in ihre flauschig weißen Tiefen geworfen werden, herrscht eine Laissez-faire-Mentalität.

Halten wir hier kurz fest, dass das mit der Cloud verbundene Chaos meist ein Problem der Menschen und Prozesse ist und kein technisches.

Das soll nicht heißen, dass die Cloud keine technischen – oder zumindest architektonischen – Herausforderungen mit sich bringt. Einige davon hängen mit der Komplexität virtueller Netzwerke zusammen. Die meisten sind jedoch architektonischer Natur. Eine dieser architektonischen Herausforderungen ergibt sich aus dem Wesen der Cloud selbst und ihrem anwendungsbezogenen Fokus.

Wenn man darüber nachdenkt, gelten die Public Cloud und ihr Bereitstellungsmodell als die ideale (die von Platonikern sogenannte „Form der Cloud“) Form der Cloud. Das bedeutet, dass auch die Private Cloud ihren Grundsätzen folgen und dieselben Merkmale aufweisen sollte.

Das bedeutet APIs und Self-Service-Bereitstellung. Dashboards und webbasierte Konsolen. Es bedeutet aber auch einen architektonischen Wandel hin zu einer Bereitstellung, die ausschließlich auf eine einzige Anwendung ausgerichtet ist.

Anwendungsbezogene Architekturen sind in der Cloud die Norm. Dienste werden so bereitgestellt und konfiguriert, dass sie jeweils eine einzelne Anwendung unterstützen und einen durchgängigen Datenpfad vom Benutzer bis zum Endpunkt schaffen, der diese Dienste durchläuft. Dies steht in starkem Gegensatz zum traditionellen Netzwerkdesign von Rechenzentren, bei dem ein erheblicher Teil der Netzwerk- und Anwendungsdienstinfrastruktur gemeinsam genutzt wird.

Das Konzept einer „gemeinsam genutzten Infrastruktur“ wird in einer DevOps- und agilen Entwicklungswelt, die ebenso stark auf einzelne Anwendungen ausgerichtet ist wie die Public Cloud, zur Herausforderung.

Herkömmliche Netzwerke mit gemeinsam genutzter Infrastruktur führen dazu, dass es „nur einen einzigen Weg vom Eingang bis zur Anwendung“ gibt. Dieser Ansatz bringt in der heutigen schnelllebigen digitalen Welt folgende Herausforderungen mit sich:

• Abstimmung der Infrastrukturversionen. Eine Anwendung benötigt möglicherweise Funktionen, die durch ein Upgrade oder einen Patch bereitgestellt werden, während eine andere auf die vorhandene Version angewiesen ist. Eine gemeinsam genutzte Infrastruktur lässt in der Regel keine unterschiedlichen Versionen auf demselben System zu und kann daher eine Anwendung zugunsten einer anderen beeinträchtigen.
• Widersprüchliche Bereitstellungszeitpläne. Wenn gemeinsam genutzte Ressourcen betroffen sind, beginnt in Unternehmen eine Verhandlungsphase, in der die Anwendungsverantwortlichen versuchen, Konflikte bei den Bereitstellungszeitplänen zu lösen. Dieser Prozess kann langwierig sein (und ist immer mühsam), und niemand gewinnt, wenn eine neue Anwendung oder ein Update aufgrund von Terminkonflikten zurückgehalten wird.
• Auswirkungsradius. Es versteht sich von selbst, dass bei einem durch meine Anwendung verursachten Ausfall eines gemeinsam genutzten Systems auch jede Anwendung ausfällt, die auf dieses System angewiesen ist. Der Auswirkungsradius gemeinsam genutzter Infrastruktur ist enorm und trägt wesentlich dazu bei, dass Unternehmen zögern, Personen außerhalb der IT-Abteilung umfassenderen Zugriff auf die Bereitstellungspipeline zu gewähren.
• Fehlerbehebung. Das Durchforsten aggregierter Protokolle ist mühsam. Sehr erfolgreiche Unternehmen wurden allein auf der Fähigkeit aufgebaut, riesige Protokolldatenmengen auszuwerten und die Daten wieder in anwendungsspezifische Abläufe aufzuschlüsseln. Die Fehlerbehebung bei gemeinsam genutzten Systemen ist kompliziert und zeitaufwendig und wirkt sich negativ auf die mittlere Lösungszeit aus, eine entscheidende Kennzahl für moderne IT-Abteilungen.

In der Cloud stellt all dies normalerweise kein Problem dar. Für jede App gibt es einen eigenen Pfad, da Apps in der Regel nach ihrem eigenen Zeitplan in ihrer eigenen Umgebung bereitgestellt werden – häufig von unterschiedlichen Teams.

Um unsere Nerven (und unser Rechenzentrum) zu schonen, müssen wir diesen Ansatz auch lokal übernehmen – unabhängig davon, ob es sich um eine Private Cloud handelt oder nicht.

Gemeinsam genutzte Netzwerkdienste wird es weiterhin geben. Firewalls, IPS/IDS, DDoS-Schutz und Benutzerüberprüfung sind weitgehend anwendungsunabhängig und können (und sollten) unternehmensweit eingesetzt werden. Für alles andere gibt es anwendungsspezifische Dienste und Infrastrukturen. Diese logische Trennung gewährleistet die Stabilität und Sicherheit des Unternehmens und ermöglicht zugleich eine dynamischere und möglicherweise instabilere Umgebung in unmittelbarer Nähe der Anwendungen. Außerdem bleibt so ein Datenpfad für traditionelle (ältere und historisch gewachsene) Anwendungen erhalten, die nicht die Geschwindigkeit und Unterstützung benötigen, die für neuere Anwendungen erforderlich sind. Das anwendungsspezifische Netzwerk kann eine Private Cloud, mehrere Container-Cluster oder eine Kombination daraus sein.

Die Verbindung beider Ansätze führt zu einem stabileren, widerstandsfähigeren Netzwerk, das zugleich flexibel und schnell ist.

Ein anwendungsspezifischer Netzwerkansatz bietet neben der Behebung der Probleme, die durch einen gemeinsam genutzten Ansatz in Verbindung mit modernen Anwendungsarchitekturen und Bereitstellungsmodellen entstehen, eine Reihe von Vorteilen:

• Individuelle Pipelines und Zeitpläne. Ich kann meine eigenen Bereitstellungen einplanen, sobald sie bereit sind, da sie keine anderen Anwendungen oder Infrastrukturen als meine eigenen betreffen. Dies bietet die nötige Flexibilität, um die unterschiedlichen Zeitpläne zu unterstützen, die in einem modernen Rechenzentrum berücksichtigt werden müssen.
• Begrenzter Auswirkungsbereich. Wenn mein Deployment auf meinen dedizierten Systemen einen Absturz verursacht, liegt die Verantwortung allein bei mir. Andere Anwendungen sind davon nicht betroffen. Dieser dedizierte Datenpfadansatz pro Anwendung erleichtert zudem die Fehlerbehebung, da ich sicher sein kann, dass sich die Protokolle und Fehlermeldungen auf allen Systemen auf mich und meine Anwendung beziehen.
• Die Skalierung ist nicht auf die Ressourcen der Plattform beschränkt. In einer äußerst volatilen, dynamischen Welt lässt sich kaum vorhersagen, wann der nächste Besucheransturm kommt, ob Inhalte plötzlich viral gehen oder ob Sie – Gott bewahre – angegriffen werden. Unabhängig von der Ursache ist die Skalierung bei Nachfragespitzen für Anwendungen auf gemeinsam genutzten Systemen (Hardware oder Software) auf die verfügbaren Plattformressourcen beschränkt. Eine anwendungsspezifische Architektur verringert diese Einschränkung und ermöglicht es, einzelne Komponenten bei Bedarf horizontal zu skalieren, um die Nachfrage zu bewältigen.
• Unterstützt ein echtes Infrastructure-as-Code-Modell. Gemeinsam genutzte Systeme verwenden gemeinsame Konfigurationen, selbst wenn es sich nur um eine Basiskonfiguration mit anwendungsspezifischen Richtlinien handelt. Dieses Modell kann beim Versuch, ein Infrastructure-as-Code -Modell zu implementieren, für Chaos sorgen, insbesondere wenn mehrere Anwendungen gleichzeitig Aktualisierungen vornehmen. Änderungen können sich ohne Vorwarnung auf andere Anwendungen auswirken, oder Commit- und Klonvorgänge können fehlschlagen, weil andere Ressourcen sperren, wenn Sie sie benötigen. Eine anwendungsspezifische Architektur stellt sicher, dass Bereitstellungsartefakte nur zu einer einzigen Anwendung gehören und von den Anwendungsverantwortlichen (ob Entwicklung, DevOps, NetOps oder ) ordnungsgemäß verwaltet werden können.

Eine anwendungsspezifische Architektur kann zwar nicht jedes Problem lösen, das durch die digitale Transformation entsteht, aber sie kann wesentlich dazu beitragen, das durch die Cloud verursachte Chaos zu bändigen. Sie bietet bessere Möglichkeiten zur Standardisierung der Sicherheit und unterstützt zugleich die Multi-Cloud-Umgebungen, zu denen sich die meisten Unternehmen entwickeln.

Bleiben Sie dran für den nächsten Beitrag dieser Reihe. Darin gehen wir näher darauf ein, wie Sie mit denjenigen umgehen können, die aufgrund des durch die digitale Transformation entstehenden Markteinführungsdrucks die Sicherheit vernachlässigen.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie