4 ms·

As far as I can tell, there's no reason why any of the constraints you have described could not be solved with libraries, and a function call is always going to

As far as I can tell, there's no reason why any of the constraints you have described could not be solved with libraries, and a function call is always going to be less complex than a network request.

DasIch 5y ago
There are many reasons for why a library might not be sufficient. The most common one is that what you’re doing is stateful and requires some sort of data store. That has a huge impact because now you need to set up the data store and potentially perform migrations, which means you may need to change how you do deployments. It may introduce a bottleneck such as number of connections to that store, so you now have limitations to think about when scaling.
- Tabular-Iceberg 5y ago
  Why can't a library be stateful or have a data store? If you're using libpng to edit an image on your disk you are working with both state and a data store. Yet plenty of applications do this every day without feeling a need to call it over a network. And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network?
  - pm90 5y ago
    > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. To illuminate this a bit more suppose you do share such a library anyways. Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once.
    - Tabular-Iceberg 5y ago
      > You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. This is exactly the same as how libraries are supposed to be written. A stable public API so the user doesn't have to bother with internal implementation details. > Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once. You aren't forced to do that with libraries either. You don't have to statically link them at compile time, you can load them whenever you please.
  - DasIch 5y ago
    A library can be stateful or have a data store but that means the user of that library has to be aware of changes beyond the API and hat to operate this data store. > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? No only the team doing it has to. Users of a service only have to worry about the API that it exposes, which should ideally never change in backwards incompatible ways and if it does, you make sure everyone calling the API understands it and migrates and you break backwards compatibility only after everyone has migrated. As a user the implementation details of other services I don’t work on, don’t concern me. Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock.
    - Tabular-Iceberg 5y ago
      > A library can be stateful or have a data store but that means the user of that library has to be aware of changes beyond the API and hat to operate this data store. No, it does not mean that at all. Where are you getting this idea from? > Users of a service only have to worry about the API that it exposes Users of a library only have to worry about the API that it exposes too. What kind of libraries have you been using? > Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock. What's the difference between the two? The only difference that I can see is that the libpng and libwishlist wouldn't waste a network round-trip and lots of serialization and deserialization compared to a png service or whishlist service.
      - DasIch 5y ago
        Let's say you want to add redis for caching purposes. If a service does that, users of that service don't have to be aware of it. If a library does that, users of the library do have to be aware of that. Same problem applies, if your library suddenly wants to access another service (like S3 or some other AWS service). You can of course maintain a stable API in a library and you should but that restricts the changes you can do to that library. A service I could rewrite in another language without users noticing.
raffraffraff 5y ago
How do you ensure that everybody uses the correct version of the library? If a library change comes with a database schema change, how do you coordinate? With microservices, the owner of the service is responsible for the database schema change and service upgrade. Nobody else needs to be involved. (Genuine question, I'm an infrastructure guy, not a software engineer)
- yakshaving_jgt 5y ago
  Where I work, we use Haskell's type system to keep all of these boundaries in sync. All of the "services" we have extracted are indeed libraries. These libraries use type classes to interface with the core of our application which manages data persistence. This also means that each "service" can be written mostly in isolation and use a different data store (like an in-memory DB or something), depending on our needs.

DasIch 5y ago

There are many reasons for why a library might not be sufficient. The most common one is that what you’re doing is stateful and requires some sort of data store. That has a huge impact because now you need to set up the data store and potentially perform migrations, which means you may need to change how you do deployments. It may introduce a bottleneck such as number of connections to that store, so you now have limitations to think about when scaling.

Tabular-Iceberg 5y ago
Why can't a library be stateful or have a data store? If you're using libpng to edit an image on your disk you are working with both state and a data store. Yet plenty of applications do this every day without feeling a need to call it over a network. And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network?
- pm90 5y ago
  > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. To illuminate this a bit more suppose you do share such a library anyways. Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once.
  - Tabular-Iceberg 5y ago
    > You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes. This is exactly the same as how libraries are supposed to be written. A stable public API so the user doesn't have to bother with internal implementation details. > Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once. You aren't forced to do that with libraries either. You don't have to statically link them at compile time, you can load them whenever you please.
- DasIch 5y ago
  A library can be stateful or have a data store but that means the user of that library has to be aware of changes beyond the API and hat to operate this data store. > And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network? No only the team doing it has to. Users of a service only have to worry about the API that it exposes, which should ideally never change in backwards incompatible ways and if it does, you make sure everyone calling the API understands it and migrates and you break backwards compatibility only after everyone has migrated. As a user the implementation details of other services I don’t work on, don’t concern me. Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock.
  - Tabular-Iceberg 5y ago
    > A library can be stateful or have a data store but that means the user of that library has to be aware of changes beyond the API and hat to operate this data store. No, it does not mean that at all. Where are you getting this idea from? > Users of a service only have to worry about the API that it exposes Users of a library only have to worry about the API that it exposes too. What kind of libraries have you been using? > Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock. What's the difference between the two? The only difference that I can see is that the libpng and libwishlist wouldn't waste a network round-trip and lots of serialization and deserialization compared to a png service or whishlist service.
    - DasIch 5y ago
      Let's say you want to add redis for caching purposes. If a service does that, users of that service don't have to be aware of it. If a library does that, users of the library do have to be aware of that. Same problem applies, if your library suddenly wants to access another service (like S3 or some other AWS service). You can of course maintain a stable API in a library and you should but that restricts the changes you can do to that library. A service I could rewrite in another language without users noticing.

raffraffraff 5y ago

How do you ensure that everybody uses the correct version of the library? If a library change comes with a database schema change, how do you coordinate? With microservices, the owner of the service is responsible for the database schema change and service upgrade. Nobody else needs to be involved. (Genuine question, I'm an infrastructure guy, not a software engineer)

yakshaving_jgt 5y ago
Where I work, we use Haskell's type system to keep all of these boundaries in sync. All of the "services" we have extracted are indeed libraries. These libraries use type classes to interface with the core of our application which manages data persistence. This also means that each "service" can be written mostly in isolation and use a different data store (like an in-memory DB or something), depending on our needs.