Das Aufkommen dezentralisierter Clouds und App-to-App-Netzwerke diktiert den Einsatz von Cloud-nativen Netzwerk- und Sicherheitsinfrastrukturen. [...]
Der Begriff „Cloud“ hat sich seit der ersten Verwendung des Begriffs Anfang der 1990er Jahre stetig weiterentwickelt. Man könnte argumentieren, dass Cloud 1.0 in Wirklichkeit nichts weiter als ein Euphemismus für gehostete Dienste war. Gehostete Dienste gaben Unternehmen die Möglichkeit, kritische Anwendungen von ihrem Firmengelände aus in einer hochsicheren, kalkulierbaren Umgebung zu betreiben. Dieses Wertversprechen setzte sich mit dem zukünftigen Aufkommen von Diensten wie AWS und Microsoft Azure fort, bei denen Unternehmen alte Anwendungen „anheben und verschieben“ und anschließend in einer Cloud ablegen konnten.
Cloud 2.0 brachte weboptimierte Anwendungen hervor. Bei Cloud 2.0 wurden die Anwendungen wirklich für die Cloud entwickelt und brachten Unternehmen hervor, die die Cloud zu ihrer primären Computerplattform machten. Diese Cloud-Strategie konzentrierte sich jedoch auf einen einzigen Cloud-Anbieter und traditionelle monolithische Anwendungsarchitekturen. Sogar Unternehmen, die mehrere Clouds nutzten, bauten App A auf einer Cloud, App B auf einer anderen usw. In diesem Fall handelte es sich bei Multi-Cloud tatsächlich um mehrere Clouds, die als diskrete, unabhängige Infrastruktureinheiten genutzt wurden.
Wir sind jetzt in die Cloud 3.0-Ära eingetreten, die man sich wie Multi-Cloud auf Steroiden vorstellen kann. Der Aufstieg von Mikrodiensten und Containern hat es Anwendungsentwicklern ermöglicht, Anwendungen zu entwickeln, indem sie auf Dienste von mehreren Cloud-Anbietern zugreifen. Die meisten modernen, Cloud-nativen Anwendungen werden auf diese Weise erstellt. Am Horizont zeichnet sich Edge-Computing ab, wodurch mehr Standorte für Anwendungsentwickler entstehen werden, um den Zugang zu Daten und Anwendungsdiensten zu erweitern. Dies ist das Konzept der Distributed Cloud, bei dem die Cloud nicht mehr ein einzelner Standort, sondern eine Reihe von verteilten Ressourcen ist.
Distributed Cloud verändert die Bereitstellung von Anwendungen
Die Entwicklung der Cloud – und damit auch der Cloud-nativen Anwendungen – hat tiefgreifende Auswirkungen auf die Netzwerk- und Sicherheitsdienste gehabt, die erforderlich sind, um App-Komponenten mit anderen App-Komponenten und Apps mit Nutzern zu verbinden. Bei Cloud 1.0 verwendeten IT-Experten physische Geräte wie Load Balancer oder Application Delivery Controller und Web-App-Firewalls. Diese wurden in denselben Rechenzentren installiert, die auch die Anwendungsinfrastruktur beherbergten. Bei Cloud 2.0 wurden diese Funktionen virtualisiert und als Cloud-Ressource installiert. Die Netzwerk- und App-Architekturen waren weitgehend identisch, aber die Infrastruktur verlagerte sich zu Cloud-residenten virtuellen Appliances.
>>Bei der Distributed Cloud (Cloud 3.0) sind die Anwendungskomponenten (z.B. Microservices) modular aufgebaut und befinden sich in Containern über mehrere Cluster hinweg. Dies stellt DevOps-Teams und IT-Experten vor erhebliche Herausforderungen bei der Bereitstellung und beim Betrieb. Die dynamische und verteilte Natur von containerisierten Arbeitslasten und Mikrodiensten kann nicht durch die physische oder sogar virtuelle Infrastruktur unterstützt werden, die traditionell für monolithische Anwendungen verwendet wird. Diese sind im Gegensatz zu dem dynamischen Betriebsmodell, das für hochgradig verteilte Cluster und Arbeitslasten erforderlich ist, auf zentralisierte Steuerung und Sichtbarkeit angewiesen. Eine containerisierte Arbeitslast kann in wenigen Minuten oder sogar Sekunden hochgefahren und wieder abgeschaltet werden. Das bedeutet, dass die unterstützende Netzwerk- und Sicherheitsinfrastruktur wie Load Balancer, Web-App-Firewalls und API-Gateways ebenso schnell hoch- und heruntergefahren werden müssen.
Den betrieblichen Herausforderungen der Distributed Cloud begegnen
Diese Woche kündigte Volterra, ein Anbieter von Cloud-Infrastrukturen für Anwendungen, die aus der Cloud kommen, die neueste Version seines VoltMesh-Dienstes an. Dieser Dienst löst viele der betrieblichen Herausforderungen, die mit der Bereitstellung und dem Betrieb moderner Anwendungen in einem dezentralen Cloud-Modell verbunden sind. Das Unternehmen bietet eine breite Palette von so genannten „Application Delivery Services“ aus der Cloud an, die als ein einziges SaaS-basiertes Angebot zur Verfügung gestellt werden.
Anstatt mehrere virtuelle Appliances pro Cluster und über mehrere Cluster hinweg bereitstellen zu müssen, bietet VoltMesh einen integrierten Service-Stack, der einfach über einen verteilten Cluster mit zentralisierter Verwaltung, End-to-End-Sichtbarkeit und Richtlinienkontrolle bereitgestellt werden kann. Durch die Nutzung der Geschwindigkeit und Allgegenwart eines SaaS-basierten Dienstes kann DevOps die Bereitstellung verteilter Cloud-nativer Anwendungen beschleunigen und den laufenden Betrieb vereinfachen. Gleichzeitig können Entwickler eine bessere Code-Integration und Agilität erreichen, da sie größere Freiheit haben, wo und wie sie entwickeln. VoltMesh kann in Clustern bei allen großen Cloud-Anbietern sowie bei privaten Clouds und Edge-Sites eingesetzt werden. Volterra bietet auch sein eigenes Anwendungsbereitstellungsnetzwerk (ADN) an, um die Leistung und Sicherheit von Cloud-Nativen Anwendungen zu verbessern – sie werden direkt in Volterras privatem Netzwerk und näher am Endbenutzer gehostet.
Der Cloud-native Infrastruktur-Ansatz, den Volterra verfolgt, dient jedoch mehr als nur der Geschwindigkeit, da er erhebliche Auswirkungen auf die Sicherheit hat. Da die Anwendungsentwickler dazu übergehen, cloud-native Anwendungen auf Mikrodiensten aufzubauen, entstehen neue Bedrohungen durch eingebettete und unsichtbare APIs. Die Anzahl der APIs pro Anwendung ist explodiert, was zu mehr Datenverkehr innerhalb der Anwendung führt. Sicherheitsansätze wie Segmentierung, sogar Mikrosegmentierung, operieren auf der Netzwerkebene – sie sind also auf der API-Ebene blind. Das bedeutet, dass DevOps- und DevSecOps-Teams den Schwerpunkt ihres Zero-Trust- Modells vom Netzwerk auf die API-Schicht verlagern müssen, einschließlich der Möglichkeit, alle APIs zu „sehen“ und dann Richtlinien auf ihnen durchzusetzen.
Als Teil dieser Veröffentlichung hat VoltMesh seine neue API-Autoentdeckungsfunktion vorgestellt, die mit Hilfe seines maschinellen Lernprogramms automatisch alle APIs in einer Anwendung finden kann. Es wendet dann automatisch Richtlinien an, um nur die APIs auf die Whitelist zu setzen, die erforderlich und validiert sind, wodurch alle nicht benötigten oder unsicheren APIs unwirksam werden. Dadurch wird die Angriffsfläche erheblich verkleinert, wodurch Schutz und Konformität erhöht werden, ohne die Release-Zyklen von Anwendungen zu verzögern.
Das Konzept von Multi-Cloud (oder multiple Clouds) plus monolithischen Anwendungen weicht rasch einer Distributed Cloud plus Distributed Apps, und dies wird die Art und Weise verändern, wie wir Netzwerk- und Sicherheitsinfrastruktur für sie bereitstellen. Die traditionelle Infrastruktur zur Anwendungsbereitstellung muss sich weiterentwickeln, um Cloud-nativ und verteilt zu sein, wenn die DevOps- und NetOps-Teams mit der Agilität der Entwickler, die heute moderne Anwendungen entwickeln, Schritt halten wollen.
*Zeus Kerravala ist der Gründer und Chefanalyst von ZK Research.
Be the first to comment