3 ms·

Sounds like a process problem. 2024 development cycles should be able to handle multiple lanes of development and deployments. Also why things moved to microser

Sounds like a process problem. 2024 development cycles should be able to handle multiple lanes of development and deployments. Also why things moved to microservices so you can deploy with minimal impact as long as you don't tightly couple your dependencies.

m00x 2y ago
You don't need microservices to do this. It's actually easier deploying a monolith with internal dependencies than deploying microservices that depend on each other.
- adrianpike 2y ago
  This is very accurate - microservices can be great as a forcing function to revisit your architectural boundaries, but if all you do is add a network hop and multiple components to update when you tweak a data model, all you'll get is headcount sprawl and deadlock to the moon. I'm a huge fan of migrating to microservices as a secondary outcome of revisiting your component boundaries, but just moving to separate repos & artifacts so we can all deploy independently is a recipe for pain.
  - jrs235 2y ago
    and a recipe for "career" driven managers and directors to grow department head count, budget oversight, and self importance.
  - Sparkyte 2y ago
    Network hop isn't needed if you're deploying your microservices correctly. So you can make pod groups inside of kubernetes and application that depends on another can call that lightweight container contained in that pod group. Pods inherently know the other is there in their group it has some or like network call without traversing hardware.
- Sparkyte 2y ago
  I know microservices and monoliths are a heated topic. However breaking up complicated code to preserve user experience is sometimes essential. However you can have machines that contain many services and that interact with each for performance if needed. You would put them into pod groups while deploying to kubernetes and have them call their service inside of the pod. This can increase performance and through put.

m00x 2y ago

You don't need microservices to do this. It's actually easier deploying a monolith with internal dependencies than deploying microservices that depend on each other.

adrianpike 2y ago
This is very accurate - microservices can be great as a forcing function to revisit your architectural boundaries, but if all you do is add a network hop and multiple components to update when you tweak a data model, all you'll get is headcount sprawl and deadlock to the moon. I'm a huge fan of migrating to microservices as a secondary outcome of revisiting your component boundaries, but just moving to separate repos & artifacts so we can all deploy independently is a recipe for pain.
- jrs235 2y ago
  and a recipe for "career" driven managers and directors to grow department head count, budget oversight, and self importance.
- Sparkyte 2y ago
  Network hop isn't needed if you're deploying your microservices correctly. So you can make pod groups inside of kubernetes and application that depends on another can call that lightweight container contained in that pod group. Pods inherently know the other is there in their group it has some or like network call without traversing hardware.
Sparkyte 2y ago
I know microservices and monoliths are a heated topic. However breaking up complicated code to preserve user experience is sometimes essential. However you can have machines that contain many services and that interact with each for performance if needed. You would put them into pod groups while deploying to kubernetes and have them call their service inside of the pod. This can increase performance and through put.