2 ms·

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 t

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.

simplotek 4y ago
> What problem are you solving with microservices? As I've already said in this thread, microservices solve primarily organizational problems. They define concrete organizational barriers and limit discussions with stakeholders on issues pertaining to service contracts, and ensure that service owners have complete freedom, responsibility, and clear accountability, on all aspects of their design, maintenance, and operation. Scalability is a welcomed benefit but lower in importance, below reliability and perceived performance. Any other discussion on microservices boil down to strawmen.
- ItsMonkk 4y ago
  The GP of this discussion talks about 10 devs where each dev is working on more than one microservice. I've seen a lot worse. If I could pick one thing to talk about when it comes to microservices it would be the name. Micro implies microscope, implies there should be millions to billions of them. If we could switch to the term two-pizza-services as your comment implies where their main point is in working around Conway's Law, I would feel a lot better about them.
- cynusx 4y ago
  I would agree with you that it could be useful for organizational problems but I would resist this as long as possible. In any case, I prefer to not split engineering teams but for practical reasons (e.g. keeping onboarding times into the team reasonable) you are quite forced to do so. Once your team loses the rapid feedback of "did this break user-facing functionality yes/no?" your reliability and speed of shipping features deteriorates rapidly as now most engineers will start to fear shipping to production. Ideally, you break the team into subteams and follow the natural fault-lines in the codebase. Most codebases have areas that do not interact much (or not at all) with each other and they lend themselves well to assigning to a specific subteam. I'm sure there's a point where this breaks also but I haven't reached it yet.

simplotek 4y ago

> What problem are you solving with microservices? As I've already said in this thread, microservices solve primarily organizational problems. They define concrete organizational barriers and limit discussions with stakeholders on issues pertaining to service contracts, and ensure that service owners have complete freedom, responsibility, and clear accountability, on all aspects of their design, maintenance, and operation. Scalability is a welcomed benefit but lower in importance, below reliability and perceived performance. Any other discussion on microservices boil down to strawmen.

ItsMonkk 4y ago
The GP of this discussion talks about 10 devs where each dev is working on more than one microservice. I've seen a lot worse. If I could pick one thing to talk about when it comes to microservices it would be the name. Micro implies microscope, implies there should be millions to billions of them. If we could switch to the term two-pizza-services as your comment implies where their main point is in working around Conway's Law, I would feel a lot better about them.
cynusx 4y ago
I would agree with you that it could be useful for organizational problems but I would resist this as long as possible. In any case, I prefer to not split engineering teams but for practical reasons (e.g. keeping onboarding times into the team reasonable) you are quite forced to do so. Once your team loses the rapid feedback of "did this break user-facing functionality yes/no?" your reliability and speed of shipping features deteriorates rapidly as now most engineers will start to fear shipping to production. Ideally, you break the team into subteams and follow the natural fault-lines in the codebase. Most codebases have areas that do not interact much (or not at all) with each other and they lend themselves well to assigning to a specific subteam. I'm sure there's a point where this breaks also but I haven't reached it yet.