4 ms·
I’m currently reading The Great Mental Models. The part I’m reading now is called The Map Is Not The Territory, and it is about formulating abstractions. In th
by yakshaving_jgt 4y ago
I’m currently reading The Great Mental Models. The part I’m reading now is called The Map Is Not The Territory, and it is about formulating abstractions.
In this chapter, the author reminds us that we run into problems when our knowledge is that of the map we’re reading, rather than that of the territory it describes.
I don’t think a network of micro-services is analogous to a chain of small UNIX programs piped together. Those aren’t pipes between micro-services; they’re web servers and network requests. It’s a whole different ball game.
The abstraction is an attractive one, and perhaps it’s why micro-services are all we’ve been able to talk about for the past decade. But it’s still not a good abstraction. It’s an oversimplification.
- shreyshnaccount 4y agoI dont get it, care to elaborate?
- yakshaving_jgt 4y agoI mean I don't agree with the analogy that the author has drawn between a micro-service architecture and UNIX programs piped together, because I don't believe inter-process communication through streams is comparable to HTTP requests over the internet. Put another [less accurate] way: a function call is not the same as a network request. The analogy the author has drawn in the article is a kind of mental model — an intentional oversimplification — intended to convey an idea. It's useful to use mental models like this, but only if you have sufficient understanding of the underlying mechanics that you're abstracting over in order to determine whether the abstraction is useful, or if it's harmful. In my opinion, because the underlying mechanics are so different, the mental model isn't actually useful. The author writes: > The idea can be applied to the web in a similar way. Many modern web applications are choosing to build out their architecture as a set of services that communicate over the network layer, which has some parallels with the Unix model of programs that communicate via OS primitives. I just don't agree with this. The author appropriately recognises that this kind of architecture often makes it considerably harder for us to manage shared context, but elides that other serious drawback that I've described.