6 ms·

> Simpler code base from not having to worry about concurrency and multi-threading Microservice advocates are so naive it's painful. It is only simpler if you

by sime2009 6y ago

> Simpler code base from not having to worry about concurrency and multi-threading Microservice advocates are so naive it's painful. It is only simpler if you completely ignore the downsides of microservices. Taking a "monolith" application and turning it into a distributed application rarely makes it simpler. Now you have to deal with network failures, serialising and deserialising data for what was previously just a method call, API versioning all over the place, kubernetes/terraform/etc configs from hell, concurrency and race conditions still persist but now they're spread across services instead of between threads. You want data consistency and transactions? Forget about it!

sto_hristo 6y ago
By mentioning data consistency and transactions - your microservice is supposed to be self-contained and self-sufficient, doing its own job only. True, it may rely on other service, but not in the way that the two services would do the exact same job together as if you're invoking a `private` method helpers. For ex., filling a shopping cart should be its own thing. Searching for stuff to fill that cart can be another service that is just a dumb catalog. No data consistency problems here.
- Volundr 6y ago
  Sure there is. What do I do when a piece of information I need to fill the shopping cart is removed or renamed in the search service?
  - sto_hristo 6y ago
    There is always the single source of truth principle. It is expected that both the search service and cart reference the catalog service.
    - Volundr 6y ago
      OK, so when the catalog service is updated I need to update the search service and the cart service and coordinate deployment of these various services, or provide multiple versions of the catalog api.
      - sto_hristo 6y ago
        Yes. If you have several consumers of the catalog service, those consumers are bound to a specific version it. You may update the catalog service API as much as you wish, but that will simply open /v2, v3, .../ endpoints - existing services shouldn't be affected. Just like with regular REST APIs. Deprecation of older API versions will be as disrupting as expected, of course. If existing consumer of catalog service needs to make use of the new version features, you update it on its own... Version hell? You can imagine the horrors. But technical debt on an architectural level is something you need to consider any architecture you choose to create your application in. Point of micro services is have your components loosely coupled and independent from one another. If catalog fails, it shouldn't bring down the whole application with it. In our simple example, catalog failure means whole app becoming inert, but in bigger applications you _may_ find benefits of this. Also worth mentioning - load can vary between components. The cart will see less use than the search service, while the catalog will be most loaded. You can make deployment decisions to optimally allocate resources for your application.

sto_hristo 6y ago

By mentioning data consistency and transactions - your microservice is supposed to be self-contained and self-sufficient, doing its own job only. True, it may rely on other service, but not in the way that the two services would do the exact same job together as if you're invoking a `private` method helpers. For ex., filling a shopping cart should be its own thing. Searching for stuff to fill that cart can be another service that is just a dumb catalog. No data consistency problems here.

Volundr 6y ago
Sure there is. What do I do when a piece of information I need to fill the shopping cart is removed or renamed in the search service?
- sto_hristo 6y ago
  There is always the single source of truth principle. It is expected that both the search service and cart reference the catalog service.
  - Volundr 6y ago
    OK, so when the catalog service is updated I need to update the search service and the cart service and coordinate deployment of these various services, or provide multiple versions of the catalog api.
    - sto_hristo 6y ago
      Yes. If you have several consumers of the catalog service, those consumers are bound to a specific version it. You may update the catalog service API as much as you wish, but that will simply open /v2, v3, .../ endpoints - existing services shouldn't be affected. Just like with regular REST APIs. Deprecation of older API versions will be as disrupting as expected, of course. If existing consumer of catalog service needs to make use of the new version features, you update it on its own... Version hell? You can imagine the horrors. But technical debt on an architectural level is something you need to consider any architecture you choose to create your application in. Point of micro services is have your components loosely coupled and independent from one another. If catalog fails, it shouldn't bring down the whole application with it. In our simple example, catalog failure means whole app becoming inert, but in bigger applications you _may_ find benefits of this. Also worth mentioning - load can vary between components. The cart will see less use than the search service, while the catalog will be most loaded. You can make deployment decisions to optimally allocate resources for your application.