3 ms·

I don't think microservices are the answer to everything, but I don't see how monoliths can keep up with developer velocity when an organization reaches thousan

I don't think microservices are the answer to everything, but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Monoliths are way slower to deploy than microservices, and when you have hundreds or thousands of changes going out every day, this means lots of changes being bundled together in the same deployment, and as a consequence, lots of bugs. Having to stop a deployment and roll it back every time a defect is sent to production would just make the whoe thing completely undeployable. Microservices have some additional operational overhead, but they do allow much faster deployments and rollbacks without affecting the whole org. Maybe I am biased, but I would love an explanation from the monolith-evangelist crowd on how to keep a monolith able to deploy multiple times a day and capable of rolling back changes when people are pushing hundreds of PRs every day.

Sohcahtoa82 4y ago
> I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Are those thousands of developers working on a single product? If so, then I'd argue that you have way too many developers. At that point, you'd need so many layers of management that the overall vision of what the product is gets lost.
- tail_exchange 4y ago
  Not necessarily. But if the solution in this case is to start breaking up the monolith into smaller services owned by specific product teams, then you are moving towards microservices.
hannofcart 4y ago
> but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. You're likely right. I think what most detractors of microservices are pointing to is that most companies don't reach thousands of devs in size. Or even hundreds.

Sohcahtoa82 4y ago

> I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Are those thousands of developers working on a single product? If so, then I'd argue that you have way too many developers. At that point, you'd need so many layers of management that the overall vision of what the product is gets lost.

tail_exchange 4y ago
Not necessarily. But if the solution in this case is to start breaking up the monolith into smaller services owned by specific product teams, then you are moving towards microservices.

hannofcart 4y ago

> but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. You're likely right. I think what most detractors of microservices are pointing to is that most companies don't reach thousands of devs in size. Or even hundreds.