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

111–120 of 272 posts

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

#111

Post by bitcurious »

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 don't have continuity of work. You have one project for a few months, completely unrelated product for another few months. Microservice architectures are easier to build and maintain in that environment.

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

#112

Post by utmb748 »

Ensorceled wrote: post #50

Years ago I attended a local meetup where the CTO of a local startup gave a presentation on their, mostly successful, microservice rollout. In the Q&A after ward, another local startup CTO asked about problems their company was having with their microservices. The successful CTO asked two questions: "How big is your microservices tooling team?" and "How big is your Dev Ops Team?" His point was, if you're development…

Was in org with 10 people devops dedicated team, it was smooth, also as a dev could push requests for their repos... but also only 3 devops and they were so busy my requirement for basic stuff was burried in backlog. You can develop but still need to maintain from the to time.

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

#113

Post by hnthrow90348765 »

candiddevmike wrote: post #6
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…

Some resume driven developers will choose microservices for startups as a way to LARP a future megacorp job. Startup may fail, but they at least got some distributed system experience. It takes extremely savvy technical leadership to prevent this.

Hiring will need to change to stop resume-driven development (can't eliminate it completely though), because you're likely to only get monolith roles if you only work on monoliths. Only being able to speak about microservices puts you in the "talk the talk, not walk the walk" category.

It would also nice to have less fear-driven career advice like "your skills go out of date" which drives people to try adopting the latest things.

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

#114

Post by dimal »

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 saw one startup with about fifty engineers, and dozens of services. They had all of the problems that the post describes. Getting anything done was nearly impossible until you were in the system for at least six months and knew how to work around all the issues.

Here’s the kicker: They only had a few hundred MAUs. Not hundreds of thousands. Hundreds of users. So all this complexity was for nothing. They burned through $50M in VC money then went under. It’s a shame because their core product was very innovative and well architected, but it didn’t matter.

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

#115

Post by pydry »

sergiotapia wrote: post #64

microservices are a gigantic waste of time. like TDD. it takes skill and taste to use only enough of each. unfortunately a lot of VC $$$ has been spent by cloud companies and a whole generation or two of devs are permasoiled by the micro$ervice bug. don't do it gents. monolith, until you literally cannot go further, then potentially, maybe, reluctantly, spin out a separate service to relieve some pressure.

like TDD, microservices are a waste of time if you do it the wrong way and for the wrong reasons.

Like TDD, theyre great if done in the right way for the right reasons.

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

#116

Post by xcskier56 »

Scarblac wrote: post #86
xcskier56 wrote: post #74

Microservices make sense from a technical perspective in startups if: - You need to use a different language than your core application. E.g. we build Rails apps but need to use R for a data pipeline and 100% could not build this in ruby. - You have 1 service that has vastly different scaling requirements that the rest of your stack. Then splitting that part off into it's own service can help - You have a portion of…

Splitting off a few services from an application is not the same as using micro services. With microservices you split off basically everything that would be a module in a normal application.

I think that really depends on your definition. But I will also contend that even splitting your system into 2 or 3 services if it's not for strong reasons will 100% slow you down and cause long term headaches.

One project that I helped design had to split out a segment of the system b/c the data was eligibility records coming from health plans. This data had very different security and lifecycle requirements (e.g. we have to keep it for 7 or 10 years). Splitting out this service simplified some parts but any time we need to cross the boundary between the 2 services, the work takes probably twice as long as it would if it were in a single service. I don't think it was the wrong decision, but it the service definitely did not come for free

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

#117

Post by Akronymus »

esafak wrote: post #17
no_wizard wrote: post #3

They have their place. In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service. For example, we have a authentication microservice at work. It makes sense that it lives outside of the main application, because its used in a multiple different contexts and the service boundary allows for it to be more responsive to changes, upgrades and security fixes than having it be…

I don't think this merited a wiki link :)

And I dont see how the link detracts from the post at all. For ESL people, like me, it can be quite helpful to have such a link. (i find myself looking up such phrases quite often)

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

#118

Post by jimbokun »

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 thought the linked article about how Khan Academy eventually migrated to multiple services was a good example of when introducing micro services is a good idea:

https://blog.khanacademy.org/go-services-one-goliath-project...

They had already scaled the mono service about as far as it could go and had a good sense of what the service boundaries should be based on experience.

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

#119

Post by djtango »

roguecoder wrote: post #65
monero-xmr wrote: post #51

Earlier quoted context omitted.

We solve the problem of 50 devs working in a single monolith with folder and file structure, separation of concerns, basic stuff like this

Part of the problem is that many current programmers came up through functional programming or framework-based development. Microservices are often the first time they encountered modular programming or encapsulation, and so they equate "literally any architecture" with "microservices". I've worked on monoliths with 400+ developers that were great, but it takes skills that people who have only ever worked in orgs tha…

Could you elaborate on how functional programming relates to people's relationship with Microservices?

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

#120

Post by roguecoder »

frollogaston wrote: post #81
BoardsOfCanada wrote: post #63

Earlier quoted context omitted.

Because the network call turns the rule into a law.

This is also why app backends don't really need statically typed languages, no matter how big the company is. You have a well-defined API on the front, and you have a well-defined DB schema on the back, that's good enough. The static typing makes even less sense at finer code scopes, like I don't need to keep asserting that a for-loop counter is an int.

"Need"? Probably not. But unlike microservices they don't really have downsides (at least not with modern IDEs and the automatic refactorings they support) and they do offer some benefits.

Statically-types languages are a form of automatically-verified documentation, and an opportunity to name semantic properties different modules have in common. Both of those are great, but it is awkward that it is usually treated as an all-or-nothing matter.

Almost no language offers what I actually want: duck typing plus the ability to specify named interfaces for function inputs. Probably the closest I've found is Ruby with a linter to enforce RDoc comments on any public methods.

Post reply on HN