Die geschäftlichen Vorteile von HTTP/2 überzeugend darlegen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

HTTP/2 wurde mit Blick auf eine hohe Leistung entwickelt.

Dennoch lässt sich offenbar leicht ein überzeugender Business Case auf der Tatsache aufbauen, dass Performance das A und O ist – insbesondere bei mobilen Apps. Unabhängig davon, ob die Kosten anhand von Produktivitätseinbußen oder entgangenem Gewinn bemessen werden, ist eine schlechte Performance für Verbraucher im Zusammenhang mit Käufen über mobile Anwendungen sowie deren Interaktion mit und Nutzung von diesen stets ein erhebliches Problem.

Aber das ist der einfache Fall. Zu diesem Schluss kann jeder gelangen, indem er sich einfach eine Reihe von Umfragen zu diesem Thema ansieht. Wir alle wissen, dass Verbraucher wie Mitarbeiter unruhig werden, wenn eine App nicht innerhalb von fünf Sekunden reagiert. Da Unternehmen neben der Umstellung auf HTTP/2 eine Vielzahl leistungsbezogener Dienste zur Verfügung stehen, um dieses Problem zu lösen, bedarf es möglicherweise eines stärkeren Anreizes, bevor sie sich mit derselben Entschlossenheit für HTTP/2 entscheiden, mit der sie sich zu „Cloud First“-Unternehmen erklärt haben.

Bedenken Sie dabei, dass viele der Funktionen von HTTP/2 aus der Erkenntnis hervorgingen, welche Einschränkungen Entwickler in HTTP/1.1 so häufig umgingen, dass dies zur gängigen Praxis wurde. Dazu zählen Praktiken wie Inlining, Konkatenierung und Domain-Sharding. Sie alle trugen zwar zu Leistungsverbesserungen bei, verursachten jedoch technische Schulden, die Entwickler und Betriebsteams bis heute belasten. Durch die Migration zu HTTP/2 lassen sich diese Praktiken künftig als Quelle technischer Schulden beseitigen und zugleich bestehende Schulden „abbauen“.

Technische (und architektonische) Schulden entstehen durch Entscheidungen. Entscheidungen darüber, welche Technologie eingesetzt, welches Produkt gekauft und welche Architektur implementiert werden soll. Sie können auch durch Entscheidungen darüber entstehen, an welcher Stelle der Anwendungsarchitektur eine bestimmte Lösung implementiert wird.

Beispielsweise umgingen Entwickler einige Einschränkungen von HTTP/1.1, indem sie kleine Bilder direkt einbetteten und kleine Dateien zusammenfassten. Dies verbesserte zwar tatsächlich die Leistung, allerdings um den Preis, dass anwendungsübergreifendes Caching (im Netzwerk) nicht mehr möglich war. Zudem erforderte dies während des gesamten Lebenszyklus der Anwendung besondere Aufmerksamkeit, da jede Änderung an den eingebetteten Bildern oder an den Dateien, aus denen die zusammengefasste Datei bestand, in jeder Anwendung nachvollzogen werden musste. Die fehlende Modularität ist eine Quelle technischer Schulden, die so lange bestehen bleiben, wie die Anwendung in Betrieb ist.

Technische Schulden müssen ebenso wie reale Schulden bedient werden. Dafür fällt ein Preis an – Zinsen. Mit jeder Änderung und jeder Aktualisierung wachsen diese Zinsen weiter an. Dies bindet Zeit und Aufmerksamkeit der Entwickler. Es werden Ressourcen für Tests sowie Netzwerk- und Rechenkapazitäten benötigt. Dadurch verbringt das Unternehmen mehr Zeit damit, seine „Schulden“ zu bedienen, als mit Innovation oder Wachstum, und es wird schwieriger, neue Technologien, Methoden und Architekturkonzepte zu nutzen, die Wettbewerbsvorteile bieten.

Diese technischen Schulden müssen angegangen werden. Eigentlich müssen sie beseitigt werden, aber zumindest muss man sich mit ihnen befassen.

Um den Kreislauf der technischen Schulden von HTTP/1.1 zu durchbrechen, sollte künftig HTTP/2 eingesetzt werden. Indem HTTP/2 eine Vielzahl technischer und protokollbedingter Einschränkungen behebt, ermöglicht es Entwicklern, die bisherigen Behelfslösungen hinter sich zu lassen und künftig andere Entscheidungen zu treffen – Entscheidungen, die nicht mit technischen Schulden belastet sind. Bestehende Anwendungen behalten diese Schulden zwar bei, können jedoch migriert oder durch Anwendungen ersetzt werden, die HTTP/2 nutzen. Dadurch werden sowohl Entwicklung als auch Betrieb von den Einschränkungen befreit, die ihnen durch die altbewährten Notlösungen für HTTP/1.1 auferlegt wurden.

Bei HTTP/2 geht es nicht nur um ein schnelleres Protokoll und schnellere Anwendungen. Es geht auch darum, Einschränkungen für Entwicklung und Betrieb zu beseitigen, sie von technischen Altlasten zu befreien und Unternehmen die Möglichkeit zu geben, andere Wege zur Leistungssteigerung zu nutzen. Wege, bei denen die Gefahr geringer ist, technische oder architektonische Altlasten anzuhäufen, die Unternehmen daran hindern, im Wettlauf um den Sieg im Wettbewerb der Anwendungen erfolgreich zu sein.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

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