The Unix philosophy has proven inadequate to meet the needs of real-world software integration
I'm assuming that's why it's so trendy to talk about "microservices" these days.
What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs.
The Unix philosophy doesn't say anything against implementing service discovery mechanisms.
...if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.
My God, "pathologically neckbearded". That's just rich. Let's shit on everyone who shows us different ways of building systems that allow for greater composability and emergent features.
The Unix philosophy doesn't say anything against implementing service discovery mechanisms.
It's less about service discovery mechanisms per se. It's more about using objects communicating via APIs as units of composition, rather than processes communicating via data (usually text) streams. The object-based approach hews closely to how programmers actually think, makes protocol specification as easy as declaring a method (and checked by the compiler!), and enables much more sophisticated interaction between components. See Miguel de Icaza's essay "Let's Make Unix Not Suck" for an in-depth look at how the COM model improves on Unix philosophy for software integration: http://baizid.org/literature/bongo-bong.html
What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs.
There is a real tension between RPC-orientated systems and protocol-orientated systems. The RPC and distributed object model (COM,DCOM,CORBA) produces tightly coupled systems that provide more functionality if all parts are from the same vendor/team. The protocol-orientated style gives us the RFC protocols with a much wider diversity of implementations.
The question is which application developers do you make happy. The Windows/GNOME style is a single system with lots of moving parts that can't be individually replaced. One of the attractions of UNIX has been its hetrogeneity.
I'm assuming that's why it's so trendy to talk about "microservices" these days.
What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs.
The Unix philosophy doesn't say anything against implementing service discovery mechanisms.
...if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.
My God, "pathologically neckbearded". That's just rich. Let's shit on everyone who shows us different ways of building systems that allow for greater composability and emergent features.