4 ms·

Very much this. It may be worthwhile for really complex and "business vice separated" services to be written as micro services because it gives you clear separ

Very much this. It may be worthwhile for really complex and "business vice separated" services to be written as micro services because it gives you clear separation of concerns. But, in reality, to often you see a single logical service getting implemented with a lot of (N/W + serialization + management) costs unnecessarily just because it is cool to say that you did micro services. My thumb rule is : If you don't foresee different teams of devs working on these different services, then you're better off leaving it as a monolith and scaling it as a whole application instead.

JamesBarney 8y 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_ 8y ago
  I 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).

JamesBarney 8y 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_ 8y ago
I 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).