Die Welten von Anwendungsentwicklern und Netzwerkarchitekten könnten unterschiedlicher kaum sein – außer vielleicht darin, wie beide jeweils das Fachgebiet des anderen betrachten.
Aus Netzwerkperspektive sieht eine typische Anwendungsbereitstellung häufig so aus:
Auf der anderen Seite der „Mauer“ stellt sich dieselbe Anwendungsbereitstellung aus Sicht der Entwickler häufig so dar:
Beide sind für ihren jeweiligen Bereich zweifellos zutreffend, berücksichtigen jedoch die tatsächliche Architektur des jeweils anderen kaum. Dies veranschaulicht, warum beim Übergang von Anwendungen in den Produktivbetrieb so viele Probleme auftreten. Und sie treten tatsächlich auf. Untersuchungen zufolge gaben 2013 „90 % der Entwickler an, Wochenenden, Feiertage und Urlaubstage damit zu verbringen, dringende Anwendungsprobleme im Produktivbetrieb zu beheben[1]“. Viele davon hängen sicherlich mit Softwaremängeln und Fehlern zusammen, doch zahlreiche andere sind zweifellos auf die vielen Unterschiede zwischen den Umgebungen zurückzuführen. Die Produktivumgebung ist keine Entwicklungsumgebung und umgekehrt.
Heutige Anwendungen nutzen eine Vielzahl von Diensten, die in Produktionsumgebungen, jedoch nur selten in Entwicklungs- oder Testumgebungen vorhanden sind: Load Balancer zur Skalierung, Caches zur Leistungssteigerung und Web Application Firewalls für mehr Sicherheit. Diese Dienste verarbeiten nicht nur jede einzelne Anfrage und Antwort auf ihrem Weg durch das Netzwerk zwischen dem Benutzer und der Anwendung (oder, wenn Sie so wollen, zwischen der Anwendung und der API), sondern verändern in manchen Fällen auch die Anfragen und/oder Antworten. Ein gutes Beispiel hierfür ist die IP-Adresse des Benutzers. Dieser Wert ist in den HTTP-Headern jeder Anfrage enthalten, wird beim Durchlaufen eines Load-Balancing-Proxys jedoch zur IP-Adresse des Proxys und nicht des Clients.
Für Entwickler, die damit nicht rechnen, kann dies dazu führen, dass Anwendungen nicht mehr funktionieren und neben dem Zeitaufwand für die Anpassung der App auch stundenlange Fehlersuchen erforderlich werden. Solche Probleme, die durch Unterschiede zwischen den Umgebungen entstehen, sind zweifellos der Grund dafür, dass 28 % der Entwickler, die Mitte 2015 an einer Umfrage[2] teilnahmen, angaben: „Mehr als 50 % der Probleme im Produktivbetrieb hätten mit der richtigen Testumgebung gefunden und behoben werden können.“ Und mehr als die Hälfte (52 %) erklärte: „Zwischen 25 % und 50 % der Probleme im Produktivbetrieb hätten behoben werden können.“
Viele der in der Produktionsumgebung 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 die Wahrscheinlichkeit erhöhen, dass solche Konflikte in der Produktionsumgebung auftreten, da der Code häufig geändert wird.
Immer mehr, aber keineswegs alle dieser Herausforderungen werden durch den Einsatz eines programmierbaren Proxys gelöst, da dadurch bereits in der Produktion befindlicher Code nicht geändert und die Markteinführung der Anwendung nicht weiter verzögert werden muss. Das zuvor erwähnte Problem mit der „IP-Adresse“ wird üblicherweise gelöst, indem der Proxy angewiesen wird, einen neuen HTTP-Header einzufügen, der die tatsächliche IP-Adresse enthält, sodass Entwickler weiterhin auf diese Information zugreifen können. Zudem eignen sich Layer-7-Load-Balancing-Proxys hervorragend dazu, Anwendungs- und API-Anfragen anhand verschiedener Daten weiterzuleiten, darunter Versionsangaben und API-Signaturen.
Interessanterweise ist der Load Balancer die eine Komponente, die sowohl in Software- als auch in Netzwerktechnikdiagrammen häufig ausdrücklich dargestellt 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 aufgeführt wird. Ebenso erkennen Entwickler heute die Bedeutung des Load Balancing für die Skalierung von Anwendungen und nehmen es in der Regel in ihre Diagramme auf.
Dies spiegelt auch die zunehmende Zahl von Fällen wider, in denen Entwicklung und Betrieb die Verantwortung für die Skalierbarkeit übernommen haben und damit auch die Kontrolle über den Lastenausgleich ihrer Anwendungen. Das ist eine gute Entwicklung, denn dadurch können Dev und Ops den Lastenausgleich (mit all seinen Vorzügen auf Schicht 7) in die CI/CD-Pipeline integrieren – und tun dies hoffentlich auch –, insbesondere in der Testphase. So lassen sich potenzielle Probleme schnell erkennen und beheben, bevor die Anwendung in die Produktion überführt wird. Durch die Vorverlagerung des Lastenausgleichs in die CI/CD-Pipeline wird zudem ein ganzheitlicherer Ansatz für Continuous Delivery möglich, bei dem das gesamte Anwendungspaket (die Architektur) als Code verwaltet und gleichzeitig aktualisiert werden kann. Dadurch kann die Netzwerkinfrastruktur – denn dieser wird der Lastenausgleich traditionell zugeordnet – eine unveränderliche Architektur unterstützen, in der Anwendungen (oder Microservices, falls Sie diesen Ansatz verfolgen) mit neuen Konfigurationen vollständig neu bereitgestellt und nicht lediglich aktualisiert werden. So lässt sich die natürliche Softwareentropie vermeiden, die zu Herausforderungen und technischen Schulden führen kann.
Der Proxy ist in vielerlei Hinsicht die Brücke, die das „Netzwerk“ über die metaphorische Kluft hinweg (wenn wir ehrlich sind, gleicht sie eher einer Mauer) mit der „Anwendung“ verbindet – eine Kluft, die Software- und Netzwerkingenieure sowie -architekten voneinander trennt. Sie gehört zu den Gräben, die DevOps überwinden muss, damit Unternehmen skalieren und die Herausforderungen moderner Architekturen bewältigen können.
Ü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 ...