Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need Microservices

medium.com

Post reply on HN
Print view View original

21–30 of 169 posts

Re: You Don't Need Microservices

#21

Post by xwolfi »

pmelendez wrote: post #7

>Modularize Your Monolith It is true that probably any monolith can be break down into components, that won't prevent the full redeployment (and all the risks that it brings) though. I think in reality no one needs Microservices, or Monolith for that matter. You would pick the poison that adjust the best to your needs.

Or do the whole redeployment all the time and you'll see the "risk" of doing so was psychological or a few better tests away.

I work in a 150+ yo company where change is ... well not welcome. When we said we could try to release without schedule, several times a week, whenever we want just because we finished one thing at a time, you should have seen their looks. We have 100 microservices doing low latency trading in 13 stock exchanges in heavily regulated Asia, trading $bn a day - it kinda has to work day after day and "the risk" of deploying "the whole" think more than once a quarter was terrifying.

Well a few better tests and a bit of bravery and now I just do "the full redeployment" whenever I want. Some teeth are still grinding but what can I say, we still banking lol, and now when we find a bug, we don't wait for months to fix it.

Re: You Don't Need Microservices

#22

Post by sorokod »

chaoz_ wrote: post #19

> Fault Isolation > The ability for a single feature of your application to go down without taking the rest down with it is a big bonus of a properly designed microservices architecture. Yes, but it also comes with a cost. Microservices might still fail in a cascade manner and bringing such system up under significant load is even more challenging.

Also known as "multiple points of multiple failures".

Re: You Don't Need Microservices

#23

Post by jmartrican »

Is this analogous to saying "you dont need TDD cause you can always write your tests after the code is written"? Or "you dont need encapsulation because you can just ignore the parts of the code you should not be touching"?

Re: You Don't Need Microservices

#24

Post by hatware »

Isn't the devil in the details? Some problems are solved better as Microservices. Some problems are solved better as monoliths. Ultimately it is the lack of maintaining the solution we choose that leads to the "grass is greener" fad chase.

Re: You Don't Need Microservices

#25

Post by orwin »

hericium wrote: post #12

Microservices are a great way to promote cloud vendors' offerings and complicate IT life with over-engineered "standards" like Kubernetes. Big corp wins while their customers create DevOps and other buzzword teams and the majority of IT world loses the capability to actually administer systems and becomes users addicted to ever-changing vendor offerings that complicate learning useful stuff outside.

I'm working on an internal service that do not benefit being set up on kubernetes (it is basically a cronjob that runs everyday, collect data from every third party software, consolidate it and send it in a s3). It could be run on a small vm, deployed with ansible.

But i understand why, for streamligning purpose, we use kubernetes. It makes the networking "easier", and i feel it integrate better with other CI/CD tools than ansible. It is only a feeling since the ansible version i used to use was quite old, so i might be wrong.

Re: You Don't Need Microservices

#26

Post by taude »

I'd love to see more of these "you don't need microservices' type of articles be more prescriptive on when you might need them. 20 product scrum teams? 10 different team? Certain functional team separate (like you have a data infra team, search, payment processing)?

I always can't help but to think most of these articles are written by engineers working at 30 people startups or something. And there's definitely a lot of org-size and structure between the startup and a faang-sized tech giant.

Re: You Don't Need Microservices

#27

Post by mirekrusin »

vasergen wrote: post #20
revskill wrote: post #17

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

Micro-services also good when an organization has a numbers of teams with different domains and release cycles, at some point it would be easier to spit code in some ways and have a boundaries. In this case splitting to services/micro-services creates those boundaries on a network level.

Why micro-?

Re: You Don't Need Microservices

#28

Post by Sevii »

taude wrote: post #26

I'd love to see more of these "you don't need microservices' type of articles be more prescriptive on when you might need them. 20 product scrum teams? 10 different team? Certain functional team separate (like you have a data infra team, search, payment processing)? I always can't help but to think most of these articles are written by engineers working at 30 people startups or something. And there's definitely a lot…

I worked on a SOA setup and we hit the inflection point somewhere around 50-100 devs contributing code to the service. Honestly, we should have taken splitting up the service more seriously earlier.

Re: You Don't Need Microservices

#29

Post by jacquesm »

vasergen wrote: post #20
revskill wrote: post #17

Microservice is to manage junior level programmers who don't know how to make loosely coupling architecture. That's it. Because your job is to manage low quality code produced by junior devs, you need to use microservice to prevent bad code to break the monothlic. Edit: For more context, this opinion is more about "the art of developer management", not much about infra, security, scalability stuff

Micro-services also good when an organization has a numbers of teams with different domains and release cycles, at some point it would be easier to spit code in some ways and have a boundaries. In this case splitting to services/micro-services creates those boundaries on a network level.

Just 'services' will do. A couple of them tied together with a single front is >> a monolith.
Post reply on HN