Von monolithisch zu verteilt: Der Einfluss sich entwickelnder Applications auf ADCs

Die ersten Computer in den 40er und 50er Jahren des 20. Jahrhunderts verwendeten nicht wirklich Applications in dem Sinne, wie wir sie heute verstehen. Sie wurden größtenteils mit Maschinensprache und Lochkarten programmiert. Die ersten Applications– wir könnten sie als Applications 1.0 bezeichnen – entstanden neben den zentralisierten Großrechnern der 1960er und 1970er Jahre, auf denen monolithische Applications liefen, die für Aufgaben wie Lohn- und Gehaltsabrechnung, Inventarisierung und grundlegende Datenverarbeitung konzipiert waren. Diese frühen Applications waren auf eine einzige Codebasis beschränkt, also auf sehr große, einheitliche Codeblöcke, die in isolierten Rechenzentren oder Unternehmensbüros betrieben wurden. Stellen Sie sich eine abgelegene Burg auf einem Hügel vor, die durch hohe Mauern und einen Graben geschützt ist und in die Arbeiter gehen, um mithilfe von Computersprachen wie FORTRAN und COBOL auf zentrale Computerressourcen zuzugreifen. 

Eine Weiterentwicklung des monolithischen Application erfolgte mit dreischichtigen Applications, bei denen die Rechenressourcen in drei unterschiedliche Funktionsschichten unterteilt wurden, die jeweils separate, aber miteinander verbundene Applications enthielten. Die Präsentationsschicht bzw. die Benutzeroberfläche wurde von Desktop- Applications, wie etwa einer Produktivitätssoftware (wie zum Beispiel WordStar), gesteuert, während die Geschäftslogikschicht einen Application umfasste, der Benutzeranforderungen verarbeitete und Berechnungen durchführte. Die Datenschicht oder Datenbank speichert und verwaltet Daten.    

Zwar bieten dreistufige Applications mehr Modularität und Flexibilität als monolithische Apps, dieses Modell ist jedoch weiterhin auf die physische Rechenzentrumsinfrastruktur und lokale Ressourcen angewiesen. Monolithische und dreischichtige Applications bleiben in einigen Branchen die Norm, darunter im Gesundheitswesen, im Bankwesen und in der öffentlichen Verwaltung, wo Altsysteme strenge gesetzliche Anforderungen erfüllen und unternehmenskritische Applications sich keine Ausfallzeiten leisten können.  

Der Aufstieg des E-Commerce in den 1990er Jahren läutete die Dotcom-Ära ein. Application (ASPs) bieten Cloud-ähnliche Webhosting-Dienste über das World Wide Web an, mit denen Unternehmen HTML- Applications starten können, ohne eine eigene Infrastruktur aufbauen zu müssen. Web-Apps waren weltweit überall dort verfügbar, wo ein Benutzer über DFÜ- oder Breitbandzugang verfügte. Diese Applications wurden in drei Schichten aufgeteilt: Verbraucher nutzten Internet- und Webbrowser-Software auf ihren Heimcomputern, um auf ASP-Sites gehostete Applications zu besuchen, während die Datenbankserver beim ASP den Kauf und die Speicherung der Kundendaten übernahmen. Web-Apps dominieren noch immer den Online-Einzelhandel und haben maßgeblich zur Entwicklung des E-Commerce-Geschäfts im Internet beigetragen.  

Die frühen 2010er Jahre waren die Ära der Cloud-Disruption und viele Prognostiker prognostizierten den Tod des lokalen Rechenzentrums und den Aufstieg des Cloud-basierten Computing. Während darüber diskutiert wurde, die gesamte Datenverarbeitung in die Cloud zu verlagern, wurden viele Apps für die Nutzung in Cloud-Umgebungen modernisiert oder in der Cloud selbst entwickelt: Cloud-native Applications. 

Diese Cloud-nativen Apps wurden für die Skalierung und Leistung der Cloud optimiert und von Grund auf auf Microservices-Architekturen aufgebaut, was einen weiteren Paradigmenwechsel in der App-Entwicklung einleitete. Auf Microservices basierende Applications waren keine eigenständigen, einheitlichen Codeblöcke mehr, sondern aus kleinen, unabhängig einsetzbaren Microservices zusammengesetzt, die jeweils eine einzelne Funktion erfüllten und über APIs mit anderen Microservices kommunizieren konnten. Modulare Mikrodienste wurden in Applications innerhalb portabler Container orchestriert. Dabei handelt es sich um virtualisierte Computerinstanzen, die autark sind und in unterschiedlichen Umgebungen konsistent ausgeführt werden können. Auf Microservices basierende Applications bieten gegenüber monolithischen oder dreistufigen Apps viele Vorteile, darunter eine schnellere App-Entwicklung, verbesserte Skalierbarkeit, erhöhte Flexibilität und Wiederverwendbarkeit der Dienste. 

Diese Komponenten-Mikroservices werden jedoch aus öffentlichen Cloud-Bibliotheken und anderen Remote-Plattformen abgerufen und über APIs oder andere Kommunikationsmechanismen weitergeleitet. Diese verstreuten Elemente waren schwer zu verwalten und durch die Offenlegung der API vergrößerte sich die Angriffsfläche der App, was Netzwerkangriffen während der Datenübertragung und potenziellen Schwachstellen in Bibliotheken von Drittanbietern Tür und Tor öffnete. 

Heute erleben Applications einen weiteren Paradigmenwechsel. Die Vorhersage des Todes des Rechenzentrums war stark übertrieben und viele der heutigen Unternehmensportfolios enthalten eine Mischung aus traditionellen und modernen Apps, die in Hybridumgebungen ausgeführt werden und auf lokale, Edge- und Cloud-Ressourcen zugreifen. Dies erschwert noch zusätzlich den Bedarf an einer konsistenten Plattform zur Konsolidierung der Bereitstellung und Sicherheit von Apps und APIs, wo auch immer diese sich befinden.

Darüber hinaus werden Apps immer komplexer und basieren nicht nur auf Cloud-basierten Mikrodiensten, sondern auch auf Echtzeit-Datenflüssen und neuen Eingabeformen. Denken Sie an eine typische Reise-Website- Application. Zusätzlich zu verlockenden Fotos und Inhalten zu Ihrem ausgewählten Reiseziel gibt es Echtzeit-Engines mit API-Zugriff zum Buchen von Hotelzimmern, Flügen und Mietwagen, Links zu Live-Wettervorhersagen und interaktive Kartenfunktionen. Diese modernen Applications sind hochgradig vernetzt, stammen aus mehreren Quellen und sind dynamisch. Sie nutzen Daten aus Hybrid-Clouds und verteilten Umgebungen, um ein robustes Kundenerlebnis zu gewährleisten. 

Die Komplexität und die Angriffsfläche nehmen nur zu, wenn zu diesen bereits hochintegrierten Applications KI hinzugefügt wird. Zu KI-gestützten Diensten, die Daten aus vernetzten Netzwerken und Geräten nutzen, können Empfehlungsmaschinen oder Chatbots gehören; eine Reisewebsite kann auf der Grundlage von Echtzeit-Benutzerprofilen und prädiktiven Analysen personalisierte Reiseziele und Aktivitäten vorschlagen oder die Überwachung dynamischer Preisalgorithmen anbieten. 

KI- Applications verarbeiten riesige Datenmengen und verwenden komplexe Verkehrsmuster. Sie stellen umfangreiche und häufige Anfragen an Unternehmensdatenspeicher und KI-Modelle in KI-Fabriken. KI-Workloads werden üblicherweise auf verteilten Infrastrukturen wie öffentlichen Clouds, Edge-Geräten und Hybridsystemen bereitgestellt, wodurch Applications Risiken hinsichtlich der Datensicherheit und des Datenschutzes, feindlichen Angriffen auf KI-Modelle und Schwachstellen in der Infrastruktur ausgesetzt sind. Diese Herausforderungen erfordern die Bereitstellung umfassender Sicherheit für API-reiche Applications in Kombination mit leistungsstarkem Verkehrsmanagement und App-Bereitstellungsdiensten, die moderne KI-Apps und -Workloads unterstützen, unabhängig davon, wo sie bereitgestellt werden.