6 ms·

Wow and I thought functions should only perform a single task. I need to keep up with the times! Apparently you need an entire deployable app and API to do anyt

Wow and I thought functions should only perform a single task. I need to keep up with the times! Apparently you need an entire deployable app and API to do anything these days. I guess it makes sense. How else could we justify so many software engineers!?

elric 4y ago
So many? Last I checked there was a huge shortage, and with the exception of a couple of notable bloatware companies, most seem to be understaffed?
- dagss 4y ago
  Understaffed because with the microservices fashion you can get 100 engineers to be satisfied and think they are doing meaningful work while producing the output of 10 engineers. The industry believes the fashion is the only way to work by now, and shortage results. (Of course, there are several other ways to get 100 engineers to have the output of 10; but I think microservices makes the engineers a lot less frustrated when it happens compared to more traditional alternatives)
  - water-your-self 4y ago
    >but I think microservices makes the engineers a lot less frustrated when it happens compared to more traditional alternatives. Can you explain this reasoning?
    - dagss 4y ago
      What I meant is: If people are working at 1/10th of their potential they would tend to get frustrated. With microservices, you make 10x as much work in such a way that the work seems meaningful and is perhaps even fullfilling. It takes some effort to see that the complexity you are solving day to day is accidental complexity, not essential complexity.
  - deleted 4y ago
    [deleted]
  - 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.
- vanviegen 4y ago
  I think GP was (half) joking that this shortage is caused by everybody cargo culting overly complicated dev practices. I'd say there's some truth in that.
- astrange 4y ago
  Due to Parkinson’s law (“work expands so as to fill the time available for its completion”) it’s likely that all teams will always appear to be slightly understaffed.

elric 4y ago

So many? Last I checked there was a huge shortage, and with the exception of a couple of notable bloatware companies, most seem to be understaffed?

dagss 4y ago
Understaffed because with the microservices fashion you can get 100 engineers to be satisfied and think they are doing meaningful work while producing the output of 10 engineers. The industry believes the fashion is the only way to work by now, and shortage results. (Of course, there are several other ways to get 100 engineers to have the output of 10; but I think microservices makes the engineers a lot less frustrated when it happens compared to more traditional alternatives)
- water-your-self 4y ago
  >but I think microservices makes the engineers a lot less frustrated when it happens compared to more traditional alternatives. Can you explain this reasoning?
  - dagss 4y ago
    What I meant is: If people are working at 1/10th of their potential they would tend to get frustrated. With microservices, you make 10x as much work in such a way that the work seems meaningful and is perhaps even fullfilling. It takes some effort to see that the complexity you are solving day to day is accidental complexity, not essential complexity.
- deleted 4y ago
  [deleted]
- 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.
vanviegen 4y ago
I think GP was (half) joking that this shortage is caused by everybody cargo culting overly complicated dev practices. I'd say there's some truth in that.
astrange 4y ago
Due to Parkinson’s law (“work expands so as to fill the time available for its completion”) it’s likely that all teams will always appear to be slightly understaffed.