[HN Gopher] Ask HN: Why Not Microservices?
___________________________________________________________________
Ask HN: Why Not Microservices?
It's pretty clear that microservices have fallen out of favor on
HN. As someone who's currently experiencing pain on both sides pro
and con here, I'm curious to learn more about the argument. Is
there more to it than "you're not Google, don't act like Google"
for small startups? How about companies that are scale?
Author : rajacombinator
Score : 12 points
Date : 2021-05-27 19:40 UTC (3 hours ago)
| bdcravens wrote:
| Many large applications have pushed back on the model.
| Microservices tend to solve problems of scaling teams, not
| scaling users.
| sethammons wrote:
| Microservices, in my experience, are chiefly about scaling teams
| (more freedom to move faster). In fewer cases, it is about
| optimizing a hot path. If it is not one of those, I'm having a
| hard time seeing why you would want the overhead of
| microservices.
| atoav wrote:
| I think microservices can become a trap where you think you might
| need one, but actually you don't -- a bit like blockchains a
| microservice structure solves very specific issues at a cost. Not
| everybody has these issues. Many people seemingly wanted to have
| these issues so they can justify using that hip tech, while
| forgetting the tradeoffs involved.
|
| Drawing a line in the sand between parts of your service and
| creating common interfaces between them is not a bad idea, but
| I'd argue that doing so too early brings in a cost of constantly
| dealing with the communications within your service.
|
| It is a similar issue to programmers who try to write everything
| generic from the start or optimize prematurely: it can get in the
| way of productivity and make your service inflexible in a
| development phase where it should still be very flexible.
|
| That being said I believe the core ideas of microservices applied
| at the right time in the right project would do wonders, but just
| like with blockchain the hardest part might actually be to decide
| when to use it and when not to.
| Minor49er wrote:
| Careful consideration must be taken with a microservice
| architecture. The ideal situation is that each instance can work
| on its own and pass it along to the next microservice in your
| application. Having to reach out to other services for additional
| data would be kept to a minimum. This way, any given instance can
| be swapped out if or when it's needed without affecting the
| application.
|
| However, as the application grows, it will most likely encounter
| scenarios where each microservice needs to do something more than
| what it was originally intended to do. A service might need
| information from an API or would need to access additional data
| from a database somewhere before it can work properly. And if
| that's the case, these hypothetical APIs and databases might be
| needed in other parts of the application as well. So now instead
| of everything being structured nicely with interchangable
| instances, you are now dealing with a network where any given
| node might not be able to be updated independently of the others.
| It can quickly become a large mess.
|
| That aside, depending on the needs of your application and how
| it's set up, the various microservices can create a much larger
| cost than something like a monolithic system. Typically, each
| service would exist on its own instance, and your hosting
| provider will happily help you figure out your usage needs and
| the price that will come along with it.
| bjourne wrote:
| Software development is about managing complexity. Think about it
| like this. If the number of lines of code in a piece of software
| is N, then the amount of effort required for managing that
| software is N^2 (or N^1.5, or whatever). Some people believe that
| by properly organizing software development, you can minimize or
| completely get rid of the exponential growth of the complexity.
| The idea is that the amount of effort for managing software
| containing N lines of code should be N.
|
| Microservices tries to organize software so that complexity is
| minimized. In my experience, they completely fail to do so.
| Rather they actually increase the complexity by putting related
| pieces of systems far apart from each other. I think it is better
| to "embrace the complexity" and to concede that software
| development is difficult. Better developer tools and stronger
| developers are better methods for dealing with complexity than in
| vain trying to minimize complexity.
___________________________________________________________________
(page generated 2021-05-27 23:03 UTC)