[HN Gopher] Unix and Microservice Platforms
___________________________________________________________________
Unix and Microservice Platforms
Author : brandonbloom
Score : 84 points
Date : 2021-08-02 17:15 UTC (1 days ago)
(HTM) web link (blog.deref.io)
(TXT) w3m dump (blog.deref.io)
| skissane wrote:
| > Write programs to handle text streams, because that is a
| universal interface.
|
| I wish they'd invented a simple structured data model, like JSON,
| and exchanged that rather than plain text.
| pjmlp wrote:
| > See, the brilliance of Unix didn't stop at functional
| orthogonality, they also used C: A high-level programming
| language, as compared to machine-specific assembly code. Once
| Unix started getting ported to new hardware architectures, the
| two-dimensional implementation matrix becomes three-dimensional.
|
| 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.
| miohtama wrote:
| Google has taken a stepmto this direction with Fuchsia. To
| replace the Linux kernel under Android/ChromeOS and maybe later
| the servers. But it will be a massive undertaking due to
| massive sunken cost in the UNIX legacy.
| pjmlp wrote:
| Yes, but if no one ever spends the money, it will never
| change.
|
| 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.
| formerly_proven wrote:
| Linux isn't Unix: commercial Unix already got obliterated
| by Linux (and the dotcom bubble, Itanium). Completely
| different development model, vastly different capabilities.
| MisterTea wrote:
| > If anything, I am looking forward to the cloud platforms to
| replace UNIX.
|
| 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
|
| > UNIX, hypervisor, Linux, Windows, bare metal,...., I just
| don't care.
|
| Then you don't need to worry about "looking forward" to replace
| any of those things.
| pjmlp wrote:
| Plan 9 failed because Bell Labs management did not care
| enough, and eventually placed the team into the Inferno
| project to try fight against Sun and Java, that is why.
|
| 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.
| dotcommand wrote:
| > "Code the Perimeter" is the key insight of Kevin Greer's
| fabulous 2016 analysis of why Unix beat Multics
|
| 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.
| pjmlp wrote:
| Multics failed for Bell Labs, it was quite useful for others,
| and in a DoD security assessemnt even proved more secure than
| UNIX thanks to PL/I.
|
| https://multicians.org/myths.html
| dboreham wrote:
| Very interesting also for insight into "what were they trying
| to do?". In several cases this was actually "facilitate
| printing bell labs technical papers without paying a printing
| company". Also interesting that the first part of Unix to be
| developed, and it was done as a stand alone project not with
| the goal to become a full OS, was the filesystem.
| foobarian wrote:
| It's amazing how much of modern computing infrastructure was
| inspired by printers. Richard Stallman's almost entire life's
| work comes to mind.
| giantrobot wrote:
| Consider big companies before departmental printers. A memo
| would be typed and then have to go to the reprographics
| department for copies or typing pool. Anything more complex
| than a memo would need to go to an outside printer to be
| typeset and printed.
|
| 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.
| macintux wrote:
| And laser printing was a key factor in the Mac's early
| success.
| smhenderson wrote:
| And now a favorite goal of small/medium business is to
| use computers to go completely paperless.
| richardfey wrote:
| Don't microservices using shared code correspond to going back to
| a monolith in disguise?
| azaras wrote:
| No. Sharing code is good. Sharing memory bad.
| jjtheblunt wrote:
| perfectly said!
| discreteevent wrote:
| Sharing memory is pretty easy when you have a garbage
| collector. Even if you have concurrency you can use messaging
| without having to put the communicating components into
| separate processes. And having separate garbage collected
| virtual machines wastes a lot of memory if you want to have
| enough headroom for performance in each one.
| dboreham wrote:
| In the same sense that a set of C binaries that uses libc is a
| monolith?
| richardfey wrote:
| Only if your company develops the equivalent of libc and it
| is clearly in scope for its business.
| [deleted]
| Animats wrote:
| Multics required unusual hardware that was expensive at the time.
| The hardware was abandoned by GE and taken over by Honeywell.
| Honeywell, which made thermostats then and makes thermostats now,
| was never a major player in computing. The big advantage of UNIX
| was that it runs on vanilla hardware.
|
| 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.
| overtomanu wrote:
| Doesn't service mesh seem similar to enterprise bus in SOA?
| gunapologist99 wrote:
| exactly. what's old is new again.
| flerovium wrote:
| I would like to see the details of what primitives the author
| considers important (the "columns" of the perimeter diagram).
| brandonbloom wrote:
| Hi, author here.
|
| 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.
| flerovium wrote:
| In many ways, AWS's insistence on proprietary vs. universal
| open-source and the lack of interoperability with other cloud
| providers is itself "coding the area", turning an O(N+M)
| problem into an O(N*M) one.
| _sheep wrote:
| AWS's console UI is a pretty good sign of "coding the area"
| as well. So many subtle inconsistencies in the UI with
| navigation structure, pagination, filtering/search with all
| of their different services.
| thom wrote:
| Some truly baffling dataviz in this article, which really
| underlines the 'do one thing well, stick to text' message of the
| article.
| [deleted]
___________________________________________________________________
(page generated 2021-08-03 23:01 UTC)