5 ms·
Totally lost it at "e knew we'd ultimately need dozens (even hundreds) of microservices to be successful" and did not read any further. I am having a very hard
by scient 10y ago
Totally lost it at "e knew we'd ultimately need dozens (even hundreds) of microservices to be successful" and did not read any further. I am having a very hard time seeing that as a criteria for success, not to even mention imagining how that mess is managed. Is this really common to have so many microservices?
- CoachRufus87 10y agoShame you didn't read any further, it was a good article. Though not necessarily a criteria for success, some businesses have requirements that make many services make sense. We may not need that many services, but its always interesting to learn how folks solve their engineering problems.
- avitzurel 10y agoYou can easily end up with dozens of services if you split up your application aggressively enough. Think about all the parts in your application that are handled by workers like Sidekiq/Celery, these can all be applications and not part of the monolithic. For example for us at Gogobot, every time a user submits a recommendation we detect the language. This can be a service instead of a worker and the code can live separately. If you do this often enough and aggressively enough, you end up with dozens of services. Once you have an environment that allows easily testing/launching these it's much more efficient to launch a service than replicating your monolithic and assign worker for things.
- geggam 10y agoIf your application / poorly architected then when you split it you just spread that pain around to more systems Design it then split if where it makes sense.
- wpietri 10y agoI have talked to a number of people at large companies who have dozens to hundreds of services. Each team typically has a few services, but when you have hundreds to thousands of engineers, having dozens to hundreds of services seems totally reasonable to me.