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

Ask HN: Why Not Microservices?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 30 posts

Re: Ask HN: Why Not Microservices?

#11

Post by karmakaze »

acranox wrote: post #8

An issue I've seen happen is as the number of microservices grows, no one is keeping track of the service dependencies. So what happens is service A goes down, and then someone says "Service B is down too." and then people start thinking it's some wider outage (they always blame the network) but it turns out that Service B just depends on Service A, but it wasn't widely known. The issue then becomes that teams don't…

If a service A going down brings service B down, then microservices aren't divided right and/or too much data is being shared over the network rather than async transformed/copied. The only time this should matter is if there's a breaking change to the way services communicate which should be very well known, e.g. having to bump a protocol version number with downstream understanding before upstream.

Re: Ask HN: Why Not Microservices?

#12

Post by yongjik »

When done correctly, microservices can replace a gigantic single point of failure.

Unfortunately, what I sometimes see is that it's replaced by multiple interacting single points of failures - i.e., if any one of them fails the whole rube goldberg architecture fails, and there are so many different things that can fail! ...which is clearly worse than just having a monolith.

Re: Ask HN: Why Not Microservices?

#13

Post by deeblering4 »

I look at it as a part of staff size.

When a company gets large enough people start having time to write software that manages other software. And IMO microservices are a late-stage outcome of this.

Layers upon layers upon layers of abstraction being developed and maintained to help provide autonomy (within a certain context) while working with hundreds of other developers.

For the vast majority of use cases a few VMs or even bare metal cloud instances will be a lot more cost effective and stable.

Re: Ask HN: Why Not Microservices?

#14

Post by rajacombinator »

giantg2 wrote: post #10

Microservices can be good. The problem is that people don't use them right (partially because everyone was joining in the fade, so lots of bad examples). Dependency management, documentation, and loose coupling are important. I work at a company that embraced microservices, but it's basically architected as a distributed monolithic. And there's so much overhead for context switching, paperwork, etc. It's like how the…

Yea this sounds a lot like my current situation. Microservices sounded good, a lot were built over time, now no one wants to understand or own them so they’re just getting punted around aimlessly.

Re: Ask HN: Why Not Microservices?

#15

Post by rajacombinator »

sethammons wrote: post #6

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.

Have you run into problems where it hinders team scaling by creating too much cross-team friction?

Re: Ask HN: Why Not Microservices?

#16

Post by acranox »

karmakaze wrote: post #11
acranox wrote: post #8

An issue I've seen happen is as the number of microservices grows, no one is keeping track of the service dependencies. So what happens is service A goes down, and then someone says "Service B is down too." and then people start thinking it's some wider outage (they always blame the network) but it turns out that Service B just depends on Service A, but it wasn't widely known. The issue then becomes that teams don't…

If a service A going down brings service B down, then microservices aren't divided right and/or too much data is being shared over the network rather than async transformed/copied. The only time this should matter is if there's a breaking change to the way services communicate which should be very well known, e.g. having to bump a protocol version number with downstream understanding before upstream.

Yeah, everyone knows this. The question as I understood it, was to ask what are some downsides to microservices. And that, to me, includes how they are implemented and managed in the real world, rather than some perfect hypothetical world where everyone did everything by the book.

Re: Ask HN: Why Not Microservices?

#17

Post by sethammons »

rajacombinator wrote: post #15
sethammons wrote: post #6

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.

Have you run into problems where it hinders team scaling by creating too much cross-team friction?

The big issues we had were because we had different services reaching into and editing the same db tables in some cases. Re-architecting to have all data access via a new API (instead of direct DB access) across 13 services ran by 8 different teams across 2 business orgs has proven hard.

The other thing that can be a pain is due to rigid agile sprints. Need a change? Well that might get into their next sprint but there are probably other, higher priorities, so maybe next quarter. Or team A just does the work on team B’s service, and waits for code reviews and quality checks.

Re: Ask HN: Why Not Microservices?

#18

Post by mu_killnine »

I work in an organization with a lot of internal line-of-business apps for manufacturing. While there might be hundreds or thousands of users, the problem just doesn't really warrant the extra steps that microservices requires to really work. (If my users want reporting, we can just run reports against the main database. We don't need some Report service implementing CQRS or Event Sourcing to put all the disparate pieces together...)

However, I will say we've taken some considerations from the microservices discussion to heart and thought more about fault-tolerance, ci/cd, and streamlining the deployment process so we've definitely gotten some value from the zeitgeist.

That said, most of our apps end up being a fairly relaxed monolith with some service integrations here and there. And you know what? It's pretty nice sometimes :)

Re: Ask HN: Why Not Microservices?

#19

Post by tuyguntn »

* more than 10 teams? -> microservices. this brings adding some guidelines: strict communication guidelines (api, events, cross team meetings)

* compliance requirements? -> (micro)services. you need to host some data and workers in separate guarded environments

* too many legacy third party dependencies which might fail or stop whole processes? -> wrap with service

* different independent products in a company? services

for everything else use monoliths

Re: Ask HN: Why Not Microservices?

#20

Post by aahortwwy »

Here's my opinion.

There are problems that are shared between monolith and microservice architectures, and there are problems that are different.

For the problems that are different, the ones faced in microservice architectures are considered "harder," and there are fewer battle-tested tools/ecosystems to help deal with those problems (though this second part is rapidly changing).

For the problems that are the same, adopting a microservice architecture will likely force you to solve those problems much earlier. This is dangerous because it takes effort which could be directed to improving your product instead, and you may find yourself solving them in a way which doesn't end up scaling for your organization.

I think they're great, but they require a level of consistent investment in tooling which is not in many organization's DNA.

Post reply on HN