|
|
|
|
|
by steveBK123
1307 days ago
|
|
I think team size / responsibility is a big part of choosing how much you need to go down the micro service route as well. I've recently launched on a ~2 dev team, and leaning more and more towards monolith the longer we go. The worst teams I have been on are the ones with multiples (~5x) as many repos & running services as we have developers. Huge swathes of repos would go without commits, builds or releases for years. Inevitably the next time you had business requirements on that repo, something in CI/CD or environment had changed enough that you had to do a bunch of devops/infra/non-business work to get the plumbing working again to even start the task. Even in teams where we eventually had nice central utilities & libraries with versioned dependencies, you never had the chance to do enough "catch up" releases to keep all 100 repos on some reasonably recent version of the core libraries. So the cost to activate some new observability function from your central libs was huge because you needed to make small changes on 50+ repos otherwise the observability was pointless since it had low coverage. |
|