Microservices are a tax your startup probably can't afford • Hacker News Board

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

#171

Post by hosh » Thu, May 08, 2025, 5:42 PM UTC

One of the advantages of the BEAM / OTP ecosystem (Erlang, Elixir, and friends) is that you can construct "microservices" and think through what that means, all within a monolith. When it comes time to break it out, you can.

> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains.

The BEAM language platform can cover scaling bottlenecks (at least within certain ranges of scale) and independently evolving domains, but has many of the advantages of working with a monolith when the team is small and searching for product-fit.

Like anything there are tradeoffs. The main one being that you'd have to learn how to write code with immutable data structures, and you have to be more thoughtful on how concurrent processes talk to each other, and what kind of failure modes you want to design into things. Many teams don't know how to hire for more Erlang or Elixir developers.

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

#172

Post by rglover » Thu, May 08, 2025, 5:45 PM UTC

The best architecture approach I've ever found is:

1. Start with a monolith

2. If necessary, set up a job server that can be vertically/horizontally scaled and then give it a private API, or, give it access to the same database as the monolith.

For an overwhelming number of situations, this works great. You separate the heavy compute workloads from the customer-facing CRUD app and can scale the two independent of one another.

The whole microservices thing always seemed like an attempt by cloud providers to just trick you into using their services. The first time I ever played with serverless/lambda, I had a visceral reaction to the deployment process and knew it would end in tragedy.

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

#173

Post by anonymars » Thu, May 08, 2025, 5:46 PM UTC

jayd16 wrote: post #45

actionfromafar wrote: post #11

Earlier quoted context omitted.

This is true, but monkey patching is scary. If you can switch over a monolith, and keep a rollback in case of trouble, do that. Make small changes in the monolith a time, though.

Btw, do any good, modern CI tools support incremental rollout of multiple in-flight changes on monoliths? As in patch A is live, team B wants to rollout A+B and team C wants to rollout A+C. Ideally, A+B+C will eventually go live. Do cloud/paas providers deeply support this flow anymore? Every dashboard would need to compare across multiple live versions and I haven't tried that in a while.

Wouldn't these just be different branches?

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

#174

Post by gopher_space » Thu, May 08, 2025, 5:47 PM UTC

bluefirebrand wrote: post #66

fallingknife wrote: post #33

Earlier quoted context omitted.

There are plenty of tech reasons for microservices. e.g. scaling high traffic services separately and separating low priority functionality from critical paths. I would agree that this is usually not a smart thing to do in a small org, but I have seen times where splitting out a high load path into a microservice has been very much worth it at a startup.

> scaling high traffic services separately This is a great optimization once you have high traffic services Building this way before you have any traffic at all is a great way to build the wrong abstractions because your assumptions about where your load will be might be wrong

Microservices are a technical solution to regional availability and pairing problems, and they start with a spreadsheet telling you when to make them based on requirements vs. cost. They're slow, expensive threads you should have a really good reason to use.

> Building this way before you have any traffic at all is a great way to build the wrong abstractions

These services only make sense to think about within specific traffic contexts. It'd be impossible to build the right abstraction.

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

#175

Post by roguecoder » Thu, May 08, 2025, 5:47 PM UTC

bunderbunder wrote: post #162

roguecoder wrote: post #94

Earlier quoted context omitted.

People misunderstanding Conway's Law is a big part of the problem for sure. The law says nothing about team boundaries: it talks about communication pathways. The paranoid socialist in me thinks big companies like team-sized microservices because it lets them prevent workers from talking to each other without completely ruling out producing running software. When companies instead encourage forums for communication a…

If team boundaries aren't a major influence on your communication pathways, what on earth do you even mean by "team"?

The most common alternative to organizing teams by service boundaries is to organize teams around the business problems to be solved. That is a lot easier to budget for than trying to staff by microservice boundary, doesn't have the coordination and planning overhead, and it means you aren't reliant on up-front planning to get to a functional solution or design.

In high-uncertainty greenfield development, Explore projects or Lean Startup-style experimentation, having developer be close to the users they are serving is very efficient.

It also lets those companies reteam frequently, without needing to change the software to match the new team boundaries, which is very helpful when growing the team.

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

#176

Post by speed_spread » Thu, May 08, 2025, 5:48 PM UTC

Espressosaurus wrote: post #60

devin wrote: post #15

Earlier quoted context omitted.

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.

I feel like it's only in the last 5 years in the tech publicity sphere that I've seen pushback against microservices, only it feels like only the last year or two where I see it to the exclusion of influencers pushing microservices. Things are different in the embedded space so I don't have personal experience with any of it.

Pushback was always there from the start. The first edition of O'Reilly's "Building microservices" recommended _against_ microservices, unless you absolutely tried scaling your monolith and team beforehand.

Any organization stuck in microservice hell fully deserves the punishment.

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

#177

Post by mjr00 » Thu, May 08, 2025, 5:50 PM UTC

roguecoder wrote: post #168

tuckerman wrote: post #90

Earlier quoted context omitted.

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.

That's even more true for microservices, though, since I have yet to see a microservice architecture that automatically runs end to end tests before deploying. The post I was replying to said "your build will still break": that's what I was taking issue with. In this day and age there is no reason our trunk build should ever be broken.

> I have yet to see a microservice architecture that automatically runs end to end tests before deploying.

One of the big tenets of independent services is that your APIs are contracts that don't change behaviour. As long as each individual service doesn't introduce breaking changes, the system as a whole should work as expected. If it doesn't this is indicative of either 1) a specific service lacking test coverage, or 2) doing something wrong i.e. directly reading from a microservices' database without going through an API.

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

#178

Post by no_wizard » Thu, May 08, 2025, 5:51 PM UTC

bob1029 wrote: post #146

no_wizard wrote: post #126

Earlier quoted context omitted.

>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.

>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.

Yes, you do have experience, and it may not match others. Thats my point. At previous jobs, I had terrible microservice experiences, they were everything people complained about them to be. Yet, by setting that aside and really diving into evaluation on merits, I came around on the idea because I understand the failures of my previous experience came to misapplication of the concepts, not the concepts themselves.

Thats what we need more of, the kind of evaluation and reflection one should do when making these decisions (or being apart of a group that does) and I don't think we should discount our own experiences, we should strive to separate them from the concepts of appropriate technical decision making, lest we become overly biased for or against something.

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

The most obvious is the independence microservices have. They're truly independent. Sometimes that is exactly what you want

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

#179

Post by pixl97 » Thu, May 08, 2025, 5:53 PM UTC

elktown wrote: post #155

pixl97 wrote: post #144

Earlier quoted context omitted.

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 clie…

Talk about an axe to grind. Are you really implying that AAA releases being bad might be due to not having microservices as a method?

No. I'm saying there is no real correlation to the quality of microservices and the quality of monorepos in games and the amount of work required to build each one as a quality software object.

Comparing a game to almost any other piece of software, especially web based software, is how you end up with broken abstractions and bad analogies.

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

#180

Post by roguecoder » Thu, May 08, 2025, 5:56 PM UTC

djtango wrote: post #119

roguecoder wrote: post #65

Earlier quoted context omitted.

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?

Sure!

Functional programming precludes encapsulation, so it doesn't scale indefinitely the way fractal paradigms can. Eventually, the complexity becomes overwhelming.

One effective solution to that is introducing microservices: programmers can still write entirely functional code, but have encapsulation in the form of services. They have to be micro, though, because conventionally-sized services are still big enough to strain the paradigm.

But I see junior engineers who aren't expected to think about the "architecture", by which they mean the modular design. They are handed a spec and they implement it, Mythical Man Month style. That treats organizing lines of code and organizing services as two completely-distinct activities, and depending on the company junior engineers are often not exposed to modular design until five or ten years into their careers.