Die überraschende Wahrheit über die digitale Transformation: Wolkenchaos

Dies ist der zweite Blog einer Reihe über die Herausforderungen, die sich aus der digitale Transformation ergeben.

• Die überraschende Wahrheit über die digitale Transformation

Wolkenchaos.

Irgendein kluger Ingenieur bemerkt gerade, dieser Satz sei überflüssig. Schließlich herrscht in der Cloud Chaos, da es an Governance mangelt und die Apps ohne klar definierten Zeitplan und unter Laissez-faire-Ansatz in ihre flauschigen weißen Tiefen geworfen werden.

Halten wir hier inne und weisen darauf hin, dass das mit der Cloud verbundene Chaos meist ein menschliches und prozessbezogenes und kein technisches Problem ist.

Das heißt jedoch nicht, dass mit der Cloud keine technischen – oder zumindest architektonischen – Herausforderungen verbunden sind. Einige davon hängen mit der Komplexität virtueller Netzwerke zusammen. Die meisten sind jedoch architektonischer Natur. Eine dieser architektonischen Herausforderungen hängt mit der Natur der Cloud und ihrem Fokus auf einzelne Anwendungen zusammen.

Wenn Sie darüber nachdenken, gelten die öffentliche Cloud und ihr Bereitstellungsmodell als die ideale Form der Cloud (die „Form der Cloud“, wie Platoniker sie nennen würden). Dies bedeutet, dass auch die private Cloud diesen Grundsätzen folgen und dieselben Eigenschaften aufweisen sollte.

Das bedeutet APIs und Self-Service-Bereitstellung. Dashboards und webbasierte Konsolen. Es bedeutet aber auch eine architektonische Umstellung auf eine Bereitstellung, die ausschließlich auf eine einzelne Application ausgerichtet ist.  

In der Cloud sind Pro-App-Architekturen die Norm. Dienste werden bereitgestellt und konfiguriert, um jeweils eine App zu unterstützen und einen einzelnen Datenpfad vom Benutzer zum Endpunkt zu erstellen, der diese Dienste durchläuft. Dies steht in krassem Gegensatz zum herkömmlichen Netzwerkdesign von Rechenzentren, bei dem ein erheblicher Teil der Netzwerk- und Application gemeinsam genutzt wird.

Es ist das Konzept der „gemeinsam genutzten Infrastruktur“, das in einer DevOps- und Agile-Entwicklungswelt, die ebenso auf einzelne Anwendungen fokussiert ist wie die öffentliche Cloud, zur Herausforderung wird.

Herkömmliche, gemeinsam genutzte Infrastrukturnetzwerke führen zu „einem echten Weg von der Tür zur App“. In der heutigen schnelllebigen, digitalen Welt ergeben sich aus diesem Ansatz folgende Herausforderungen:

• Ausrichtung der Infrastrukturversion. Eine App benötigt möglicherweise Funktionen, die durch ein Upgrade oder einen Patch bereitgestellt werden, während eine andere von der vorhandenen Version abhängig ist. Eine gemeinsam genutzte Infrastruktur lässt im Allgemeinen keine Versionsvielfalt auf demselben System zu und kann daher eine Application behindern, um eine andere zu bevorzugen.
• Widersprüchliche Bereitstellungspläne. Wenn gemeinsam genutzte Ressourcen betroffen sind, beginnen Unternehmen mit einer Verhandlungsphase, in der die an der Application Beteiligten versuchen, Konflikte in den Bereitstellungsplänen zu lösen. Der Prozess kann langwierig sein (und ist immer schmerzhaft) und es ist für niemanden ein Gewinn, wenn die Veröffentlichung einer neuen App oder eines Updates wegen Terminkonflikten verzögert wird. 
• Explosionsradius. Es versteht sich von selbst, dass, wenn meine App den Ausfall eines gemeinsam genutzten Systems verursacht, alle Apps, die auf dieses System angewiesen sind, ausfallen. Der Explosionsradius gemeinsam genutzter Infrastrukturen ist enorm und ein wesentlicher Faktor für die Zurückhaltung, Personen außerhalb der IT einen umfassenderen Zugriff auf die Bereitstellungspipeline zu gewähren.
• Fehlerbehebung. Der Versuch, aggregierte Protokolle zu durchsuchen, ist mühsam. Der Erfolg sehr erfolgreicher Unternehmen beruht einzig und allein auf der Fähigkeit, riesige Protokolle auszuwerten und die Daten wieder in Anwendungsflüsse aufzuschlüsseln. Die Fehlerbehebung bei gemeinsam genutzten Systemen ist kompliziert und zeitaufwändig und wirkt sich negativ auf die durchschnittliche Zeit bis zur Problemlösung aus, ein kritischer KPI für die moderne IT.

In der Cloud stellt dies normalerweise kein Problem dar. Es gibt einen Pfad pro App, da Apps im Allgemeinen nach ihrem eigenen Zeitplan in ihrer eigenen Umgebung bereitgestellt werden – oft von verschiedenen Teams. 

Um unsere geistige Gesundheit (und unser Rechenzentrum) zu schützen, müssen wir diesen Ansatz vor Ort übernehmen, unabhängig davon, ob es sich um eine private Cloud handelt oder nicht.

Ihnen stehen weiterhin gemeinsame Netzwerkdienste zur Verfügung. Firewalls, IPS/IDS, DDoS und Applications sind weitgehend anwendungsneutral und können (und sollten) unternehmensweit eingesetzt werden. Für alles andere gibt es pro App (oder, wenn Sie das bevorzugen, appspezifische) Dienste und Infrastruktur. Diese logische Trennung bewahrt die Stabilität und Sicherheit des Unternehmens und ermöglicht gleichzeitig die volatilere und möglicherweise instabilere Umgebung näher an den Apps. Darüber hinaus bleibt ein Datenpfad für herkömmliche (Legacy- und Heritage-)Apps erhalten, die nicht die Geschwindigkeit und Unterstützung benötigen, die neuere Apps brauchen. Das Netzwerk pro App kann eine private Cloud, mehrere Container-Cluster oder eine Kombination davon sein.

Durch die Verbindung beider entsteht ein stabileres, belastbareres Netzwerk, das zudem flexibel und schnell ist. 

Ein Pro-App-Ansatz für das Netzwerk bietet eine Reihe von Vorteilen und verringert außerdem die Probleme, die sich aus einem gemeinsamen Ansatz in Verbindung mit modernen App-Architekturen und Bereitstellungsmodellen ergeben:

• Individuelle Pipelines und Zeitpläne. Ich kann meine eigenen Bereitstellungen planen, wenn sie fertig sind, da sie keine anderen Apps oder Infrastrukturen als meine eigene betreffen. Dies bietet die Flexibilität, die Sie zur Unterstützung der unterschiedlichen Zeitpläne benötigen, die Sie in einem modernen Rechenzentrum unterstützen müssen.
• Eingeschränkter Explosionsradius. Wenn meine Bereitstellung einen Absturz auf meinen dedizierten Systemen verursacht, liegt dies ganz allein an mir. Es hat keine Auswirkungen auf andere Apps. Dieser dedizierte Datenpfad pro App erleichtert außerdem die Fehlerbehebung, da ich sicher sein kann, dass die Protokolle und Fehlermeldungen auf allen Systemen zu mir und meiner Application gehören.
• Die Skalierung ist nicht auf Plattformressourcen beschränkt. In einer höchst unbeständigen und dynamischen Welt ist es nahezu unmöglich vorherzusagen, wann der nächste Besucheransturm kommt, ob sich Inhalte viral verbreiten oder ob man – Gott bewahre – angegriffen wird. Was auch immer die Ursache sein mag: Wenn die Nachfrage nach Apps auf gemeinsam genutzten Systemen (Hardware oder Software) sprunghaft ansteigt, ist die Skalierung auf die auf der Plattform verfügbaren Ressourcen beschränkt. Durch die Verwendung einer Pro-App-Architektur wird diese Einschränkung gemildert und die Skalierung einzelner Komponenten nach Bedarf ermöglicht, um die Nachfrage zu erfüllen.
• Unterstützt echte Infrastruktur als Codemodell. Gemeinsam genutzte Systeme verwenden gemeinsame Konfigurationen, selbst wenn es sich nur um eine Basiskonfiguration mit Richtlinien pro App handelt. Dieses Modell kann beim Versuch, eine Infrastruktur als Codemodell zu implementieren, Chaos verursachen, insbesondere wenn mehrere Apps gleichzeitig aktualisiert werden sollen. Änderungen können sich ohne Vorwarnung auf andere Apps auswirken oder Commit- und Klonaktionen können fehlschlagen, weil andere Personen Ressourcen sperren, wenn Sie sie benötigen. Eine Pro-App-Architektur stellt sicher, dass Bereitstellungsartefakte nur zu einer App gehören und von den App-Eigentümern (egal ob Entwickler, DevOps, NetOps oder ) ordnungsgemäß verwaltet werden können.

Zwar wird eine Pro-App-Architektur nicht alle Probleme lösen, die sich aus der digitale Transformation ergeben, doch kann sie einen großen Beitrag dazu leisten, das durch die Cloud entstehende Chaos einzudämmen. Es bietet größere Möglichkeiten zur Standardisierung der Sicherheit und unterstützt die Multi-Cloud-Umgebungen, zu denen die meisten Unternehmen zunehmend werden.

Seien Sie gespannt auf den nächsten Beitrag dieser Reihe. Darin werden wir uns näher damit befassen, wie Sie mit denen umgehen können, die aufgrund des Markteinführungsdrucks infolge der digitale Transformation die Sicherheitsvorkehrungen vernachlässigen.