Unix and Microservice Platforms(blog.deref.io) |
Unix and Microservice Platforms(blog.deref.io) |
UNIX is all wrong for microservices. Interprocess communication barely existed at first, and it's still mediocre. QNX did this right, with a true message-passing architecture, and a message-oriented network protocol. (Reliable, any-length message, not just raw UDP packets.) QNX continues to power many real-time systems, passing messages around.
If UNIX was closed source, sold at the same price as the competition, whatever hardware it run on would have not mattered at all.
Yeah, like plenty of other OSes since the late 1950's.
Multics was also written in an high level language, PL/I.
If anything, I am looking forward to the cloud platforms to replace UNIX.
It doesn't matter what AWS runs on, as long as my language runtime, or Kubernetes runs there.
UNIX, hypervisor, Linux, Windows, bare metal,...., I just don't care.
That happened in the late 80's / early 90's and it was called Plan 9. And there was a reason it failed to fill its intended role:
[I]t looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.
— Eric S. Raymond
Then you don't need to worry about "looking forward" to replace any of those things.
The lesson is that if you want a project to succeed ensure management is on your side for the long road.
I still need to care, because the final decision what to use is not always on my table.
The main reason why alternatives failed so far it wasn't for lack of technical capabilities, rather companies not willing to put the money in for the long road it takes to reboot everything.
At least the majority of userspace applications are moving into the right direction, specially those being deployed on cloud environments on top of orchestrated runtimes, or the mobile phone apps.
My writing backlog includes a post defining what "good" looks like for a web service. I don't think most organizations are doing it well, or have their priorities straight.
Rumor has it that there is a 30+ page checklist if you work at AWS and want to launch a new service. Meanwhile, CloudFormation support still trails most new service launches and remains completely unavailable for many old services. These things suggest strongly that they are coding the area, not the perimeter.
I wish they'd invented a simple structured data model, like JSON, and exchanged that rather than plain text.
Brian Kernighan's "UNIX: A History and a Memoir" delves into why multics failed and unix was created and opinions on why unix succeeded ( something they really didn't anticipate ). It's a great book, broader than just unix - bell labs history, the people involved, computer history, etc.
JK, if Multics has TCP/IP and VT100 support (or even raw serial support), IRC, Gopher, E-Mail, News, and Telnet clients could be backported perfectly for Multics.
IF there's a Z Interpreter for Tops-20 on the KA10, I think a computer capable on running Multics should be able to run Zork.
> When the Computing Sciences Research Center wanted to use Unix on a machine larger than the PDP-7, while another department needed a word processor, Thompson and Ritchie added text processing capabilities to Unix and received funding for a PDP-11/20.[5] For the first time in 1970, the Unix operating system was officially named and ran on the PDP-11/20. A text-formatting program called roff and a text editor were added. All three were written in PDP-11/20 assembly language. Bell Labs used this initial text-processing system, consisting of Unix, roff, and the editor, for text processing of patent applications. Roff soon evolved into troff, the first electronic publishing program with full typesetting capability.
Which is what you want if the application is to be resilient to crashes and exploits from dynamicallly loaded code.
So you're looking at hours to days (weeks in the case of technical documentation) turn around time. All the labor was also very expensive.
Departmental printing could cut the turn around time to minutes or hours and reduce the manual labor significantly. This got cheaper and more accessible with desktop printing.
While e-mail is often abused anymore it's much more manageable than the reams of paper even relatively small companies had to deal with just to communicate internally.