15 ms·

I feel like I was a 10x when we did monoliths. With "fake team microservices" - which is extremely prevalent these days, I feel like a 1x developer. The second

I feel like I was a 10x when we did monoliths. With "fake team microservices" - which is extremely prevalent these days, I feel like a 1x developer. The second I have to open another repo and do something - pull, yarn, build, and start updating, push, go back and update. I just lose all want to do anything for this company. "Fake team microservices" is when you have say like 7-10 devs in the company, and 50 libraries and 15 microservices. The microservices are real, but the team "size" is faked. People moved on from monoliths way to quickly and it's ruined my productivity. I actually thought my brain was slow and I was getting stupid recently. Then I did a programming test (interview). I burned through it so fast that I realized most of my mental blocks are NOT wanting to work for the company I am currently employed. My wife just nodded in complete agreement when I came to that realization. I want to be a 10x again and I realized when companies focus on the wrong things, that breaks the 10x.

MikeDelta 4y ago
Motivation and passion are very much underestimated in performance. I hope you manage to rekindle your passion somewhere else and run at 10x the speed again!
cynusx 4y ago
Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase. That's assuming good intent, worse intent is that devs want to experiment with different languages or generally want to avoid learning what everything is in the codebase or they are unable to use their editor properly to navigate large codebases efficiently. There is absolutely no reason to split the codebase and subsequently the test-suite ever. You can always take a monolith codebase and deploy it differently with the configuration driven by environment variables. (e.g. external vs. internal API's). This way your test-suite remains unified and can test the entire application.
- simplotek 4y ago
  > Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase. This is simply not true. Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources. The organizational problem is solved by the hard boundaries and loose coupling imposed by operating and consuming independent services. Allowing a team to own and operate their services allows them to have more control over all aspects of a their life cycle, reducing the scope of other stakeholders to what contract their interfaces need to comply with. Those who naively shit on microservices seem to be totally oblivious to what it would be like if all we had were monoliths. We tried that already. It's awful, and we learned from that mistake. Well, some of us did.
  - naasking 4y ago
    > Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources. "A" solution does not mean the only solution or the best solution. They're often treated as the only solution though.
    - simplotek 4y ago
      > "A" solution does not mean the only solution or the best solution. They're often treated as the only solution though. They are often, and by far, the best solution though, specially taking into account the tradeoffs of whatever alternative you come up with. Specially massive monoliths in a monorepo. It makes no sense to mindlessly crap on operating services, specially when compared with alternatives. I get that some people feel the need to vent their personal frustrations, but this does not mean they have a point.
      - withinboredom 4y ago
        What problem are you solving with microservices? Scaling? You can run the same service everywhere but route traffic to specific endpoints to pools of the same thing. These are devops problems and don't necessarily need to be reflected in the code. Are you trying to solve a problem with code organization? I've heard of folders, they do a pretty good job. Most of the time though, microservices tend to get in the way of delivering VALUE to the company I work for ... because someone thinks 'this is the way.' I was hired to deliver VALUE, not beautiful code, not code that follows this year's 'best practices' that aren't, or even bad code. I will always write easy, simple, and clear code that delivers VALUE. Microservices usually get in the way of doing that, for basically arbitrary reasons.
- feoren 4y ago
  > There is absolutely no reason to split the codebase There are always reasons for and against any decision. Engineering is about balancing those tradeoffs to meet your particular needs. It's silly to say "there is absolutely no reason to ..." about almost anything.
arp242 4y ago
The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment. Runs the application locally? Run tests locally? lolno, we're Modern dev-ops™ so you push it to CI and wait for 10 to 30 minutes and browse HN in the meanwhile! I found that's the real productivity killer. The whole microservice bonanza is still not my favourite approach, but with the right tooling it can work okay. If you don't have good tooling that's actively maintained (which is the case more often than not) ... yeah, your productivity will drop to nothing.
- simplotek 4y ago
  > The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment. That's far from my experience. In all the projects I worked with that involved services, the very first thing that was setup was a working local test environment and at least a non-prod stage. With tools like Docker compose and any of the myriad local kubernetes clusters this is outright trivial. If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture. Once I worked on a legacy desktop application project that didn't even had debug builds. Would it be fair to pin this failing on how awful desktop apps are?
  - arp242 4y ago
    I've never worked anywhere that was deeply invested in microservers and had a workable development environment. n=3. All small companies. I'm sure this isn't representative of all companies, but I also never claimed that's the case. Smaller companies tend to have worse dev tooling in general, so not a surprise this extends to this, too. > If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture. Running 15 servers is harder than running 1 servers. These things are certainly related. It's not "trivial" to run any of this. It's not "on me"; I joined long after all of this was set up. Usually there seems little interest in getting anything going, it's all pretty complex and often undocumented, so not so easy to "just" fix it by myself either, and after a few weeks or months of basically getting fuck all done I've ended up leaving (
mattgreenrocks 4y ago
Software engineering, tools, and practices nowadays seems more concerned with enabling higher headcounts than it does enabling existing members to work effectively. We need a counter-movement for the latter.
EarthMephit 4y ago
Its just that you moved from an environment where you knew the product back to front and how everything fit together really well to a new environment that you understood less. I work on two microservice cloud systems at the moment: the first I was the first person working on it day one, and have been involved in every aspect including devops & support for the past seven years - I'm far and away the most producive developer on this system. With the second system, there's another developer that's driven the team for the past few years and designed everything from the start, and they are easily the most productive person on this team. Probably 3x everyone else and its a strong team. Its just that I know the second system less - I know roughly how everything works, but haven't poked around in every corner of the system like I have the first. For larger systems this kind of knowledge can take years to build up.
aidenn0 4y ago
> grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too > seem very confusing to grug https://grugbrain.dev/#grug-on-microservices https://grugbrain.dev/#grug-on-microservices
bartimus 4y ago
The choice of architectural solution is exactly where the developer can achieve their 10x gains. So who knows your monolith idea might achieve the 10x gains over whatever solution you're currently stuck with?
- noloblo 4y ago
  Fp
DonHopkins 4y ago
Being able to work on both the client and the server side at once is worth at least 5x, since you're not at the mercy of somebody else to get things done from end-to-end.
- turtleyacht 4y ago
  Docker Compose has been amazing for working both client and server. An image for Postgres, another for Node.js (for example), and it's (almost) off to the races. One level of indirection up, it would be nice to have this as scaffolding, and a script would pull in (containerized) services, injecting the appropriate env vars and the like. We would (or should) be able to debug things, because we control the layer on top. Maybe intercepting network calls, redirecting requests from the container--the possibilities are endless.
rongenre 4y ago
Microservices for their own sake seems to be a mistake. The big win of microservices seems to be when your dev team is big enough that coordinating everything within a monolith becomes cumbersome. It's more about organizational structure than anything else. Examples: Team a needs version 6 of a dependency Team b is using version 5, and there's serious compatibility issues Team c is writing something in Rust which makes sense for them, but not teams a and b.

MikeDelta 4y ago

Motivation and passion are very much underestimated in performance. I hope you manage to rekindle your passion somewhere else and run at 10x the speed again!

cynusx 4y ago

Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase. That's assuming good intent, worse intent is that devs want to experiment with different languages or generally want to avoid learning what everything is in the codebase or they are unable to use their editor properly to navigate large codebases efficiently. There is absolutely no reason to split the codebase and subsequently the test-suite ever. You can always take a monolith codebase and deploy it differently with the configuration driven by environment variables. (e.g. external vs. internal API's). This way your test-suite remains unified and can test the entire application.

simplotek 4y ago
> Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase. This is simply not true. Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources. The organizational problem is solved by the hard boundaries and loose coupling imposed by operating and consuming independent services. Allowing a team to own and operate their services allows them to have more control over all aspects of a their life cycle, reducing the scope of other stakeholders to what contract their interfaces need to comply with. Those who naively shit on microservices seem to be totally oblivious to what it would be like if all we had were monoliths. We tried that already. It's awful, and we learned from that mistake. Well, some of us did.
- naasking 4y ago
  > Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources. "A" solution does not mean the only solution or the best solution. They're often treated as the only solution though.
  - simplotek 4y ago
    > "A" solution does not mean the only solution or the best solution. They're often treated as the only solution though. They are often, and by far, the best solution though, specially taking into account the tradeoffs of whatever alternative you come up with. Specially massive monoliths in a monorepo. It makes no sense to mindlessly crap on operating services, specially when compared with alternatives. I get that some people feel the need to vent their personal frustrations, but this does not mean they have a point.
    - withinboredom 4y ago
      What problem are you solving with microservices? Scaling? You can run the same service everywhere but route traffic to specific endpoints to pools of the same thing. These are devops problems and don't necessarily need to be reflected in the code. Are you trying to solve a problem with code organization? I've heard of folders, they do a pretty good job. Most of the time though, microservices tend to get in the way of delivering VALUE to the company I work for ... because someone thinks 'this is the way.' I was hired to deliver VALUE, not beautiful code, not code that follows this year's 'best practices' that aren't, or even bad code. I will always write easy, simple, and clear code that delivers VALUE. Microservices usually get in the way of doing that, for basically arbitrary reasons.
feoren 4y ago
> There is absolutely no reason to split the codebase There are always reasons for and against any decision. Engineering is about balancing those tradeoffs to meet your particular needs. It's silly to say "there is absolutely no reason to ..." about almost anything.

arp242 4y ago

The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment. Runs the application locally? Run tests locally? lolno, we're Modern dev-ops™ so you push it to CI and wait for 10 to 30 minutes and browse HN in the meanwhile! I found that's the real productivity killer. The whole microservice bonanza is still not my favourite approach, but with the right tooling it can work okay. If you don't have good tooling that's actively maintained (which is the case more often than not) ... yeah, your productivity will drop to nothing.

simplotek 4y ago
> The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment. That's far from my experience. In all the projects I worked with that involved services, the very first thing that was setup was a working local test environment and at least a non-prod stage. With tools like Docker compose and any of the myriad local kubernetes clusters this is outright trivial. If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture. Once I worked on a legacy desktop application project that didn't even had debug builds. Would it be fair to pin this failing on how awful desktop apps are?
- arp242 4y ago
  I've never worked anywhere that was deeply invested in microservers and had a workable development environment. n=3. All small companies. I'm sure this isn't representative of all companies, but I also never claimed that's the case. Smaller companies tend to have worse dev tooling in general, so not a surprise this extends to this, too. > If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture. Running 15 servers is harder than running 1 servers. These things are certainly related. It's not "trivial" to run any of this. It's not "on me"; I joined long after all of this was set up. Usually there seems little interest in getting anything going, it's all pretty complex and often undocumented, so not so easy to "just" fix it by myself either, and after a few weeks or months of basically getting fuck all done I've ended up leaving (

mattgreenrocks 4y ago

Software engineering, tools, and practices nowadays seems more concerned with enabling higher headcounts than it does enabling existing members to work effectively. We need a counter-movement for the latter.

EarthMephit 4y ago

Its just that you moved from an environment where you knew the product back to front and how everything fit together really well to a new environment that you understood less. I work on two microservice cloud systems at the moment: the first I was the first person working on it day one, and have been involved in every aspect including devops & support for the past seven years - I'm far and away the most producive developer on this system. With the second system, there's another developer that's driven the team for the past few years and designed everything from the start, and they are easily the most productive person on this team. Probably 3x everyone else and its a strong team. Its just that I know the second system less - I know roughly how everything works, but haven't poked around in every corner of the system like I have the first. For larger systems this kind of knowledge can take years to build up.

aidenn0 4y ago

> grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too > seem very confusing to grug https://grugbrain.dev/#grug-on-microservices https://grugbrain.dev/#grug-on-microservices

bartimus 4y ago

The choice of architectural solution is exactly where the developer can achieve their 10x gains. So who knows your monolith idea might achieve the 10x gains over whatever solution you're currently stuck with?

noloblo 4y ago
Fp

DonHopkins 4y ago

Being able to work on both the client and the server side at once is worth at least 5x, since you're not at the mercy of somebody else to get things done from end-to-end.

turtleyacht 4y ago
Docker Compose has been amazing for working both client and server. An image for Postgres, another for Node.js (for example), and it's (almost) off to the races. One level of indirection up, it would be nice to have this as scaffolding, and a script would pull in (containerized) services, injecting the appropriate env vars and the like. We would (or should) be able to debug things, because we control the layer on top. Maybe intercepting network calls, redirecting requests from the container--the possibilities are endless.

rongenre 4y ago

Microservices for their own sake seems to be a mistake. The big win of microservices seems to be when your dev team is big enough that coordinating everything within a monolith becomes cumbersome. It's more about organizational structure than anything else. Examples: Team a needs version 6 of a dependency Team b is using version 5, and there's serious compatibility issues Team c is writing something in Rust which makes sense for them, but not teams a and b.