Microservices are a tax your startup probably can't afford

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.

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

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

Keyword driven and filtered application processes also heavily incentivize adding into projects whatever is being posted on jobs sites. If microservices are part of a company's standard template for developer postings, people who want to work at that company will find a way to get it on their resume.

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.

"Cloud Migration"

So true. It was in March that I saw on HN an advertisement for a vibe coder with 3 years experience. I believe the term "vibe coding" was invented a month before! Buzzword hiring is as bad as resume driven development.

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.

Bad software dev. degrees that focus on fancy architecture that brings nothing to the table except overhead.

Do you not care about the users either? They too will lose the service if the company shutters.

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.

You have a point, but I wouldn't say this is a big deal unless there is a mammoth dependency somewhere that slow down things to a crawl. Then maybe that one part of the codebase can be broken into its own separate service.

But even then there are ways around this kind of problem with dynamic linking pre-built binaries and caching, but it is extra complexity that could be worse than managing multiple services. Docker cache can usually handle this pretty well though.

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

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.

> but a monolith with more than 50 developers working on it (no matter how you split your teams) isn't great either.

Why can the game industry etc somehow manage this fine, but the only place where it's actually possible to adapt this kind of artificial separation over the network, it's somehow impossible not do it beyond an even lower number of devs than for a large game? Suggests confirmation bias to me.

The main problem with microservices is that it's preemptive, split whatever you want when it makes sense after-the-fact, but to intentionally split everything up before-the-fact is madness.

I work on a monolith with ~1500 developers and it works pretty great.

The secret is that you're able to break a monolith apart, just like you can with microservices. You have APIs and modules of the monolith are responsible for their own thing. APIs are your contracts, just like in a microservice architecture.

The difference is that you can check if APIs are broken at compile time. In addition, you can view the API right in your IDE. In addition, your API isn't returning wishy-washy json with a half-assed OpenAPI spec - it's returning real types in a full-featured type system. And, cherry on top - you don't have to communicate over the network. Oh my god, you don't realize how many bugs and thousands of hours are wasted just working around that until you no longer have to. It's an immediate productivity boost.

But the best part is probably deployments. It's just so, so much more straightforward with one codebase.

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

I call them nanoservices.

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.

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

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.

Statically typed languages, when used correctly, save engineering time both as you extend your service and when thing go wrong as the compiler helps you check that the code you've written, to some degree, meets your specification of the problem domain. With a weak type system you can't specify much of the problem domain without increased labour but with a more expressive type system (and a team that understands how to use it) you can embed enough of the domain specification that implementing part of the business logic incorrectly or violating protocols turns into compile errors instantly rather than possibly leaking to production.

As for your comment on `any`, the reason why one doesn't want to fall back on such is that you throw out most of the gains of using static types with such a construct when your function likely doesn't work with `any` type (I've never seen a function that works on absolutely anything other than `id :: a -> a` and I argue there isn't one even with RTTI).

Instead you want to declare the subset of types valid for your function using some kind of discriminated union (in rust this is `enum`, zig `union(enum)`, haskell ADTs/GADTs, etc etc) where you set a static bound on the number of things it can be. You use the type system to model your actual problem instead of fighting against it or "lying" (by saying `any`) to the compiler.

The same applies to services, APIs, protocols, and similar. The more work the compiler can help you with staying on spec the less work you have to do later when you've shipped a P1-Critical bug by mistake and none of your tests caught it.

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

I forgot to add that "like I don't need to keep asserting that a for-loop counter is an int." is exactly what is happening with a dynamically typed language that is exactly what the runtime ends up doing unless it has a built-in range type to avoid that overhead and the loop variable cannot change while looping. With a static type checker that can be eliminated upfront as the compiler knows that it's an int and not suddenly a string as it's impossible to change the variable's type once it's defined thus all of the overhead of RTTI can be erased.

Javascript has to check on each iteration that the item is an int and for arrays that the length of those arrays hasn't changed underneath along with a bunch of other things as the language doesn't guarantee that it can't change. Even the JIT compiler in use has to check "is this path still that I expect" as at any point the type of the variable used in the loop can change to something else which invalidates the specialization the JIT compiler emitted for the case of it being an int. When you don't use languages with static types you push all of this work on runtime which makes the program slower for every check it needs to do while offering none of the advantages you have with static types.

Thus with a for loop in say C you don't assert that it is an int each time you statically constrain it to be an int as the loop condition can well be based on something else even if int is the more common to use. For example in zig `for` only takes slices and integer ranges with any other type being a compile-error:

    var example: [1 << 8]usize = @splat(0);
    for (&example, 0..) |*num, int| num.* = int;

At a larger organization this could be, but there is nothing elixir could possibly be doing for the startup that go would not do.

Remember the whole topic here is avoiding this tax

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

Even tiny backends usually have, from the start, a database server, some web server / proxy to handle incoming requests and load balance or cache them, and then something running your actual code that requests are passed on to. That's so normal that we don't even think of them as separate services anymore, but they are.

Splitting off a few larger parts because they are self contained, have their own Ops characteristics and might be usable by other projects on their own, vs creating a service for every single entity in your domain modal (or whatever), that's quite a difference.

We have an auth service, a database service for raster geo data, a generic task runner. Those are services. They all have their own pretty unique architecture and stand on their own, they are used by but are separate from the project that they were made for.

Different services for customers, for orders, for invoices, for items in the shop, for items on an order, for promotions, that's microservices. They all look very similar and belong to the application.

(in my opinion this morning)

Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.

> The largest benefit of microservices has always been lifecycle management, and "clear interfaces" in "modular monoliths" does not in fact solve that.

What lifecycle are we really talking about? There are massive monoliths - like the Linux kernel or PostgreSQL - with long lifespans, clear modularity, and thousands of contributors, all without microservices. Lifecycle management is achievable with good architecture, not necessarily with service boundaries.

> If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams.

This is a vague argument. In a microservice architecture, if multiple systems rely on the structure or semantics of logs — or any shared behavior or state - updating one service without coordination can just as easily break integrations. It’s not the architecture that protects you from this, but communication, discipline, and tests.

> It also means on critical systems separating high risk and low risk changes are not possible.

Risk can be isolated within a monolith through careful modular design, feature flags, interface boundaries, and staged rollouts. Microservices don’t eliminate risk - they often just move it across a network boundary, where failures can be harder to trace and debug.

I’m not against microservices. But the examples given in the comment I responded to reflect the wrong reasons (at least based on what I’ve seen in 15+ years across various workplaces) for choosing or avoiding a microservice architecture.

Microservices don’t solve coupling or modularity issues — they just move communication from in-process calls to network calls. If a system is poorly structured as a monolith, it will likely be a mess as microservices too — just a slower, harder-to-debug one.

> Every situation should be evaluated on merits. This came across that there is also an assumption that we didn't try other solutions first - we absolutely did.

I completely agree. But this a little bit contradicts with your original comment that caught my eye:

> In my experience, a good rule of thumb[0] is if there are actual benefits from being a standalone service.

A rule of thumb is, by nature, a generalization — it simplifies decision making through heuristics. Benefits on the other hand always subjective, they can be interpreted in a given context.

And based on my experience, there will always be some benefits that can be used to justify factoring something out into a separate service. The challenge is that it's often easy to overemphasize those benefits, even when they don't outweigh the downsides. Your example with the auth service and the added friction is, in my view, a good illustration of a justification that might sound reasonable but can lead to unnecessary complexity. (Just to be clear, my intent here isn't to judge your decisions - I understand these trade-offs are often nuanced - and that's why again there is no good rule of thumb for this)