The Zen of Multiplexing and Other Software Engineering Fallacies

Technologies that are related to software engineering, occasionally produce the following phenomenon; they occasionally re-invent the wheel. Not only that, but these technologies are presenting themselves as mind-blowing, we-are-going-to-save-the-world of solutions.

Not so long ago, IP Networking was invented and people thought that it would be cool to have several services multiplexed on the newly founded network data channel. They conceived the ports on the Transport Layer. Ports were numbers assigned to specific services; thus we had the 80 port for the HTTP service, 22 for secure shell (SSH), 20 and 21 for FTP, etc.

So far, so good, but it seemed that our fellow software engineers were not happy with that approach, and they decided to do something else instead. First, the idea of permitting only HTTP port (80) appeared. All other ports were designated as insecure (!) and one-by-one network administrators closed them with firewalls. But the need to multiplex was still there, and the re-invention pattern became a reality. The concept was simple; all protocols (or at least a lot) and new services were designed to work over HTTP. Of course, I’m not against the RESTfull approach, but to see all protocols to be abandoned for the sake of one protocol, does not seem logical also. I think we need to find the Golden ratio on this matter.

What goes around, comes around

The insecure port mechanism gave its place to a new set of vulnerabilities, like SQL injections, cross-site scripting, etc. In addition, modern approaches appeared and many services were rewritten from scratch, utilising the new paradigm.

But in reality the gain was minimal, firewalls were replaced by intrusion detection systems that made deep packet inspections, to identify if the packets transferred over HTTP were indeed legal. All protocols were replaced by HTTP, thus inheriting both its good and bad characteristics

In addition, after HTTP/2 and HTTP/3 we finally understood that JSON and HTTP are not that good, especially for internal microservices, thus we are adopting technologies like gRPC etc.

The Final Frontier

It seems that there will never be an end to this. Software engineers seem that they feel the need to reinvent the wheel (or parts of it) every now and then, enforcing their clients to pay costly software rewrites.

Of course, many of those alterations contain improvements, sometimes significant ones, but I think that all these is a matter of control. Maybe programmers think that it is better to control all aspects of the software. The multiplexing of services are significant and cannot be left to the operating system or the network to handle it. But the question is, who pays the bill?