4 ms·

If you're losing 10x performance then you're clearly using microservices poorly. Our team of like 6 people produces a crap ton of output. We've got something li

by adra 4y ago

If you're losing 10x performance then you're clearly using microservices poorly. Our team of like 6 people produces a crap ton of output. We've got something like 18 well written services that need basically no ongoing support. If for some reason we're doing too much, those services can be shipped to other teams to maintain or enhance. The one and only amazingly valuable function of microservices is the ability to easily move tasks to other teams without a significant amount of hassle. The monolith doesn't work well in multi-team setups, so you're either doing less or have huge teams with their own sets of problems. Companies do it, but it's so much worse IMHO. To your original point though, correlation doesn't equal causation, and just because you could abuse a technique to placate your wrong-sized org using this technique doesn't mean that it's the purpose of said technique.

gizzlon 4y ago
> Our team of like 6 people produces a crap ton of output. We've got something like 18 well written services that need basically no ongoing support. Seems like this falls under "doing work", not creating output. You're doing a lot of work. > The monolith doesn't work well in multi-team setups.. There are other ways of splitting work between multiple people and teams without introducing a network call.
dagss 4y ago
"Using microservices poorly" -- this comes up a lot when I discuss microservices with people who believe in them. I think it comes close to the True Scotsman fallacy -- if microservices ended up causing a mess, the explanation is always that one wasn't using microservices "properly". I could say the same of a monolith -- if it is a big ball of mud then it is not a Proper Monolith ... Granted, my only experience with microservices was a ball of mud mess microservices. I am sure we will both agree they were NOT doing microservices correctly -- BUT -- they did not know that going in did they? If microservices is defined by definition to only be about the successsful applications of the technique, then it is not very helpful for those choosing architecture for a new system.. Re shifting services to other teams: We have a medium-sized-service architecture, not monolith nor microservice. One or two services per team mostly. By far, the hardest part of onboarding and doing development is learning the business domain and have people understand WHAT to do, why to do it, etc. -- the HOW is usually simple. Code usually covers only the HOW part. Just shipping parts of what we do to another team and expect them to be on top of things quickly doesn't seem realistic regardless of the size of services.. Teams are homes for business and domain knowledge first. A home for the code is just a byproduct.

by adra 4y ago

gizzlon 4y ago

> Our team of like 6 people produces a crap ton of output. We've got something like 18 well written services that need basically no ongoing support. Seems like this falls under "doing work", not creating output. You're doing a lot of work. > The monolith doesn't work well in multi-team setups.. There are other ways of splitting work between multiple people and teams without introducing a network call.

dagss 4y ago

"Using microservices poorly" -- this comes up a lot when I discuss microservices with people who believe in them. I think it comes close to the True Scotsman fallacy -- if microservices ended up causing a mess, the explanation is always that one wasn't using microservices "properly". I could say the same of a monolith -- if it is a big ball of mud then it is not a Proper Monolith ... Granted, my only experience with microservices was a ball of mud mess microservices. I am sure we will both agree they were NOT doing microservices correctly -- BUT -- they did not know that going in did they? If microservices is defined by definition to only be about the successsful applications of the technique, then it is not very helpful for those choosing architecture for a new system.. Re shifting services to other teams: We have a medium-sized-service architecture, not monolith nor microservice. One or two services per team mostly. By far, the hardest part of onboarding and doing development is learning the business domain and have people understand WHAT to do, why to do it, etc. -- the HOW is usually simple. Code usually covers only the HOW part. Just shipping parts of what we do to another team and expect them to be on top of things quickly doesn't seem realistic regardless of the size of services.. Teams are homes for business and domain knowledge first. A home for the code is just a byproduct.