Die Ironie beim Schlagwort des Tages ist köstlich: Cloud-native.
Zunächst einmal ist festzuhalten, dass Cloud-native trotz seines Namens keine Cloud voraussetzt. Verrückt, oder? Der Name leitet sich von dem Architekturansatz ab, eine Anwendung zu entwickeln, die auf Infrastruktur angewiesen und auf die Konzepte der Cloud ausgelegt ist: Elastizität, Skaleneffekte und verteiltes Rechnen. Es ist unbestreitbar das Cloud-Computing, das diese Konzepte in alle Bereiche der Anwendungsbereitstellung getragen hat: von der Anwendungsarchitektur bis zur Automatisierung, von der API-basierten Integration bis zur Infrastruktur. Cloud-Computing hat die Art und Weise verändert, wie wir Anwendungen entwickeln, erstellen und bereitstellen. Anwendungen, die in der Public Cloud entstanden sind, übernahmen naturgemäß viele der gleichen Abhängigkeiten und Merkmale. Somit gibt der Name die Herkunft dieser Architekturform treffend wieder.
Unbestreitbar besteht auch ein Zusammenhang zwischen Cloud-Native und Containern. Allein dadurch unterscheidet sich Cloud-Native von Born-in-the-Cloud-Anwendungen, die sich zum Erreichen ähnlicher Ziele hauptsächlich auf virtuelle Maschinen und cloudnative Dienste stützen. Cloud-Native und Container sind eng miteinander verknüpft, da die zugehörigen Container-Orchestratoren (Kubernetes) die einfachste und am weitesten verbreitete Möglichkeit darstellen, Anwendungen mit der Infrastruktur zu verbinden, die erforderlich ist, um Elastizität und damit die gewünschten Skaleneffekte zu erzielen.
In einer Cloud-nativen Anwendung werden Komponenten in kleinste Einheiten zerlegt, um Skaleneffekte zu ermöglichen. Daher werden Cloud-native und Container nahezu synonym verwendet. Es muss möglich sein, bei Bedarf nur die jeweils benötigten Funktionen zu skalieren. Eine solche elastische, funktionale Aufteilung von Anwendungen wird traditionell durch Architekturen erreicht, die auf Layer-7-Routing (HTTP) basieren – und Cloud-native bildet hier keine Ausnahme. Dieselben Prinzipien gelten auch für diese modernen Anwendungen. Dabei kommt in der Regel ein Ingress-Controller zum Einsatz, also ein Infrastrukturdienst, der eingehende Anfragen an die passende containerbasierte Instanz einer Anwendungskomponente verteilt.
Diese Aufteilung erfolgt häufig auf API-Ebene, wobei URIs API-Aufrufen zugeordnet werden, die wiederum bestimmten Container-Services zugeordnet sind. Die Ingress-Steuerung leitet Anfragen an den entsprechenden Container-Service weiter, der sie seinerseits auf einen Pool von Komponenten-/Anwendungsinstanzen verteilt. Dabei handelt es sich um eine zweistufige Architektur, bei der die Ingress-Steuerung auf Schicht 7 (HTTP) die Anfragen zur Zustellung und Verarbeitung an einen herkömmlichen Load Balancer (POLB) verteilt.
Darüber hinaus besteht eine Abhängigkeit von Service-Registrys, hinter denen sich ein weiterer Infrastrukturanwendungsdienst verbirgt, der für die Skalierbarkeit cloudnativer Anwendungen erforderlich ist. Ohne einen Mechanismus zur Serviceerkennung funktionieren weder der Lastenausgleich noch die Ingress-Steuerung, wodurch die Anwendung letztlich nicht mehr betriebsfähig ist.
Diese Beziehung – zwischen Komponenten, Diensten, Dienstverzeichnissen, Load Balancern und der Ingress-Steuerung – verkörpert die Prinzipien cloudnativer Anwendungen. Anwendungskomponenten und Infrastruktur sind eng miteinander verbunden, ohne dabei starr gekoppelt zu sein. Ohne Layer-7-Routing und herkömmliche Lastverteilung können Komponenten weder Skaleneffekte erzielen noch über verschiedene Umgebungen hinweg verteilt werden. Die Abhängigkeit zwischen Infrastruktur und Anwendungen ist real und von entscheidender Bedeutung für die geschäftliche Notwendigkeit, Anwendungen bereitzustellen.
Nichts davon ist von irgendeiner Art von Cloud-Computing-Umgebung abhängig oder setzt eine solche voraus. Eine Cloud-native-Anwendung kann eigenständig bereitgestellt werden – und wird es häufig auch. Betrachtet man die Daten zu Containern und ihren Ausführungsorten, zeigt sich sogar, dass „On-Premises“-Umgebungen gegenüber Public-Cloud-Umgebungen weiterhin dominieren.
Nun ist es zwar durchaus richtig, dass Container in einer privaten Cloud (On-Premises) bereitgestellt werden können – und tatsächlich zeigen auch unsere eigenen Untersuchungen weiterhin, dass die private On-Premises-Cloud nach wie vor das am häufigsten genutzte Cloud-Modell ist. Mehr als drei Viertel (79 %) der Befragten in unserem Bericht „State of Application Services 2019“ betreiben Anwendungen in einer privaten On-Premises-Cloud, während die Public Cloud mit 45 % weiterhin keine Mehrheit erreicht.
Cloud-native-Anwendungen sind eine schnell wachsende Architektur, die sich in den nächsten fünf Jahren mit Sicherheit weiter verbreiten wird. Das Verständnis ihrer Beziehung zu Infrastrukturanwendungsdiensten – und ihrer Abhängigkeit von diesen – ist eine entscheidende Voraussetzung für die erfolgreiche Bereitstellung und Absicherung dieser modernen Anwendungen.
Über den Autor
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Ähnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...