4 ms·

Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codeba

by 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.
      - 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
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.

by cynusx 4y ago

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.
    - 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

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.