Why Sponsor Oils? | blog | oilshell.org
In December, I reviewed eight 2021 posts on #software-architecture. This post goes deeper in that direction, showing diagrams of the narrow waist idea.
When you hear the term, you should picture an hourglass with M things on one side, N on the other, and an important concept in the middle. Recap:
Let's start with 2 diagrams I found about the architecture of the Internet itself.
The "IP" in TCP/IP stands for the Internet Protocol. It was developed by Vint Cerf and Bob Kahn, who described it in 1974. It allows interoperability between applications on the top and physical transports on the bottom.
For example, I started using the web in the 90's with a PC connected to a modem, connected to a phone line. (Guitar tablature was a type of text that traveled well over slow networks!)
In the next few decades, I used the Internet over Ethernet at college, over wires meant for cable television, over DSL from the phone company, with wireless routers, and with cell phones.
At no point did a web page author have to do anything to make this work! This is because web browsers and servers both use the Internet abstraction. (I'm mixing up some layers, but my ignorance is part of the point — it just worked.)
So in networking, the idea of a narrow waist is used and taught explicitly.
But we don't pay enough attention to this idea in software — particularly in the modern "cloud". In the next few posts, I'll review some Unix fallacies, i.e. local complaints which are ignorant of the large scale architecture.
The first e-mail applications did not use the Internet; they were directly coupled to a local, physical network. You could send messages to your coworker, but not to your family across the ocean.
Moreover, you had to rewrite or port the app if you wanted to use different hardware, e.g. a wireless network instead of wired. You also had to rewrite or port your file transfer application.
So instead of just one e-mail application, you had N e-mail apps that worked on N networks. And this was true for each of M applications, giving O(M × N) amounts of code.
These days, each application uses the Internet, and each local network supports the Internet, which is an O(M + N) amount of code.
2/28 Update: Reader CheCheDaWaff reminded me that The Dream Machine by
Waldrop covers the development of the Internet in great detail. I read it in
2018 and mentioned it in this
blog!
My point is that we take narrow waists for granted, like the air. But real people put a lot of effort into designing and inventing them!
I think we're still writing distributed systems the "wrong" way, with O(M × N) amounts of labor. This blog post from August goes deeper into that:
Unix and Microservice Platforms (blog.deref.io, 6 months ago)
45 points, 18 lobste.rs comments
97 points, 36 Hacker News comments
A major point is that crosscutting concerns like authentication, authorization, metrics, monitoring, alerting, and deployment are done for each service and for each programming language, leading to code explosions (and language wars). It cites the excellent Unix vs. Google video, which makes an analogy to Multics. (This discussion is similar but not identical to Kubernetes is Our Generation's Multics.)
With hindsight, this way of building systems now will seem as silly as throwing out your software when you buy a new computer. We should explicitly think about new narrow waists and fix old ones, like the shell.
I made two diagrams to show where this line of thought is going. Upcoming posts will substantiate and elaborate on them.
This diagram shows that using the common abstraction of byte streams allows essential generic / polymorphic operations, avoiding O(M × N) amounts of code.
Slogans:
An important special case of byte streams is human-readable text. When you represent data with plain text, you get useful operations and tools for free.
This isn't a theoretical issue; it has big consequences. This economy of engineering is why Unix and the Internet have been so successful.
It's also why programmers of all types lament the pervasiveness of text. I understand why: both #parsing and serialization are laborious, and have associated security problems. (String hygiene is still in the blog queue).
But I claim that programmers disregard system issues in favor of local convenience. And that we use poor abstractions provided by interested vendors. These abstractions don't interoperate, leading to bigger problems than parsing.
Slogan: Unix and the Web Are Equally Inconvenient for Every Programmer, And That's Good.
(Help wanted: I made these SVG diagrams with https://diagrams.net, and I want to illustrate more narrow waists. So it would be nice to generate them with a parameterized program. Can a reader get me started, e.g. with a pikchr or asymptote script?)
I started these drafts:
While I write these articles, you may want to review Retrospective: Software Architecture, published December. It turned into a pretty good post with concrete claims and project updates!
My main goal is to "re-justify" the effort put into OSH, and the design of the new Oil language. This project has a difficult design and implementation because it sits at the center of many strong forces in architecture.
But I also think narrow waists are worth describing and thinking about independent of Oil. It's interesting and underexplored idea. More claims:
I suppose there are two closely related but distinct claims here:
I'd like to better understand the history of this idea. (You could even call it a meta-idea — an idea about ideas.) I asked for references in previous blog posts but I don't recall any noteworthy responses.
I think it's complicated by the varied terminology:
The earliest writing I can find on it is a 1994 government publication, via this Berkeley article:
So I would like help finding references to narrow waists, interoperability, and O(M × N) code explosions! The idea is central in compilers (IRs) and operating systems as well, but I don't see a lot of explicit writing about it.
Here are some more links I dug up:
After publishing this article, I found an earlier source for the hourglass / narrow waist idea in the networking domain.
Reader Caleb Malchik pointed out a more convincing origin story for the narrow waist idea — both the analogy and the technical work itself!
The first 10 minutes of this talk by Van Jacobson are amazing:
Watching NDN's Waist (October 2019, YouTube)
Summary:
I wasn't aware of this, but there are big echoes of Ken Thompson's design philosophy, which I covered in Unix Shell: History and Trivia.
Jacobson also mentions the explicit desire for vendors to lock in their customers.
Aside: In 2006, I attended a talk by Van Jacobson on Named Data Networking at Google. It proposes a new and explicitly designed narrow waist for the Internet. This talk is probably a major reason this idea stuck with me for the last 14 years!
Here are more links that show that the narrow waist idea is explicit in networking.
This paper convinced me that the idea is important. It has engineering consequences and predictive power! The fact that the narrow waist moves and evolves is fascinating. (Counterpoint: Fuck It, Overload HTTP and comments. This article has some substantial misunderstandings that I could write about later. This is another argument about local convenience vs. system integrity.)
Another article about a moving waist:
These articles make use of the model, although I see their main ideas as experimental: