Ein Business Case für HTTP/2

HTTP/2 wurde im Hinblick auf die Leistung entwickelt.

Dennoch scheint es einfach, ein Geschäftsmodell auf der Grundlage der Tatsache zu entwickeln, dass Leistung das A und O ist, insbesondere wenn es um mobile Apps geht. Unabhängig davon, ob die Kosten in Produktivität oder Gewinn gemessen werden, ist eine schlechte Leistung immer ein bedeutender Kritikpunkt, den Verbraucher im Zusammenhang mit dem Kauf, der Nutzung und Verwendung mobiler Anwendungen ansprechen.

Aber das ist der einfache Fall. Diese Antwort kann jeder einfach durch die Untersuchung einer Flut von Umfragen zu diesem Thema stellen. Wir alle wissen, dass Verbraucher und Mitarbeiter unruhig werden, wenn eine App nicht innerhalb von 5 Sekunden oder weniger reagiert. Angesichts der Tatsache, dass Unternehmen neben der Migration zu HTTP/2 eine große Bandbreite leistungsbezogener Dienste zur Verfügung steht, mit denen sie das Problem lösen können, sind möglicherweise stärkere Impulse erforderlich, bevor sich Unternehmen mit der endgültigen Entscheidung, dass sie „Cloud First“-Unternehmen sind, für die Migration zu HTTP/2 entscheiden.

Bedenken Sie also, dass viele der Funktionen von HTTP/2 aus dem Verständnis dessen entstanden sind, was Entwickler in HTTP/1.1 so oft umgangen haben, dass es zur Standardpraxis wurde . Praktiken wie Inlining, Verkettung und Domänen-Sharding. Obwohl all diese Maßnahmen zu Leistungsverbesserungen beitrugen, führten sie leider alle zu technischen Schulden, die auch heute noch Entwickler und Betrieb gleichermaßen belasten. Durch die Migration auf HTTP/2 können diese Vorgehensweisen als Quelle technischer Schulden künftig eliminiert werden und es wird ein Weg geboten, die heute bestehenden Schulden „abzuzahlen“.

Technische (und architektonische) Schulden entstehen durch Entscheidungen . Es werden Entscheidungen darüber getroffen, welche Technologie übernommen, welches Produkt gekauft und welche Architektur implementiert werden soll. Es können auch Entscheidungen darüber getroffen werden, wo in der Anwendungsarchitektur eine bestimmte Lösung implementiert wird.

Einige Einschränkungen von HTTP/1.1 wurden von Entwicklern beispielsweise durch das Inlining kleiner Bilder und die Verkettung kleiner Dateien umgangen. Dadurch wurde tatsächlich die Leistung verbessert, allerdings fiel dadurch die Option des Cachings zusätzlicher Anwendungen (im Netzwerk) weg. Es erforderte auch während des App-Lebenszyklus Aufmerksamkeit, da jede Änderung an diesen eingebetteten Bildern oder den Dateien, aus denen die einzelne verknüpfte Datei besteht, in jeder Anwendung widergespiegelt werden muss.  Der Mangel an Modularität ist eine Quelle technischer Schulden, die bestehen bleibt, solange die Anwendung im Einsatz ist.

Technische Schulden müssen, wie echte Schulden, bedient werden. Das hat seinen Preis: Zinsen. Mit jeder Änderung und jeder Aktualisierung steigt dieses Interesse. Es erfordert Zeit und Aufmerksamkeit des Entwicklers. Es erfordert Testressourcen. Es erfordert Netzwerk- und Rechenressourcen. Dies führt dazu, dass das Unternehmen mehr Zeit mit der Bedienung seiner „Schulden“ verbringt als mit Innovation oder Expansion. Darüber hinaus fällt es dem Unternehmen schwer, von neuen Technologien, Methoden und Architekturkonzepten zu profitieren, die Wettbewerbsvorteile bieten.

Diese Schulden müssen beglichen werden. Eigentlich schon beseitigt, aber zumindest muss das Problem angegangen werden.

Der Schuldenkreislauf von HTTP/1.1 lässt sich durch die zukünftige Einführung von HTTP/2 beenden. Indem HTTP/2 eine breite Palette technischer und protokollbezogener Einschränkungen behebt, bietet es Entwicklern eine Möglichkeit, sich von den Workarounds der Vergangenheit zu lösen und in Zukunft andere Entscheidungen zu treffen. Entscheidungen, die nicht mit technischen Schulden verbunden sind. Vorhandene Anwendungen behalten diese Schulden zwar, können aber durch Anwendungen verschoben oder ersetzt werden, die HTTP/2 verwenden und sowohl Entwicklung als auch Betrieb von den Beschränkungen befreien, die ihnen durch die alten Standbys für HTTP/1.1 auferlegt werden.

Bei HTTP/2 geht es nicht nur um ein schnelleres Protokoll und schnellere Apps. Es geht auch darum, Beschränkungen bei Entwicklung und Betrieb zu beseitigen, diese von technischer Schuld zu befreien und Unternehmen die Chance zu geben, andere Wege zur Leistungssteigerung zu nutzen. Es handelt sich dabei um Methoden, bei denen die Gefahr geringer ist, dass technische oder architektonische Schulden entstehen, die Unternehmen davon abhalten, im Rennen um den Sieg im Anwendungsspiel die Oberhand zu gewinnen.