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

81–90 of 272 posts

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

#81

Post by frollogaston »

BoardsOfCanada wrote: post #63
jihadjihad wrote: post #4

Microservices [0] > grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too > seem very confusing to grug 0: https://grugbrain.dev/#grug-on-microservices

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.

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

#82

Post by bob1029 »

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 eternity by comparison to a local method. Arguments can be made that the latency can be "hidden", but this is generally only true for the more trivial kinds of problems. For many practical businesses, you are typically in a strictly serialized domain which means that you are going to be forced to endure every microsecond of delay. Assuming that a transaction was not in conflict doesn't work at the bank. You need to be sure every time before the caller is allowed to proceed.

The tighter the latency domain, the less you need to think about performance. Things can be so fast by default that you can actually focus on building what the customer is paying for. You stop thinking about the sizes of VMs, who's got the cheapest compute per dollar and other distracting crap.

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

#85

Post by frollogaston »

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…

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

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

#86

Post by Scarblac »

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 microservices. With microservices you split off basically everything that would be a module in a normal application.

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

#88

Post by bzmrgonz »

I agree, most startups could do with a decent hypervisor plus vps for web visibility, but honestly selfhosting is fine. I'm surprise no one has built a startup environment in a box of boxes (pfsense/truenas/proxmox/minIO/openwrt), if you want bleeding edge, add microcloud from canonical or incus.

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

#89

Post by mjr00 »

monero-xmr wrote: post #76
mjr00 wrote: post #61

Earlier quoted context omitted.

Folder and file structure and separation of concerns doesn't change the fact that if you have one deployable artifact, it's all sharing the same runtime when deployed. Which means the underlying versions of Java/Go/Python/etc, or core shared libraries, all need to be updated at the same time. All the code is far more coupled than it first seems.

All of that is so much easier with a single monorepo

Monorepo is orthogonal to services though. You can have a monorepo with multiple services in it.

Even with a monorepo, you will hit a point where you have 1, 10, 100 million lines of e.g. Python, realize you should upgrade from 3.8 to 3.14 because it's EOL, and feel a lot of pain as you have to do a big-bang, all-at-once change, fixing every single breaking change, including from libraries which you also have to update. There's no way around this in current mainstream languages.

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

#90

Post by tuckerman »

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.

Even if it builds successfully, I've never worked anywhere where automated tests prevented 100% of problems and I doubt I ever will. For most systems of sufficient complexity you are testing in prod, even if you did a lot of testing before prod as well.
Post reply on HN