3 ms·

The microservices fad is hilarious. Let’s replace direct function calls and direct channels of communication with calls and channels over a network, and that wi

• Aeolun 5y ago
  It also makes it easier to split teams/repositories organisation wise. Technically I agree. It doesn’t really do anything that decent interfaces and loose coupling do not.
  • api 5y ago
    It makes you give more money to your cloud provider as it is less efficient.
  • marcosdumay 5y ago
    That "micro" part there implies that the thing is not team-sized. Libraries help split your project for teams, as do SOA. Microservices are just extraneous splits added into it. What microservices help with is making data-based native applications and those single page applications for the web. But the usual patterns people push around only make those tasks harder. At this point I believe the entire microservices knowledge base is bullshit.
• praptak 5y ago
  No, it is not only about scaling or gluing different languages. Some other aspects that microservices can help with: Reliability. There is a chance that one microservice crash looping does not bring the whole system down. This would not be an advantage if languages were better at isolating failures but they aren't. Independent release cycles. It is good to be able to upgrade only one service. For example if something goes wrong, you roll back only one service. You also have a smaller code base to debug. Runaway resource consumption. A memory leak or a logs explosion only affects one service. This arguably is a version of "scales independently". Above stuff is from my experience at Google. YMMV. I can imagine that a badly designed microservice architecture does not bring these benefits.
  • ratww 5y ago
    I've had great success solving those things merely by having multiple deployments of the same monolith, each answering to different parts of the same API. It worked pretty well IME.
  • username90 5y ago
    > Above stuff is from my experience at Google Google needs microservices, their codebase is many thousands times too big to deploy as a single unit. They also have the money to focus on reliability over velocity. The startup with 2 developers doesn't need microservices, and the things you are talking about aren't things that a startup should think about before they have any users. Yet they still often goes with microservices because that is what the big boys do. It is those cases we talk about here.
• deleted 5y ago
  [deleted]
• tsimionescu 5y ago
  Microservices have some organizational advantages that libraries don't: they are much harder to hack around the boundaries of, forcing a better adherence to the agreed architecture. Also, microservices are much better at isolating faults than any traditional langauge is, even for pretty systemic faults such as memory leaks - if each service is running in some container, storing most state in a DB instead of memory, users may not even notice when it crashes with an OOM, something no runtime I know could realistically handle (unless you do gargantuan work to manage memory explicitly for this goal). > It’s probably something pushed by cloud providers to increase lock in and use more resources, since adding self hosting capability to a microservice based system that is dependent on Kubernetes is going to be that much harder. The whole point of Kubernetes is the ease of switching between clouds or cloud and self hosting. As long as your application only depends on Kubernetes abstractions, the cost of moving from EKS to AKS or to Kubernetes on bare metal is going to be relatively small - probably smaller than most deployment options that can handle a similar scale and reliability.