Hacker News Reader

Comment by mm321 | Hacker News Reader

I think that i understand the argument, but things changed with the advent of microservices. Suddenly everything turned into a distributed system, and it is hard to cope without some understanding of the subject matter. This lecture series by Martin Kleppman has helped me quite a bit here: https://www.youtube.com/watch?v=UEAMfLPZZhE&list=PLeKd45zvjc... Also see his book 'Designing Data-Intensive Applications', which is more focused on discussing practical systems.

View on HN

> but things changed with the advent of microservices.

Microservices is just a marketing buzzword invented by container orchestration start-ups. Partitioning of large applications across multiple inter-connected processes has been around for decades. Your computer is packed with microservices.

On Linux, type `watch date` and enjoy two microservices running and interacting. On Windows, observe a dozen of svchost.exe processes in the Task Manager.

i don't know about marketing, but things are much more simple, when everything is running on the same machine. There are fewer points of failure, ipc latencies are significantly lower, you are looking at the same system clock (unless you are looking at rdtsc, which is core specific). It's not quite the same, in practical terms.

We got some of the distributed aspects, when we got multiple processor cores and multiple cpus, but it's still not exactly the same thing.

I have the impression that the microservice architecture lowers the... 'activation energy', if you will, of building components that operate in a different paradigm. It's intensely pursuing the idea that a subservice is only its interfaces. And behind each of those curtains, it would be practical to construct something really weird.

Of course, it's cheaper and intellectually less stressing to just pop up a container, so that's what everyone does... so far. I mean, you need a TCP/IP stack somewhere.

Perhaps a microservice component embodied entirely on a GPU is an easily accessible example, or on one of those fancy ML-specific processors in the bowels of Google..

Since 2000, we have been building new stuff on top of the already established OS and system-level abstractions, without ever questioning their adequacy in these new configurations. Virtualization and containerization have certainly developed and enabled new modes of deployment and maintenance, but they still play with the decades-old x86 ISA and spin up a Unix-like OS with a decades-old process state model and everything-is-a-byte-stream-mindset. Fundamental computing research should start from the ground up without any concerns for portability and industrial viability. It should demonstrate new abstractions for new classes of problems, without carrying the burden of legacy.

Distributed systems were already a thing in early 1990's timesharing systems, Sun used to have "The network is the computer" slogan for a reason.

You are right, of course. However thin clients weren't such a big hit, and a workstation did cost half a fortune. All this was a bit remote, to me, at least.

Naturally they were only a reality in university campus and big companies, my first thin clients were X Windows IBM terminals and green phosphor text ones used to connect into DG/UX used on campus.

I once worked at a shop that developed slightly more modern GUI clients for their mainframe systems, we got TN3270 emulators. fun!

Reply on news.ycombinator.com