4 ms·

You've broken the microservice abstraction if this a problem. A team should own a microservice, you release as soon as the team able to. You version your apis

You've broken the microservice abstraction if this a problem. A team should own a microservice, you release as soon as the team able to. You version your apis, so you don't break any services which rely on yours.

giantg2 6y ago
"You've broken the microservice abstraction if this a problem." I agree, but in practice it seems more companies break it rather than follow it.
- UK-Al05 6y ago
  I agree people hop on the microservice bandwagon without really understanding the "philosophy" behind it. Then blame microservices when they struggle.
  - giantg2 6y ago
    I actually prefer a monolith compared to the way we do microservices. One or two big apps to own vs ten microservices or apps that require coordinating with others. It's really just a duplication of paperwork and other overhead processes.
    - UK-Al05 6y ago
      We don't require any coordination with ours. It's low cost for us. We may make the occasional announcement that v5 our api is coming soon which has x features based on feedback from other teams. Then announce when we've released it. Its a product, and we own it.
      - giantg2 6y ago
        That sounds nice. My most recent elevation involved coordinating with 5 other services to stop/restart/reprocess items with a couple deploys between the 5. Had to be off-hours too. Sort of normal for us.
        UK-Al05 6y ago
        You have all the symptoms of a distributed monolith.
    - ex_amazon_sde 6y ago
      > vs ten microservices or apps that require coordinating with others That's called the "distributed monolith" and it's worse than a monolith.
nonameiguess 6y ago
Although this is true, there is still the additional problem that a lot of customers, specifically government customers, require frozen known versions of everything as a requirement for acceptance testing. Auditing standards for the aerospace industry require that what is running in ops is exactly the same version of everything that was running when an acceptance test was witnessed and signed. It's a totally impractical standard for modern software development, but the developers themselves have no choice in the matter until the customers change.

giantg2 6y ago

"You've broken the microservice abstraction if this a problem." I agree, but in practice it seems more companies break it rather than follow it.

UK-Al05 6y ago
I agree people hop on the microservice bandwagon without really understanding the "philosophy" behind it. Then blame microservices when they struggle.
- giantg2 6y ago
  I actually prefer a monolith compared to the way we do microservices. One or two big apps to own vs ten microservices or apps that require coordinating with others. It's really just a duplication of paperwork and other overhead processes.
  - UK-Al05 6y ago
    We don't require any coordination with ours. It's low cost for us. We may make the occasional announcement that v5 our api is coming soon which has x features based on feedback from other teams. Then announce when we've released it. Its a product, and we own it.
    - giantg2 6y ago
      That sounds nice. My most recent elevation involved coordinating with 5 other services to stop/restart/reprocess items with a couple deploys between the 5. Had to be off-hours too. Sort of normal for us.
      - UK-Al05 6y ago
        You have all the symptoms of a distributed monolith.
  - ex_amazon_sde 6y ago
    > vs ten microservices or apps that require coordinating with others That's called the "distributed monolith" and it's worse than a monolith.

nonameiguess 6y ago

Although this is true, there is still the additional problem that a lot of customers, specifically government customers, require frozen known versions of everything as a requirement for acceptance testing. Auditing standards for the aerospace industry require that what is running in ops is exactly the same version of everything that was running when an acceptance test was witnessed and signed. It's a totally impractical standard for modern software development, but the developers themselves have no choice in the matter until the customers change.