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

231–240 of 272 posts

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

#231

Post by jamesfinlayson »

devin wrote: post #15
candiddevmike wrote: post #6

Earlier quoted context omitted.

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.

In my experience, it seems the majority of folks know the pitfalls of microservices, and have since like... 2016? Maybe I'm just blessed to have been at places with good engineering, technical leadership, and places that took my advice seriously, but I feel like the majority of folks I've interacted with all have experienced some horror story with microservices that they don't want to repeat.

> In my experience, it seems the majority of folks know the pitfalls of microservices, and have since like... 2016?

Majority maybe, but not everyone. I was at a place in 2018 where a guy turned up declaring that microservices would solve all of the company's performance issues (he'd heard that AWS S3 was made up of over 500 microservices so we must do the same, but he obviously had no idea about the depth of features in S3 so hit take was more is better).

So we got like 30 microservices in the space of year which gave the company 10x complexity, complicated and fragile local development and... dubious wins like faster email sending, but no improvements to true bottle-necks of the system.

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

#232

Post by jamesfinlayson »

MDGeist wrote: post #10
candiddevmike wrote: post #6

Earlier quoted context omitted.

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.

I've also seen the top down version where senior leadership like a CIO/CTO wants to put a huge "modernization" project on their resume and they don't care if it is impossible to maintain or falls over after they move on.

Oh yeah, I've come to realise that the people at the top are just as bad. I was at a place where "consultants decided" that the company's two backbone systems should be replaced with off-the-shelf solutions. Very obviously a resume-padding project from the CIO who was in their first large company job, but which would have almost certainly crippled the company if it went ahead.

Thankfully the business and finance people at the company decided it would be an expensive and stupid idea it was shut down.

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

#233

Post by jamesfinlayson »

bcrosby95 wrote: post #62
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…

I call them nanoservices.

We joked about a microservice at a previous job in the same way - the frontend guys didn't want to include a dependency for generating a random ID so the microservice guy decided to build yet another microservice that did nothing but return random IDs.

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

#234

Post by jamesfinlayson »

steveBK123 wrote: post #41
abirch wrote: post #30

Earlier quoted context omitted.

Microservices are GREAT when 1 team owns each service. I haven't seen a good use case when you have 1 team supporting multiple microservices.

Every org I've tried to see push microservices did exactly the wrong version. Rather than 1 micro service per team, which many devs.. it was some team that owns 20 services, generally way more services than developers. It's probably just how non-lean Mag7 were in peak vs how lean most other orgs that try to ape them are.

Yep, I remember working at a place where one team churned out a large majority of the microservices and the other three teams just kept on doing their thing.

The microservice team were especially terrible because the did all the initial work and basked in the "glory", but when it came to maintaining the services, they wanted nothing to do with it.

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

#235

Post by eddyfromtheblok »

wmf wrote: post #181
ljm wrote: post #44

Earlier quoted context omitted.

One place I worked at got sold on microservices by Thoughtworks, along with a change to Java as the main language to be used. As one would expect, they made bank from their consulting endeavor and rode off into the sunset while the rest of us wasted several years of our careers rewriting ugly but functional monolithic code into distributed Java based microservices. We could have been working on features and product b…

What language was used before Java?

probably java, i doubt decision makers want a rewrite unless they want to bring in hungry young developers and accept some hiccoughs

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

#236

Post by gad21034 »

Trying to force fit a monolith/modulith is also a problem. I've seen overreactions to fears about having separate services create suboptimal solutions. The real answer is that you have to make the right solution for the problem you're facing without lapsing into a dogma. Humans tend to be pretty bad at this and want simple rules of thumb. The only rule I would endorse almost blindly is, don't start with microservices. The rest depends on what happens with your business and in what time frame. After building a company from scratch to 15 devs and experiencing tons of services at Spotify, I would recommend:

- monolith to start with very little time spent on code architecture patterns like DDD (although these days with llms I would say go for it and use DDD patterns in your prompts)

- optimize code cleanliness by adhering to better code architecture patterns

- when it feels like you are doing weird things to scale a process on the monolith (scheduling background tasks where you could break out a pubsub to function service and defend your uptime while coordinating on a shared DB), drop any religion around no micro services.

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

#237

Post by grg0 »

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…

> sounds wrong

It's not wrong at all, literally Conway's law: https://en.wikipedia.org/wiki/Conway's_law

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

#238

Post by about3fitty »

bityard wrote: post #123
candiddevmike wrote: post #6

Earlier quoted context omitted.

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.

It could also just be plain old overengineering. Like using Django and leaning on all of the magic contained within it just to implement a simple API that could instead be a very small Flask or FastAPI app.

Unforeseen scope creep is the reason to utilise Django over Flask, I feel.

Also, you can pick and choose what to use in Django similarly to Flask - it just has a higher initial learning curve.

Once you get to sufficient levels of complicated, leaning on established, documented, community supported design patterns and abstractions helps vs. sorting out your imports, making bespoke design choices, and doing a bunch of non-core value producing work.

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

#239

Post by andreygrehov »

I used to love monoliths, but I just can’t do it anymore. After many years of development, my brain simply resists building another one. My solo side project now consists of 12 AWS accounts, separate code repositories, separate pipelines, and separate infrastructure-as-code repositories. Some might say that’s insane—and fair point—but to me, it’s insane to pack everything together. If I know that my public API is sitting right next to customer data, that’s a red flag. No network isolation? Red flag. DNS management in the same account? Another red flag. To me, separation of concerns makes development much leaner. Things just work.

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

#240

Post by 0cf8612b2e1e »

about3fitty wrote: post #238
bityard wrote: post #123

Earlier quoted context omitted.

It could also just be plain old overengineering. Like using Django and leaning on all of the magic contained within it just to implement a simple API that could instead be a very small Flask or FastAPI app.

Unforeseen scope creep is the reason to utilise Django over Flask, I feel. Also, you can pick and choose what to use in Django similarly to Flask - it just has a higher initial learning curve. Once you get to sufficient levels of complicated, leaning on established, documented, community supported design patterns and abstractions helps vs. sorting out your imports, making bespoke design choices, and doing a bunch of…

I will forever beat the Django over Flask drum. Nothing ever stays simple. Maybe today it is one single view function, but tomorrow someone is going to want to add authentication, emails, whatever. Django might have features you do not need, but it would be an unusual situation where Django is holding you back vs Flask.
Post reply on HN