4 ms·
Yes, I've always seen microservices as an organizational win over any type of technical win. Basically having separate teams work on one code base with one dep
by JamesBarney 9y ago
Yes, I've always seen microservices as an organizational win over any type of technical win.
Basically having separate teams work on one code base with one deployment cycle can sometimes be really tough. And sometimes you can get a big win by splitting up this service so multiple teams can each have their own service to focus on.
This whole team of one developer supporting 8 microservices seems ludicrious to me.
- kakwa_ 9y agoI completely agree with you. I tend to like the idea of the 2 pizzas rule from Jeff Bezos. Having a small team (let say under 10 people) manage a service end to end (from spec to code to production) can be really efficient. On large code bases/large products, this can help a lot, offsetting the cost of a more complex architecture. However in a microservice architecture, the APIs between services is critical. It's a contract between services, and it should be clearly stated, you cannot go berserk every other day and change it. You also need to establish clear rules about versioning, deprecation and end of life of said APIs. (by the way, it would be nice if we had a standard to negotiate API versions, for example stating that a rest API must always have a /version which lists the available versions, if some versions are deprecated and when they will be EOLed).