The design pattern and paradigm that was invented a very long time ago.
Circa 1970s. Many decades ago, before Functions-as-a-Service, Microservices and Containers were coined; pioneers of the UNIX operating system including Bill Joy (csh), Stephen Bourne (bash), David Korn (ksh) and other visionaries had already invented the modular operating pattern and paradigm that define those terms.
It’s architects had decided that every UNIX command would be narrowly-scoped to supply one elementary function, and to do that well. The commands were also required to accept input FROM and direct output TO the UNIX Standard I/O streams. And finally, they equipped their UNIX shell with three simple-to-use operators that provided the means to arbitrarily direct those streams between any pair of commands — for example, subscribing the input of command-A to the output of command-B. These humble operators were: Pipe (|), Redirect (<, >) and Background (&).
Using these ideas, it’s architects made building things atop UNIX accessible to virtually everyone. The design pattern allowed any user to easily chain elementary commands in succession to compose services of arbitrary complexity and specification. Those core commands then, were and are equivalent to today’s microservices. And equivalence doesn’t end there: Like their modern descendants, each command participating in the chain also run in their own just-in-time container—that is, the forked child-processes of their parent shell.
Let’s now appreciate the power of this design: To create higher-order services / functions, developers —typically Systems Administrators — needed only to envision the desired composite behavior, as well as be familiar with the standard UNIX command set (again, “microservices” or “API” if you prefer). But that’s it: Other than knowing the syntax of the three shell–assembly-operators, understanding the complex machinery beneath the shell itself wasn’t needed at all.
This is absolutely stunning when you think about it: Perhaps by now literally billions of arbitrarily complex ad-hoc CLI commands, as well as shell scripts have been successfully composed and run; despite authors with differing skill levels never giving a passing thought as to what actually happens behind the curtain — which is incredibly complex. That was the whole point of their lasting architecture!
And by the way, what ever became of all those trivial one-trick-pony, standard UNIX commands anyway? Well, precisely because of this snap-together design pattern — which I call Microservices ’77 — those commands (“microservices”) have suffered neither code-rot, nor diminished in relevance.
In fact, they remain the bedrock of everything built today: Elementary UNIX commands are regularly chained together by users in ad-hoc command line sessions; or they are being assembled inside files using logic and input parameter handling; and whose Fully-Qualified-PathNames point to shell-scripts that essentially represent URIs to callable API endpoints. Imagine that.
The imaginative pioneers of the UNIX operating system avoided the monolithic trap that would confound I.T. and application developers in the decades that followed; instead delivering a modular system by providing a directory of singularly-purposed microservices (i.e. the standard UNIX command library); along with three simple tools to arbitrarily snap those microservices together towards some larger end.
Was that vision not a stunning success? The pattern was so well-thought-out that we don’t even realize how much we rely on it all these years later.
Microservices ’77 is a time-tested, proven and hugely successful pattern and paradigm that is being visited upon us again, today. This post is my homage to its original inventors and greatest pioneers.