Die Macht des Proxys: Die Lücke zwischen Entwicklung und Produktion schließen

Die Welten der Anwendungsentwickler und Netzwerkarchitekten könnten nicht unterschiedlicher sein, abgesehen vielleicht von der Art und Weise, wie sie den Bereich des anderen betrachten.

Eine typische Netzwerkperspektive einer Anwendungsbereitstellung sieht oft folgendermaßen aus:

Auf der anderen Seite der „Mauer“ sieht die Perspektive des Entwicklers auf die Bereitstellung derselben Anwendung häufig folgendermaßen aus:

Beide sind in ihrem jeweiligen Bereich zweifellos präzise, aber gegenüber der tatsächlichen Architektur des anderen höchst gleichgültig. Dies ist ein Beispiel dafür, warum bei der Einführung von Anwendungen in die Produktion viele Probleme auftreten. Und sie stehen auf. Untersuchungen haben ergeben, dass im Jahr 2013 „90 % der Entwickler angaben, Wochenenden, Feiertage und Urlaub damit zu verbringen, Notfälle in der Produktionsphase zu beheben [1]“. Während viele davon sicherlich auf Softwaredefekte und -fehler zurückzuführen sind, sind viele andere zweifellos auf die vielen Unterschiede in den Umgebungen zurückzuführen. Produktion ist nicht Entwicklung und umgekehrt.

Heutige Anwendungen nutzen eine Vielzahl von Diensten, die in Produktionsumgebungen vorhanden sind, aber selten in Entwicklungs- oder Testumgebungen: Lastenausgleich für Skalierbarkeit, Caches zur Verbesserung der Leistung und Web-App-Firewalls für die Sicherheit. Diese Dienste berühren nicht nur jede einzelne Anfrage und Antwort, während sie das Netzwerk zwischen dem Benutzer und der App (oder der App und der API, wenn Sie das bevorzugen) durchlaufen, sondern in einigen Fällen ändern sie die Anfragen und/oder Antworten. Ein gutes Beispiel hierfür ist die IP-Adresse des Benutzers. Dieser Wert findet sich in den HTTP-Headern jeder Anfrage, wenn er aber durch einen Proxy zum Lastenausgleich läuft, wird er zur IP-Adresse des Proxys und nicht des Clients.

Für den ahnungslosen Entwickler kann dies dazu führen, dass Anwendungen „kaputtgehen“ und stundenlange Fehlerbehebungen erforderlich sind, zusätzlich zu der Zeit, die zum Ändern der App erforderlich ist. Diese Art von Problemen, die durch Unterschiede in der Umgebung entstehen, sind zweifellos der Grund, warum 28 % der Entwickler, die an einer Umfrage teilgenommen haben, [2] sagte Mitte 2015: „Über 50 % der Produktionsprobleme hätten mit der richtigen Testumgebung gefunden und behoben werden können.“ Und mehr als die Hälfte (52 %) gab an, dass „zwischen 25 und 50 % der Produktionsprobleme behoben worden wären“.

Viele der in der Produktion auftretenden Probleme sind direkt auf Unterschiede in der Anwendung zurückzuführen, insbesondere bei Anwendungen, die mit agilen Methoden entwickelt wurden. Agile Methoden können aufgrund der Häufigkeit von Codeänderungen die Wahrscheinlichkeit erhöhen, dass derartige Konflikte in der Produktion auftreten.

Immer mehr, aber bei weitem nicht alle dieser Herausforderungen lassen sich durch die Verwendung eines programmierbaren Proxys lösen, da dadurch die Notwendigkeit entfällt, bereits in der Produktion befindlichen Code zu ändern und die Markteinführung der Anwendung dadurch nicht mehr weiter verzögert wird. Das oben erwähnte „IP-Adress“-Problem wird üblicherweise dadurch gelöst, dass der Proxy angewiesen wird, einen neuen HTTP-Header einzufügen, der die tatsächliche IP-Adresse enthält, sodass Entwickler weiterhin Zugriff auf diese Informationen haben. Außerdem sind Layer-7-Loadbalancing-Proxys in der Lage, Anwendungs- und API-Anfragen anhand einer Vielzahl von Daten, einschließlich Versionierung und API-Signaturen, weiterzuleiten.

Es ist interessant festzustellen, dass der Load Balancer die Komponente ist, die sowohl in Software- als auch in Netzwerktechnikdiagrammen häufig erwähnt wird. Obwohl dieser Proxy traditionell vom Netzwerkteam bereitgestellt und verwaltet wird, ist er für Anwendungsarchitekturen so wichtig, dass er fast immer als Teil der Anwendung enthalten ist. Ebenso erkennen Entwickler heute die Bedeutung des Lastausgleichs für die Skalierung von Anwendungen und beziehen ihn im Allgemeinen in ihre Diagramme ein.

Es spiegelt auch die zunehmende Zahl von Fällen wider, in denen Entwickler und Betriebsmitarbeiter die Verantwortung für die Skalierbarkeit übernommen und damit die Kontrolle über den Lastenausgleich für ihre Anwendungen übernommen haben.  Das ist eine gute Sache, denn es bedeutet, dass Entwicklung und Betrieb die Lastverteilung (und alle damit verbundenen Vorteile der Schicht 7) in die CI/CD-Pipeline integrieren können (und dies hoffentlich auch tun), insbesondere während des Tests, um sicherzustellen, dass potenzielle Probleme schnell gefunden und gelöst werden können, bevor mit der Produktion begonnen wird. Durch die Verlagerung des Lastausgleichs nach links in die CI/CD-Pipeline wird zudem ein ganzheitlicherer Ansatz für die kontinuierliche Bereitstellung ermöglicht, bei dem das gesamte Anwendungspaket (die Architektur) als Code verwaltet und gleichzeitig aktualisiert werden kann. Auf diese Weise kann die Netzwerkinfrastruktur (denn darunter fällt bei der Beschreibung traditionell der Lastenausgleich) eine unveränderliche Architektur unterstützen, in der Anwendungen (oder Microservices, wenn Sie diesen Weg wählen) nicht einfach aktualisiert, sondern mit neuen Konfigurationen vollständig neu bereitgestellt werden. Dadurch wird die natürliche Software-Entropie vermieden, die zu Herausforderungen und technischer Schuld führen kann.

Der Proxy ist in vielerlei Hinsicht die Brücke, die das „Netzwerk“ mit der „Anwendung“ über die bildliche Lücke (eher eine Mauer, wenn wir ehrlich sind) hinweg verbindet, die Software- und Netzwerkingenieure und -architekten trennt. Dies ist eine der Lücken, die DevOps schließen muss, wenn Unternehmen in der Lage sein sollen, die Herausforderungen moderner Architekturen zu meistern.

[1] http://solutions-review.com/mobile-application-development/5000-developer-survey-mobile-app-development-insights-revealed/

[2] https://www.ravellosystems.com/blog/software-is-not-quite-ready-to-eat-the-world-state-of-devtest-infrastructure-survey-results/