3 ms·

I used to work in supply chain logistics. Boy howdy, I am not surprised by any of this. Most companies (especially the older and more established ones) have z

I used to work in supply chain logistics. Boy howdy, I am not surprised by any of this. Most companies (especially the older and more established ones) have zero visibility into their supply chains. Suppliers don't share this information without a lot of arm-twisting. It's very much like being in dependency hell, except that the dependencies themselves are also in dependency hell. Edit: Shoutout to sourcemap.com, who are trying to solve this problem!

Ericson2314 5y ago
This is also why microservices are bad and libraries are good. Much better to have a copy of the IP than rely on some black box.
- eikenberry 5y ago
  Why not both? Better to run the service applications yourself. You have the IP and don't have the tech lock-in of a library.
  - Ericson2314 5y ago
    Composition of microservices is untyped, error-prone and once done has too many failure modes.
    - lolinder 5y ago
      Composition of microservices doesn't have to be untyped, it just almost always is in the current ecosystem. There's always an implicit contract in place between the services, and there's no reason that contract can't be encoded in types on both ends. (I agree in general that microservices aren't all they're cracked up to be, but lack of typing isn't an inherent flaw in the concept.)
      - Ericson2314 5y ago
        Yes it could be fixed, but even then I don't think it is worth it. The early language designers too got excited at the thought of generalizing subroutines to be able to suspend and resume rather than return once (especially before the call stack, where activation records are naturally ephemeral), but this was wisely abandoned. Later we see much interest in actor models, and they too are disergonomic, and a skeuomorphism from planning people. What's important is note the nodes, but the dataflow between them: programming is plumbing not connecting increasingly complicated pipe fittings. Most people get this dead wrong, and microservice are just the latest misunderstanding. All it has over the others is the unhealthy synergy with Conway's law.

Ericson2314 5y ago

This is also why microservices are bad and libraries are good. Much better to have a copy of the IP than rely on some black box.

eikenberry 5y ago
Why not both? Better to run the service applications yourself. You have the IP and don't have the tech lock-in of a library.
- Ericson2314 5y ago
  Composition of microservices is untyped, error-prone and once done has too many failure modes.
  - lolinder 5y ago
    Composition of microservices doesn't have to be untyped, it just almost always is in the current ecosystem. There's always an implicit contract in place between the services, and there's no reason that contract can't be encoded in types on both ends. (I agree in general that microservices aren't all they're cracked up to be, but lack of typing isn't an inherent flaw in the concept.)
    - Ericson2314 5y ago
      Yes it could be fixed, but even then I don't think it is worth it. The early language designers too got excited at the thought of generalizing subroutines to be able to suspend and resume rather than return once (especially before the call stack, where activation records are naturally ephemeral), but this was wisely abandoned. Later we see much interest in actor models, and they too are disergonomic, and a skeuomorphism from planning people. What's important is note the nodes, but the dataflow between them: programming is plumbing not connecting increasingly complicated pipe fittings. Most people get this dead wrong, and microservice are just the latest misunderstanding. All it has over the others is the unhealthy synergy with Conway's law.