Einfügen von App-Diensten in sich verändernde App-Architekturen

Application haben sich seit den Anfängen der Computertechnik mehrfach weiterentwickelt. Einige langjährige Unternehmen verfügen bereits über die fünfte eigenständige Application . Viele betreiben und warten heute in jedem dieser Bereiche Applications . Die Ergebnisse unseres bevorstehenden Berichts „State of Application Services“ im Jahr 2020 deuten darauf hin, dass dies die Realität ist, in der die meisten Organisationen agieren:

Jede App-Architektur hat dramatische Auswirkungen auf alle „Upstream“-Komponenten – Netzwerkarchitekturen, Technologien, Sicherheit und Application (Bereitstellungsdienste). Im Mittelpunkt des jüngsten Architekturwandels – Microservices – steht ein Konzept, das wir als „Atomisierung“ oder „Komponentenbildung“ bezeichnen können. Beide beziehen sich im Wesentlichen auf den Prozess der Aufteilung einer Application in kleinere, handhabbare Komponenten mit dem Ziel, die Markteinführungszeit, die Codequalität und die Agilität zu verbessern.

In früheren Generationen von App-Architekturen blieb das Netzwerk der effizienteste Punkt, an dem bestimmte Arten von Application eingefügt werden konnten. Bis vor Kurzem war der Proxy das primäre Mittel, mit dem diese Dienste in den Datenpfad von der App zum Client eingefügt wurden.

Doch dieser Datenpfad zerfällt zusammen mit modernen Application . Es umfasst mittlerweile das Internet, Cloud-Eigenschaften und das Rechenzentrum. Der Client wird zunehmend als kritische Komponente der Application einbezogen. 

Daher ist es nicht mehr optimal, sich zum Einfügen von Application ausschließlich auf einen einzigen, bekannten Datenpfad zu verlassen. Da viele der neuen Datenpfade nicht für eine Proxy-basierte Plattform geeignet sind, müssen wir uns außerdem nach anderen potenziellen Einfügungspunkten umsehen, um moderne Applications zu skalieren und zu sichern.

Einfügepunkte für Application

Die Vorstellung, Application in einen Datenpfad „einzufügen“, bietet uns eine einfache Möglichkeit, diese moderne Sichtweise der Bereitstellung von Application zu beschreiben: Einfügepunkte.

In diesem Modell unterscheiden wir zwischen einem herkömmlichen Einfügepunkt (dem Proxy) und anderen Orten wie dem App-/Webserver und dem Client-Gerät. Jeder Standort verfügt über mehrere Formulare, die für die Einfügung von Application geeignet sind.

Proxy

Am traditionellen Netzwerkeinfügungspunkt des Netzwerks finden Sie proxybasierte Application sowie deren modernes Äquivalent – ​​den Sidecar-Proxy, der die Grundlage einiger Service-Mesh-Lösungen bildet. Beide werden „im Netzwerk“ bereitgestellt und erfordern daher unabhängig vom Formfaktor (Container, Software, Hardware) Zugriff auf diesen Standort.

Proxys sind weiterhin ein effizientes Mittel zum Einfügen von Application . Der größte Einfluss moderner App-Architekturen auf Proxys ist heute deren Fokus. Während Proxys traditionell Application für viele Applications hosten, erfordern heutige Architekturen einen eher anwendungsbezogenen Ansatz. Aus diesem Grund werden Proxys in Applications und deren Infrastruktur integriert und weisen tendenziell einen viel stärker granularen Fokus auf als frühere Proxy-Lösungen.

Proxylos

Da nicht alle Applications und Umgebungen diesen Zugriff bieten (denken Sie an SaaS), suchen wir nach alternativen Einfügepunkten, an denen Application bereitgestellt werden könnten. Wir bezeichnen diese alternativen Punkte im weitesten Sinne als „proxylos“, da sie für die Bereitstellung und Ausführung keinen Proxy erfordern oder darauf angewiesen sind. Diese Dienste können die Form herkömmlicher Agenten annehmen – Software, die als Teil des Servers oder der Application bereitgestellt wird – oder eine entwicklerfreundlichere Form codebasierter Optionen. Eingefügter Code wie JavaScript-Bibliotheken oder Webserver- und Browser-Plug-ins sind gute Beispiele für Einfügepunkte an diesen alternativen Stellen.

Service

Viele der Application können „als Service“ bereitgestellt, also als Cloud-basiertes Angebot gehostet werden. Für die Einfügung ist weiterhin Zugriff zum Aufrufen dieser Dienste erforderlich. Daher kommt es selten vor, dass solche Dienste ohne eine Einfügung über Code oder Konfigurationsartefakt in eine Application aufgenommen werden. 

In dieser neuen, von modernen Application geprägten Landschaft lautet die Antwort auf die Frage, wo Application passen, zunehmend: überall dort, wo eine App – oder ein Teil einer App – vorhanden sein könnte. Mit der Auflösung der App-Architekturen werden auch die App-Dienste zerstört, die zur Skalierung, Sicherung und Beschleunigung der Bereitstellung von Application verwendet werden. 

Die Erweiterung der Einfügepunkte ist nur einer der evolutionären Schritte, die notwendig sind, um den zukünftigen Bedarf an Telemetrie und intelligenterer Automatisierung zu unterstützen.  Während Unternehmen weiterhin den Weg der digitale Transformation beschreiten, werden auch die App-Dienste weiter ausgebaut und weiterentwickelt.