4 ms·

I am literally working on a project where the backend team consists of three coders, and the backend currently consists 33 microservices. Common tasks for this

by Maxion 3y ago

I am literally working on a project where the backend team consists of three coders, and the backend currently consists 33 microservices. Common tasks for this platform involves calling around 7+ microservices. Thankfully I am working on the frontend side of things, but this is going to be hell when when we launch.

ttyyzz 3y ago
Yup. Are you using grphql+federation?
- no_butterscotch 3y ago
  Do you think GraphQL has contributed to more microservice driven development?
  - ttyyzz 3y ago
    Yes, not in a bad way. I love graphql to be honest. Federation (using Apollo) is awesome.
- Maxion 3y ago
  LOL no, we're using websockets but doing REST-like requests over it. It's fun!
  - ttyyzz 3y ago
    Sounds like you're making it hard for yourselves on purpose. May I ask why you (the team) chose this over other technology and what was the decision process at the start the project?
guideamigo_com 3y ago
I once saw 5 backend engineers, 100 AWS lambdas, and 30+ GitHub repos! Awesome job security for everyone.
- corethree 3y ago
  This isn't even a joke. Technology in software development has been progressing horizontally. Nothing is improving but abstractions and patterns are changing constantly. Engineers need something to talk about in their OKRs. One strategy is to refactor things into microservices.
Freedom2 3y ago
> Thankfully I am working on the frontend side of things Honestly, given the opinion of frontend on this forum, I'm surprised that you're thankful! I am 100% certain everyone here would take any kind of backend work over the hype-driven mess that is frontend development.
- zdragnar 3y ago
  I moved from backend to frontend years ago, when "hype-driven mess" was a much more accurate description of the field than it is today. There's simply many more interesting challenges in web application front-ends than backends, especially if you need spacial design- things where canvas or webgl excel. Comparatively, there are far fewer backend positions available that are more than basic CRUD, even if it those CRUD operations are gussied up with a bunch of needless complexity juggling sources of truth across a bunch of different services. There's plenty of drudgery out there, and some interesting work in every field, but on the whole I personally have found frontend product development- product configurators for engineering / manufacturing, network visualization, visual design tool development, and data driven interfaces to be more fulfilling work. To each their own, but maybe you might want to be a little more aware of the people that you work with when you feel like saying something condescending. Edit: FWIW, you'd have to be blind to not see hype driven development in backend, especially in HN. "Rewrite it in rust" is the meme that continues to keep on giving.
- gherkinnn 3y ago
  Isn’t it obvious that it is all the same? A dozen micro services per developer on rickety infrastructure serving data for a pixel generator built on top of 5 years worth of JS hype cycles. Why are we doing this to ourselves? It is just so stupid.
  - Maxion 3y ago
    We all gotta pay the mortgage somehow!
- lenkite 3y ago
  > I am 100% certain everyone here would take any kind of backend work over the hype-driven mess that is frontend development The back-end is becoming an even more hype-driven mess these days. What with k8s and dozens of micro-services and controllers and telemetry-everything. And people don't even listen nowadays if you try to propose something simpler. The front-end is at-least constrained by browser limitations and the client device. One can only do hanky-panky upto to a point. But at the backend, "throw another cloud machine" at it has become the de-facto solution for most performance issues.
kgeist 3y ago
One of our projects has ~15 backend engineers and ~30 microservices. It also requires a separate platform team. A k8s cluster with several nodes. It has incidents like every week because the whole thing is like a house of cards. A small feature requires changes in ~5 microservices and a lot of coordination between the teams. They always need to think about things like circuit breakers, timeouts, APIs (schema synchronization, versioning), event queues, distributed transactions, sagas, distributed locking, k8s configs, Git repository management, distributed tracing etc. etc. On the other hand, there's another project, which is a monolith. Around ~15 engineers. Incidents happen very rarely. The infrastructure is simple: just one beefy server without k8s (but there's a standby replica of course), so the team often does maintenance of the server on their own instead of a separate SRE/production team. The monolith is modular so it enjoys same advantages as microservices when it comes to module isolation etc. Highload functionality is moved to separate Go services only when needed (currently 2 or 3 satellite microservices). All changes happen in the same codebase so features are released faster and it's easier to reason about. I'm currently on the second project and whenever I attend architecture reviews of the first project, I'm shocked how overcomplicated the first project has become. A simple addition of a new object property can end up in 5-10 engineers arguing for hours whose microservices are affected and how they should best communicate.
- f4c39012 3y ago
  Has the microservice + backend project team ever observed the monolith project team?
TheBigSalad 3y ago
Jesus. All that and you haven't even launched yet?

by Maxion 3y ago

ttyyzz 3y ago

Yup. Are you using grphql+federation?

no_butterscotch 3y ago
Do you think GraphQL has contributed to more microservice driven development?
- ttyyzz 3y ago
  Yes, not in a bad way. I love graphql to be honest. Federation (using Apollo) is awesome.
Maxion 3y ago
LOL no, we're using websockets but doing REST-like requests over it. It's fun!
- ttyyzz 3y ago
  Sounds like you're making it hard for yourselves on purpose. May I ask why you (the team) chose this over other technology and what was the decision process at the start the project?

guideamigo_com 3y ago

I once saw 5 backend engineers, 100 AWS lambdas, and 30+ GitHub repos! Awesome job security for everyone.

corethree 3y ago
This isn't even a joke. Technology in software development has been progressing horizontally. Nothing is improving but abstractions and patterns are changing constantly. Engineers need something to talk about in their OKRs. One strategy is to refactor things into microservices.

Freedom2 3y ago

> Thankfully I am working on the frontend side of things Honestly, given the opinion of frontend on this forum, I'm surprised that you're thankful! I am 100% certain everyone here would take any kind of backend work over the hype-driven mess that is frontend development.

zdragnar 3y ago
I moved from backend to frontend years ago, when "hype-driven mess" was a much more accurate description of the field than it is today. There's simply many more interesting challenges in web application front-ends than backends, especially if you need spacial design- things where canvas or webgl excel. Comparatively, there are far fewer backend positions available that are more than basic CRUD, even if it those CRUD operations are gussied up with a bunch of needless complexity juggling sources of truth across a bunch of different services. There's plenty of drudgery out there, and some interesting work in every field, but on the whole I personally have found frontend product development- product configurators for engineering / manufacturing, network visualization, visual design tool development, and data driven interfaces to be more fulfilling work. To each their own, but maybe you might want to be a little more aware of the people that you work with when you feel like saying something condescending. Edit: FWIW, you'd have to be blind to not see hype driven development in backend, especially in HN. "Rewrite it in rust" is the meme that continues to keep on giving.
gherkinnn 3y ago
Isn’t it obvious that it is all the same? A dozen micro services per developer on rickety infrastructure serving data for a pixel generator built on top of 5 years worth of JS hype cycles. Why are we doing this to ourselves? It is just so stupid.
- Maxion 3y ago
  We all gotta pay the mortgage somehow!
lenkite 3y ago
> I am 100% certain everyone here would take any kind of backend work over the hype-driven mess that is frontend development The back-end is becoming an even more hype-driven mess these days. What with k8s and dozens of micro-services and controllers and telemetry-everything. And people don't even listen nowadays if you try to propose something simpler. The front-end is at-least constrained by browser limitations and the client device. One can only do hanky-panky upto to a point. But at the backend, "throw another cloud machine" at it has become the de-facto solution for most performance issues.

kgeist 3y ago

One of our projects has ~15 backend engineers and ~30 microservices. It also requires a separate platform team. A k8s cluster with several nodes. It has incidents like every week because the whole thing is like a house of cards. A small feature requires changes in ~5 microservices and a lot of coordination between the teams. They always need to think about things like circuit breakers, timeouts, APIs (schema synchronization, versioning), event queues, distributed transactions, sagas, distributed locking, k8s configs, Git repository management, distributed tracing etc. etc. On the other hand, there's another project, which is a monolith. Around ~15 engineers. Incidents happen very rarely. The infrastructure is simple: just one beefy server without k8s (but there's a standby replica of course), so the team often does maintenance of the server on their own instead of a separate SRE/production team. The monolith is modular so it enjoys same advantages as microservices when it comes to module isolation etc. Highload functionality is moved to separate Go services only when needed (currently 2 or 3 satellite microservices). All changes happen in the same codebase so features are released faster and it's easier to reason about. I'm currently on the second project and whenever I attend architecture reviews of the first project, I'm shocked how overcomplicated the first project has become. A simple addition of a new object property can end up in 5-10 engineers arguing for hours whose microservices are affected and how they should best communicate.

f4c39012 3y ago
Has the microservice + backend project team ever observed the monolith project team?

TheBigSalad 3y ago

Jesus. All that and you haven't even launched yet?