4 ms·

I think it should be possible to buy or use software from third parties. One thing I'm disappointed about and think we need better tools to avoid is the fact th

I think it should be possible to buy or use software from third parties. One thing I'm disappointed about and think we need better tools to avoid is the fact that third parties provide their tools as services rather than libraries. There's reasons they do that, deploying a library that all your customers can easily use is hard right now, but there's no reason it has to be that way. Some things can't easily be libraries like databases, but other things like some caches, miscellaneous operations like image resizing (depending on an architecture that can handle the load on those servers), and a bunch of other things could just be libraries.

nemetroid 6y ago
> Some things can't easily be libraries like databases The world's most widely deployed database engine (SQLite) is only available as a library.
- tlarkworthy 6y ago
  The worlds most trafficked database is probably Google search* index and its not sqlite and it's certainly distributed. * Maybe Facebook, I dunno, the point stands.
  - tosserup478 6y ago
    Modern browsers all use sqllite, so more than 90% of user accessing that index are doing through an app using sqllite. Lot’s of things come with sqllite without you knowing about it
    - tlarkworthy 6y ago
      Good point, though the Google index users are 1. the google search users AND 2. the machine crawlers who crawl webpages no-one visits. I am not sure the human users of the index are the majority. Admittedly this is a fairly pedantic point.
tlarkworthy 6y ago
The world is distributed. Money is distributed. You need services to interact with the world. The large portion of useful business services cannot be encapsulated into a hermetic library. If you think that distributed service clients as libraries is enough to solve the issue of distributed computing, that is incorrect as most of the same distributed systems crap will still happen.
- kortex 6y ago
  Totally agree. I have found that all of the pain points OP article mentions, are things that still crop up in monoliths, and by hardening against them, the app is more antifragile. Ex: Fragile: writing fault tolerant (because the endpoint is unreliable) hedges against the case when unforseen conditions throw a spanner into the works. Async/Laggy: some operations just take longer. Being able to gracefully route control flow around blockages improves performance. Pipes: I've found it's helpful to have ser/de interfaces throughout the program, as it forces you to use immutable data structures - aka functional programming. This helps reduce state space. Put together, I find having various "shear lines" in a monolith codebase, where I could split into a service if I wanted, greatly improves robustness.

nemetroid 6y ago

> Some things can't easily be libraries like databases The world's most widely deployed database engine (SQLite) is only available as a library.

tlarkworthy 6y ago
The worlds most trafficked database is probably Google search* index and its not sqlite and it's certainly distributed. * Maybe Facebook, I dunno, the point stands.
- tosserup478 6y ago
  Modern browsers all use sqllite, so more than 90% of user accessing that index are doing through an app using sqllite. Lot’s of things come with sqllite without you knowing about it
  - tlarkworthy 6y ago
    Good point, though the Google index users are 1. the google search users AND 2. the machine crawlers who crawl webpages no-one visits. I am not sure the human users of the index are the majority. Admittedly this is a fairly pedantic point.

tlarkworthy 6y ago

The world is distributed. Money is distributed. You need services to interact with the world. The large portion of useful business services cannot be encapsulated into a hermetic library. If you think that distributed service clients as libraries is enough to solve the issue of distributed computing, that is incorrect as most of the same distributed systems crap will still happen.

kortex 6y ago
Totally agree. I have found that all of the pain points OP article mentions, are things that still crop up in monoliths, and by hardening against them, the app is more antifragile. Ex: Fragile: writing fault tolerant (because the endpoint is unreliable) hedges against the case when unforseen conditions throw a spanner into the works. Async/Laggy: some operations just take longer. Being able to gracefully route control flow around blockages improves performance. Pipes: I've found it's helpful to have ser/de interfaces throughout the program, as it forces you to use immutable data structures - aka functional programming. This helps reduce state space. Put together, I find having various "shear lines" in a monolith codebase, where I could split into a service if I wanted, greatly improves robustness.