Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wanted to make a similar point with piping UNIX commands. I can think of two reasons why the degradation happened:

1. Expansion of the software universe. Back in VB6 times, there were fewer programmers but many languages. Reusing components made with different languages was a big deal (VB used COM/ActiveX machinery to make this possible), but today there are so many more developers, that each language/ecosystem is big enough to exist on an island and happily not interact with anything unless it's a grpc/rest endpoint.

2. Transition to SaaS. We no longer use the same platform for building and running. Your VB app used to run on more or less the same computer it was built on. SaaS applications run in weird, custom-made, hard to reproduce and fragile computers called "environments". They are composed from all kinds of complex bits and this makes SaaS applications less portable. Frankly, they feel more like "environment configuration" than "code" sometimes.



The SaaS expansion could make componentisation easier - it would just be microservices, but from different companies. Somehow it doesn't. Possibly because it's not in their interest to do so.

On the other hand .. look at how much software goes into e.g. car entertainment systems. How many systems have "curl" in, for example. Have a look at the vast list of BSD license acknowledgements in many systems.

Look at the npm ecosystem, where people complain that there's too much componentisation.


Microservice has no new meaning (although a few content marketing teams may disagree). It's just a process with an input and output. Building applications consisting of multiple processes has been possible since forever. I would even argue that piping multiple UNIX commands together is a valid example of microservices :)


This is why containers are a _big deal_. They are bundling the "environment" with the "code"

We don't fully get back to component reuse, but it makes the sharing of services much more feasible, and more portable as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: