4 ms·

Big organizations do microservices because it reduces the number of people who you need to coordinate changes with to a reasonably small number per service. Thi

by DasIch 5y ago

Big organizations do microservices because it reduces the number of people who you need to coordinate changes with to a reasonably small number per service. This is critical for the ability to effectively maintain services and make progress at a reasonable pace. Important to note here is that a single microservice can actually be quite large with anywhere from 3-12 people working on just one or a few services. A single service could be larger than a startups monolith. I would argue that this is really the only reasonable use of microservices. If you can fully understand your monolith, you shouldn’t change to microservices. If you fully understand or even know about all microservices in your organization, chances are that you’re doing it wrong.

yakshaving_jgt 5y ago
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.
- 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.
spaetzleesser 5y ago
"Important to note here is that a single microservice can actually be quite large with anywhere from 3-12 people working on just one or a few services. A single service could be larger than a startups monolith.". This seems quite reasonable In some companies it seems it's more like 1 developer managing 3-12 services :-(

by DasIch 5y ago

yakshaving_jgt 5y ago

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.
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.

spaetzleesser 5y ago

"Important to note here is that a single microservice can actually be quite large with anywhere from 3-12 people working on just one or a few services. A single service could be larger than a startups monolith.". This seems quite reasonable In some companies it seems it's more like 1 developer managing 3-12 services :-(