4 ms·

Monolith: a->b Microservice: a->async->serialization->network->serialization->scheduling->b A monolith is extremely simple to traverse with a debugger, a micr

Monolith: a->b Microservice: a->async->serialization->network->serialization->scheduling->b A monolith is extremely simple to traverse with a debugger, a microservice is not. I can make a dozen jumps over/into/out in less time than it would take me to open Fiddler or man tcpdump. I have heard that some companies have tooling that makes the microservices debugging situation tolerable or sometimes even better than monolith (e.g. writing tests for you by snooping the network layer), but I have yet to play with any. Do you have recommendations?

reacharavindh 9y ago
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 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 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).

reacharavindh 9y ago

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 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 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).