In einem früheren Beitrag haben wir uns mit der Idee beschäftigt, App-Dienste zu sich verändernden App-Architekturen hinzuzufügen. Dabei verwenden wir ein Konzept, das wir „Einfügepunkte“ nennen. Für diejenigen, die es nicht verstanden haben: Ein Einfügepunkt ist eine architektonisch eindeutige Stelle im Code-zu-Kundendatenpfad, an der es sinnvoll ist, Funktionen hinzuzufügen, die oft außerhalb des Entwicklungsumfangs liegen oder betrieblich effizienter sind.
Eine Reihe robuster Funktionen ergänzt oder verbessert die Anwendungen, die heutige Geschäftsaktivitäten repräsentieren.
Einfügepunkte sind der Client, die Infrastruktur und die App selbst. Jeder Punkt hat seine Vor- und Nachteile, wenn es um die Abwägung zwischen Betriebs- und Kosteneffizienz geht. Beispielsweise ist es wahrscheinlich weder betrieblich noch kosteneffizient, einen netzwerkzentrierten DDoS-App-Dienst in den Client oder die App einzufügen. Dies liegt daran, dass keiner der Einfügepunkte Zugriff auf die hardwarebeschleunigten Funktionen hat, die mit einer Infrastrukturoption verfügbar sind, und auch nicht über die erforderliche Transparenz verfügt, um eine genaue Bestimmung vorzunehmen.
Wir suchen also nach App-Diensten, die zum Zeitpunkt der Einbindung sowohl betriebswirtschaftlich als auch kosteneffizient sind. In diesem Fall konzentrieren wir uns auf den App-Server (die Plattform) selbst.
Auf den ersten Blick scheint dieser Einfügepunkt eine seltsame Wahl zu sein. App-Server hosten und liefern Apps, keine App-Dienste. Wenn Sie jedoch die Rolle von NGINX und anderen App-Servern heutzutage bedenken, werden Sie feststellen, dass sie häufig gleichzeitig die Rolle der Infrastruktur und des Servers übernehmen. Beispielsweise können einige App-Server als SSL-Endpunkt fungieren und tun dies auch. Die SSL-Terminierung ist ein App-Dienst, der häufig mit SSL-Offload (Hardwarebeschleunigung) gekoppelt ist. Auch Web-App-Firewall-Dienste werden häufig über Plugins an App-Server gekoppelt.
Die Verwendung des App-Servers als Einfügepunkt ist weder neu noch fremd. In unserer Studie „State of Application Services 2020“ haben wir nach dieser Option zur Bereitstellung von App-Diensten gefragt. Wir haben festgestellt, dass an diesem Einfügepunkt Interesse besteht. Etwa 6% der Befragten möchten ein „Plugin“ für App-Dienste nutzen. Weitere 9 % würden die Option „als Dienst“ bevorzugen, für deren Aufruf ein begleitender Codeabschnitt (eingefügt oder eingeschlossen) erforderlich ist. Eine kleine Zahl, nämlich 4 %, würde gerne eine Bibliothek zur Einbindung von App-Diensten nutzen. Diese letzte Option wird unserer Erfahrung nach häufig verwendet, um Funktionen in serverlose Anwendungen (Funktion als Dienst) einzufügen.
In vielen Fällen ist die Bereitstellung eines App-Dienstes auf einem App-Server aus betrieblicher Sicht sinnvoll. Da diese Dienste häufig für die Bereitstellung einer einzelnen App konfiguriert sind, können sie vom selben Team verpackt und bereitgestellt werden. Fachwissen zum App-Server sorgt für mehr Vertrauen und eine einfachere Integration in Ökosysteme und Bereitstellungspipelines.
In einigen Fällen ist es sinnvoll, die App und den App-Dienst zusammen auf derselben Instanz eines einzelnen App-Servers bereitzustellen. Beispielsweise kann der App-Schutz über eine app-spezifische Richtlinie integriert und als Schritt bei der Verarbeitung von Anfragen und Antworten ausgeführt werden. Dass die Funktionalität innerhalb des Servers aufgerufen wird, ist sinnvoll und kann, wenn die Prüfung lokal ausgeführt wird, die Leistung verbessern, indem zusätzliche Hops und Verarbeitungen durch außerhalb der Umgebung gehostete Dienste vermieden werden. Dies kann sowohl betrieblich als auch finanziell die Effizienz steigern, insbesondere wenn Sie den Dienst stunden- oder stundenweise bezahlen.
Unabhängig davon, ob der App-Server zum Hosten eines eigenständigen App-Dienstes oder als Host sowohl für die App als auch für den App-Dienst verwendet wird, ist der App-Server sicherlich ein guter Einfügepunkt für die richtigen App-Dienste.