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

101–110 of 272 posts

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

#101

Post by shooker435 »

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…

In addition to having 1 service with vastly different scaling requirements, having 1 service with vastly different availability requirements may make sense to separate as well.

If you need to keep the lights or maintain an SLA and can do so by separating a concern, it can really reduce risk and increase speed when deploying new features on "less important" components.

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

#102

Post by jounker »

elevatedastalt wrote: post #52
singron wrote: post #12

Earlier quoted context omitted.

> You'll have a monolith, it might break out into frontend, backend and a separate service for async background jobs And when you break these out, you don't actually have to split your code at all. You can deploy your normal monolith with a flag telling it what role to play. The background worker can still run a webserver since it's useful for healthchecks and metrics and the loadbalancer will decide what "roles" get…

If you are building the same binary for all microservices you lose the dependency-reduction benefit microservices provide, since your build will still break because of some completely unrelated team's code.

You’ll still get some isolation since not all pathways share the same code. It’s not all or nothing.

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

#103

Post by shooker435 »

parpfish wrote: post #80

I’ve read a lot of pros/cons about micro services over the last decade, but don’t have a clear definition for what qualifies. My current job insists that they have a “simple monolith” because all the code is in a single repo. But that repo has code to build dozens of python packages and docker containers. Tons of deploy scripts. Different teams/employees are isolated to particular parts of the codebase. It feels a lo…

Sounds like microservices deployed from a monorepo...

Which honestly may be the future if LLMs stay in a dev's toolkit. Plugging in an AI model to a monorepo provides so much context that can't be easily communicated across microservices in separate repos.

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

#104

Post by jimbokun »

roguecoder wrote: post #77
elevatedastalt wrote: post #52

Earlier quoted context omitted.

If you are building the same binary for all microservices you lose the dependency-reduction benefit microservices provide, since your build will still break because of some completely unrelated team's code.

If it is possible for that other team to merge a broken build, you are doing it wrong. If you are concerned about someone else breaking your thing, good! You were going to eventually break it yourself. Write whatever testing gives you confidence that someone else's changes won't break your code, and, bonus, now you can make changes without breaking your code.

What about when it’s you breaking your own thing?

A very large code base full of loosely related functionality makes it more and more likely a change in one part will break another part in unexpected ways.

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

#105

Post by frollogaston »

demarq wrote: post #92
didip wrote: post #58

Micro services show their benefits in a large organization. It’s a tool to solve people issues. They can remove bureaucratic hurdles and allow devs to somewhat be autonomous again. In a small startup, you really don’t gain much from them. Unless if the domain really necessitates them, eg. the company uses Elixir but all of the AI toolings are written in Python/Go.

One of those teams need to go.

If they're doing two very different things, why?

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

#106

Post by hereonout2 »

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?

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

#108

Post by Akronymus »

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…

I personally wouldnt even call those microservices, but rather treat them closer to how a DB server is usually separate from an application one.

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

#109

Post by CharlieDigital »

Google had a really great paper on this about 2 years back titled Towards Modern Development of Cloud Applications[0] that talks about how teams often:

    > ... conflate logical boundaries (how code is written) with physical boundaries (how code is deployed)
It's very easy to read and digest and I think it's a great paper that makes the case for building "modular monoliths".

I think many teams do not have a practical guide on how to achieve this. Certainly, Google's solution in this case is far too complex for most teams. But many teams can achieve the 5 core benefits that they mentioned with a simpler setup. I wrote a about this in a blog post A Practical Guide to Modular Monoliths with .NET[1] with a GitHub repo showing how to achieve this[2] as well as a video walkthrough[3]

This approach has proven (for me) to be easy to implement, package, deploy, and manage and is particularly good for startups with all of the qualities mentioned in the Google paper without much complexity added.

[0] https://dl.acm.org/doi/pdf/10.1145/3593856.3595909

[1] https://chrlschn.dev/blog/2024/01/a-practical-guide-to-modul...

[2] https://github.com/CharlieDigital/dn8-modular-monolith

[3] https://www.youtube.com/watch?v=VEggfW0A_Oo

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

#110

Post by westurner »

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.

Does [self-hosted, multi-tenant] serverless achieve similar separation of concerns in comparison to microservices?

Should the URLs contain a version; like /api/v1/ ?

FWIU OpenAPI API schema enable e.g. MCP service discovery, but not multi-API workflows or orchestrations.

(Edit: "The Arazzo Specification - A Tapestry for Deterministic API Workflows" by OpenAPI; src: https://github.com/OAI/Arazzo-Specification .. spec: https://spec.openapis.org/arazzo/latest.html (TIL by using this comment as a prompt))

Post reply on HN