Making the Business Case for HTTP/2

HTTP/2 was developed with performance in mind.

That being said, it seems simple to make a business case based on the reality that performance is king, particularly when mobile apps are involved. Whether costs are measured in productivity or profit, poor performance is always a significant issue raised by consumers with respect to their purchasing on, engagement with, and use of mobile applications.

But that’s the easy case. Anyone can make that one simply by examining a spate of surveys on the subject. We all know if an app doesn’t respond in 5 seconds or less that consumers and employees alike get fidgety. Given that there are, outside of moving to HTTP/2, a wide variety of performance-related services available for organizations to use to address the issue, there may need to be more of an impetus provided before organizations decide to move to HTTP/2 with the definitiveness they have determined they are “cloud first” businesses.

Consider, then, that many of the capabilities in HTTP/2 grew out of understanding what it was that developers worked around so often in HTTP/1.1 that it became standard practice. Practices like inlining, concatenation, and domain sharding. While these all contributed to improvements in performance, each one unfortunately incurred technical debt that is even now weighing down developers and operations alike. Migrating to HTTP/2 can eliminate those practices as a source of technical debt moving forward and provides a path to “pay off” the debt that exists today.

Technical (and architectural) debt is incurred by choices. Choices made regarding which technology to adopt, which product to purchase, which architecture to implement. It can also come from decisions based on where in the application architecture a particular solution will be implemented.

For example, some limitations with HTTP/1.1 were circumvented by developers with inlining of small images and concatenation of small files. This did, in fact, improve performance but at the cost of eliminating extra-application caching (in the network) as an option. It also required attention during the app lifecycle as any change to those inlined images or the files comprising the single concatenated file need to be reflected in every application.  The lack of modularity is a source of technical debt that will continue as long as that application is in service.

Technical debt, like real debt, requires servicing. It comes at a price – interest. With every change and every update that interest compounds. It requires developer time and attention. It requires testing resources. It requires network and compute resources. This leaves the organization spending more time servicing its “debt” than it does on innovation or expansion, and makes it difficult to take advantage of new technologies, methodologies, and architectural concepts that offer competitive advantages.

This debt needs to be addressed. Eliminated, actually, but at a minimum it needs to be addressed.

For HTTP/1.1 the means to end the debt cycle of HTTP/1.1 is to adopt HTTP/2 moving forward. By addressing a wide array of technical and protocol limitations, HTTP/2 offers a way for developers to walk away from the workarounds of the past and make different choices moving forward. Choices that don’t come laden with technical debt. Existing applications retain that debt, yes, but can be moved or replaced by applications that use HTTP/2 and free up both dev and ops from the constraints placed upon them by the old standby’s for HTTP/1.1.

HTTP/2 is not just about a faster protocol and apps. It’s also about eliminating constraints on dev and ops that free them from technical debt and afford organizations the opportunity to take advantage of other ways of improving performance. Ways that are less likely to incur the kind of technical or architectural debt that will hold business back from winning in the race to win in the game of applications.