> As tempting as it is to use SSH everywhere (for exactly the reasons outlined here), other protocols exist because they usually have some form of marginal gains over the alternatives, and marginal gains matter at scale.
I heard people "at scale" also use micro services over HTTP. Or even Rest for mobile apps, where latency is a real issue.
So I am not buying that part. I think HTTP (over TCP) has won because the web has won. As always technical people are overestimating the importance of technical aspects of a product and thereby their own importance, when really it is all about usability and network effects.
>I think HTTP (over TCP) has won because the web has won.
For sure. If I were building a mobile app that had to talk to a server, a RESTful API would be the first thing that comes to mind.
It's not the most lightweight protocol, but it's the protocol with a structure and interface that's designed for this -- making it a natural choice.
You could to a certain extent implement a REST-like API over SSH, or UDP for that matter, but that takes extra effort, and the fact of the matter is that many developers are just working on a higher level of abstraction, and lack the expertise to build new protocol. (My reasoning is that the lower barrier of entry into software development has created many developers with skillsets specialized in use of more "modern" technologies).
TL;DR -- IMO, using verbs to act on resources is easier to grok than working in terms of packets for most developers, and is sufficient in most situations. I still believe there are better alternatives for high-performance networking.
I heard people "at scale" also use micro services over HTTP. Or even Rest for mobile apps, where latency is a real issue.
So I am not buying that part. I think HTTP (over TCP) has won because the web has won. As always technical people are overestimating the importance of technical aspects of a product and thereby their own importance, when really it is all about usability and network effects.