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

Microservices are a tax your startup probably can't afford

nexo.sh

Post reply on HN
Print view View original

141–150 of 272 posts

Re: Microservices are a tax your startup probably can't afford

#141

Post by karmakaze »

I've worked in monoliths done poorly and well, as well as bad and good implementations of microservices (even if done for the wrong reasons). The part of this post on 'if you go microservices' doesn't state things strongly enough. My takeaways comparing what worked vs what didn't:

- Use one-way async messaging. Making a UserService that everything else uses synchronously via RPC/REST/whatever is a very bad idea and an even worse time. You'll struggle for even 2-nines of overall system uptime (because they don't average, they multiply down).

- 'Bounded context' is the most important aspect of microservices to get right. Don't make -services. You can make a UserManagementService that has canonical information about users. That information is propagated to other services which can work independently each using the eventually consistent information they need about users.

There's other dumb things that people do like sharing a database instance for multiple 'micro'-services and not even having separately accessible schemas. In the end if done well, each microservice is small and pleasant to work on, with coordination between them being the challenging part both technically and humanly.

Re: Microservices are a tax your startup probably can't afford

#142

Post by tstrimple »

asim wrote: post #2

> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value. Basically this. Microservices are a design pattern for…

I put my team through this as an inexperienced lead about 15 years ago. We were a team of less than a dozen who had a nice single solution file that you could build and run the entire stack from. At the end we were looking at roughly a dozen services all which required orchestration to get them running and working together. First hand lessons in YAGNI and "do the simplest thing that works" which have stuck with me the rest of my career.

Re: Microservices are a tax your startup probably can't afford

#143

Post by codr7 »

bob1029 wrote: post #82

Monolith really is the best path and I question if you couldn't make it work in ~100% of cases if you genuinely tried to. One should consider if they can dive even deeper into the monolithic rabbit hole. For example, do you really need an external hosted SQL provider, or could you embed SQLite? From a latency & physics perspective, monolith wins every time. Making a call across the network might as well take an etern…

Containerization unfortunately pretty much killed embedded DBs; it's a shame, because you can squeeze a lot of performance out of not having to access the DB over a network.

Re: Microservices are a tax your startup probably can't afford

#144

Post by pixl97 »

elktown wrote: post #133
eloisant wrote: post #42

Earlier quoted context omitted.

1 team supporting multiple services is not great, but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. That's why I don't like the term "microservice", as it suggests each service should be very small. I don't think it's the case. You can have a distributed system of multiple services of a decent size. I know "services of a decent size" isn't as catchy as…

> but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either. Why can the game industry etc somehow manage this fine, but the only place where it's actually possible to adapt this kind of artificial separation over the network, it's somehow impossible not do it beyond an even lower number of devs than for a large game? Suggests confirmation bias to me. The main p…

How many of those game developers are actually art and asset developers?

How many times have AAA releases been total crap?

How many times have games been delayed by months or years?

How many times have games left off features like local LAN play, and instead implemented a 'microservice' as a service for online play?

How many times have the console manufactures said "Yea, actually you have the option of running a client server architecture with as many services you want?"

Re: Microservices are a tax your startup probably can't afford

#145

Post by frollogaston »

no_wizard wrote: post #134
frollogaston wrote: post #85

Earlier quoted context omitted.

The DB part can also get technical as performance comes into play. Most startups are probably not encountering this problem, but they could.

This may explain some of the popularity resurgence of SQLite (including distributed SQLite) It makes Database Per Customer type apps really easy, and that is something alot of SaaS products could benefit from.

Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.

Re: Microservices are a tax your startup probably can't afford

#146

Post by bob1029 »

no_wizard wrote: post #126
bob1029 wrote: post #82

Monolith really is the best path and I question if you couldn't make it work in ~100% of cases if you genuinely tried to. One should consider if they can dive even deeper into the monolithic rabbit hole. For example, do you really need an external hosted SQL provider, or could you embed SQLite? From a latency & physics perspective, monolith wins every time. Making a call across the network might as well take an etern…

>I question if you couldn't make it work in ~100% of cases if you genuinely tried to. You could say this about almost any pattern, if you genuinely tried to make microservices work it could work in ~100% of cases, I'm sure of that. Its this pattern of dismissing or accepting a solution with strong prejudice you don't evaluate the merits is the real problem. Thats the true behavior we need to get away from. We as an i…

> Its this pattern of dismissing or accepting a solution with strong prejudice you don't evaluate the merits is the real problem.

I spent a solid 3 years of my career attempting to make micro service architecture work in a B2B SaaS ecosystem. I have experience. This is not prejudice.

> modular monoliths

I don't see the meaningful difference between this and microservices.

Re: Microservices are a tax your startup probably can't afford

#147

Post by roguecoder »

dkarl wrote: post #75

My current take on microservices is that people pay serious attention to modularity and API design in the context of microservices. They work hard to break down the problem properly and design good interfaces between parts of the system. In monoliths, they generally don't. There's no logical reason why you couldn't pay as much attention to decomposition and API design between the modules of a monolith. You could have…

Bingo!

Every good monolith I've worked in (and I have worked in several, including one that was more than twenty years old) was highly-modular, well-designed with an easy-to-explain architecture.

The other thing they had in common was that code reviews talked about the aesthetics of the code and design, instead of just hunting for errors or skimming for security problems. It was relatively common to throw out the first proposed PR and start over, and that was fine because people were slicing the work small enough they were posting four to six PRs a week anyway.

It took the engineers at the company being willing to collaborate on the craft of software development and prioritize the long-term health of the code over short-term feature delivery. And the result of being willing to go a little bit slower day-to-day was that the actual feature delivery was faster than anywhere else I've ever worked.

Without a functioning professional culture, nothing is going to be great. But at least with microservices people do have to design an API at some point.

Re: Microservices are a tax your startup probably can't afford

#148

Post by utmb748 »

siliconc0w wrote: post #54

The biggest wins for microservices aren't really technical, they're organizational. They force you to break a problem down and allow each team to own a piece of it, including end to end delivery. This allows specialization of labor which is a key driver of productivity - including an ability to experiment and innovate. Every change is incremental by default, and well-documented external APIs are the only way to talk…

Could kept infra as a code, logging, auth and so on in packages, gRPC or message queues for communication, telemetry, monitoring/alerts and more stuff as a code too... got to the point creating new service was just new repo, name, port a resource utilization.

Agree with organizational win, also smaller merge requests in the team were superb.

Around 5-10 devs, monolith, we ran into conflicts more often, deployment, bigger merge requests, releasing by feature was problematic, microservices made team more productive, but rules about tests/docs/endpoints/code were important.

Re: Microservices are a tax your startup probably can't afford

#149

Post by codr7 »

hereonout2 wrote: post #106
bossyTeacher wrote: post #19

Problem is that, come recruiting time, interview gatekeepers are filtering out candidates who don't have the shiny words of the season, see micro services, unit tests, lots of abstractions, etc. It's like a dating app game. Everyone knows is overblown but they are still playing the game. The idea that not every company needs to make the same architectural and technological decisions is a concept way too complex for i…

Are unit tests a shiny fad? Second time I've seen it mentioned in this thread. Is there some other type of testing I should be doing, or have I been doing it all wrong for the last two decades?

Integration testing?

Less mocking, more bang for the buck.

Re: Microservices are a tax your startup probably can't afford

#150

Post by roguecoder »

codr7 wrote: post #125
bitcurious wrote: post #111

I'll go against the grain and say that microservices have advantages for small dev teams embedded in non-tech orgs. 1. You get to minimize devops/security/admin work. Really a consequences of using serverless tooling, but you land on a something like a microservices architecture if you do. 2. You get can break out work temporally. This is the big one - when you're a small team supporting multiple products, you often…

Microservices minimize devops/security/admin work? What planet are you living on?

I assume he means building the product out of AWS legos like Lambdas. Stick it all under one account, manage it manually instead of trying to deal with Terraform and it isn't too bad.

Heroku is still way easier, though.

Post reply on HN