6 ms·

Microservices Killed Our Startup. Monoliths Would've Saved Us

51 points by leptoniscool 9mo ago

dabinat 9mo ago
One thing I’ve learned is that you should be wary of spending too much time on things that customers don’t see. Customers don’t care about backend engineering unless it results in benefits they can actually see, and if you spend too long on invisible features they’ll think your platform is stagnant and move somewhere else.
- CharlieDigital 9mo ago
  > ...you should be wary of spending too much time on things that customers don’t see I don't think this is entirely true because there are some things that will help you ship faster like good architecture and a system design that is as simple as possible. These are worth investing, despite their obscurity to the end user, because doing it well can result in a faster pipeline and more stability.
  - dedge 9mo ago
    I would say this is fine, provided it’s in service of releasing value. It’s when the invisible stuff becomes a chore, and blocks or slows down releasing value, such as worrying about micro services.
analogpixel 9mo ago
this goes to show that one person can make a difference, the lead architect all by himself was able to destroy a company and moral.
jiggawatts 9mo ago
Ironically posted on Medium, which showed me the text, then blanked the whole screen to replace the text with light grey polyfills, and then showed me the same text again... several seconds later. That's because Medium is a bunch of APIs and (micro) services, not a monolith like it should be. Heck, it could be plain static HTML because it's just text for crying out loud! Instead, it uses a GraphQL query through JSON to obtain the text of the article... that it already sent me in HTML. Total page weight of 17 MB, of which 6.7 MB is some sort of non-media ("text") document or script. This is user-hostile architecture astronaut madness, and is so totally normal in the modern internet that nobody even bats and eye when text takes appreciable amounts of time to render on a 6 GHz multi-core computer with 1 Gbps fibre Internet connectivity. Your customers hate this. Your architects love it because it keeps them employed.
- ameliaquining 9mo ago
  Monoliths vs. microservices has nothing to do with server-side rendering vs. GraphQL. Architecturally monolithic Web apps use GraphQL all the time. I'm not sure why Medium does the weird blanking thing but my guess is that it's because it's deciding whether to let you read the article or instead put up a paywall. There are a lot of SPA sites out there, many of which aren't particularly economical with frontend resources, and they generally don't do that unless they're trying to enforce some kind of paywall or similar.
  - simfree 9mo ago
    Monoliths generally server side render. Server side rendering is fast, consistent and performant, the state of the client won't get into wonky territory since they are a button click away from getting current, known good state from the server.
    - jdlshore 9mo ago
      That’s not a microservice vs monolith thing. That’s a client-side single-page app vs server-side rendering thing. Although, granted, I more often see microservice architectures with single-page apps than with server-side rendering.
  - jiggawatts 9mo ago
    > Architecturally monolithic Web apps use GraphQL all the time. Sure, but a significant motivation for using GraphQL is to stitch together a bunch of microservices into a cohesive API for the front end. My comment about Medium using microservices was just an informed guess, but a good one. They started migrating from a monolith to microservices back in 2018: https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f https://medium.engineering/microservice-architecture-at-medi... Is it a coincidence that that's around the time frame that I noticed the Medium web site becoming slower than it used to be?
    - ameliaquining 9mo ago
ameliaquining 9mo ago
Does this story seem kinda…fake…to anyone else? Like, obviously companies do sometimes make decisions this stupid, but the way this is written seems a little too carefully optimized to make for a morality play of the kind HN enjoys. (And there's a potential motive, since there's a whole bunch of links to paid books and such, somewhat clumsily tied to the main narrative.)
- temp_praneshp 9mo ago
  100%. The writing style put me off too, not sure exactly what about is weird though
  - tills13 9mo ago
    Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.
    - Proofread0592 9mo ago
      Agree on it being AI, but what really screamed "AI slop" to me was the emojis. I don't know any tech bloggers who use emojis, but everything that ChatGPT or Gemini generates always has too many emojis.
  - yongjik 9mo ago
    Also, it starts with > Microservices didn’t scale our startup. They killed it. ...and then at the end, > We lost 6 months. We lost some good engineers. We burned through money we didn’t have. But we survived. ...So did microservices kill the startup or not?
- altmanaltman 9mo ago
  > “It’s not complex if you do it right. Netflix — “ > “WE’RE NOT NETFLIX!” I finally snapped. “Netflix has 500 engineers. We have 4. Netflix has dedicated DevOps teams. We have one guy. Netflix has millions of users. We have 50,000.” Then > Lesson 5: The Monolith Isn’t Your Enemy > A well-structured monolith can: > Scale to millions of users (Shopify, GitHub, Stack Overflow prove this) Because Shopify, Github and Stack Overflow have 4 engineers each as well. It kind of seems real because it reads like the it's written by the kind of person that would make high level arch decisions without even understanding what the f they are doing.
blackoil 9mo ago
Microservices solve people problem not technical. Till ~20 backend devs no point in moving to it. Monoliths are better in terms of performance, reliability and dev speed.
- hinkley 9mo ago
  You can’t solve social problems with technology. Microservices solve a logistical problem. Rob wants to push code every two days. Steve wants to push every three. Thom deals with business who wants to release at whim and preferably within a few hours. Their commissions and bonuses are not reduced by how much chaos they case the engineering team. It’s an open feedback loop. As you add more employees they start tripping over each other on the differences between trunk and deployed. Thats when splitting into multiple services starts to look attractive. Unfortunately they create their own weather and so if you can use process to delay this point you’re gonna be better off. Everyone eventually merges code they aren’t 100% sure about. Some people do it all the time. However microservices magnify this because it’s difficult to test changes that cross service boundaries. You think you have it right but unless you can fit the entire system onto one machine, you can’t know. And distributed systems usually don’t concern themselves with whether the whole thing will fit onto a dev laptop. So then you have code in preprod you are pretty sure will work but aren’t completely sure. Stack enough “pretty sure”s over time and as team sizes grow and you’re gonna have incidents on the regular. Separate deployment reduces the blast radius, but doesn’t eliminate it. Feature toggles reduce it more than an order of magnitude, but that still takes you from problems every week to a couple a year. Which in high SLA environments still makes people cranky.
another_twist 9mo ago
I am pretty sure it was a lack of demand that killed the startup. Either of these are valid problems and quite easy to deploy and work with.
- hinkley 9mo ago
  One of the tricks of the startup dance is attaching improvement to revenue. Any work that’s done to support new customers will get approved. And work that looks like a loss leader, such as to retain existing customers, they may lean on the business or support people to paper over.
nodesocket 9mo ago
Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup which is absurd (unless your startup is high frequency trading or something).
- hinkley 9mo ago
  There’s a Venn diagram of different delusions and they overlap a lot. You don’t have a market fit and you’re running your dev team like a larger company? What are the odds? Pretty high actually.
hdaz0017 9mo ago
please give us $200 ;) but sorry we can't even get the title right!
rambojohnson 9mo ago
Premature distribution killed the startup, not microservices. You split the system before the boundaries were real, paid the tax in latency and coordination, and skipped the hard parts that make it viable: event-driven boundaries, local read models, and boring failure handling and comprehensive logging. Start with a modular monolith, earn your boundaries, then extract.
- hinkley 9mo ago
  Ask your coworkers how many of them got any formal training in distributed systems in college. You’re going to find out it’s not many. So far I haven’t found anyone who didn’t go to Berkeley or UIUC. WTF is going on with universities?
condwanaland 9mo ago
The mistake here is having an architect who is not shipping product. Architects who's job it is to define 'rules' and 'patterns' without actually impending anything are almost always a bad idea. Just focus on shipping. Have at least one experienced engineer who can guide the development but don't give those decisions over to some 'architect' who is not even going to write 10 lines of code in your codebase
- salomonk_mur 9mo ago
  Having members of the tech team who don't write code in some way or another is bad practice in general
- LucaMo 9mo ago
  > We had 4 backend developers and a DevOps guy who was already stretched thin. The mistake here was having an architect full stop. The team is too small, a good tech lead can manage to plan a service with 50k MAU (and way beyond) without an architect. The problem with some companies that get millions in seed funding is that they need to spend the money and they do so by adding roles that shouldn't exist at that stage.
  - sshine 9mo ago
    > and a DevOps guy who was already stretched thin Another favourite antipattern: making devops a bottleneck. Don’t over-engineer production, don’t buy abstraction you can’t afford, and educate your colleagues to lower the bus factor. Dedicated devops that aren’t co-founders are notorious for cv optimizing: working with cool, but time-consuming stuff they don’t yet master, at the cost of delivery-time risk.
- hinkley 9mo ago
  I vastly prefer architecture as a responsibility shared by all the staff+ or lead devs than as a role. But that starts to fall down too any time too many people are talking about software they aren’t responsible for deploying or fixing.
Olumde 9mo ago
> But we survived > And ironically? Now that we’re back on a monolith and shipping fast again, we’ve started growing again. Customers are happier. The team is happier. So Microservices did not kill your startup? And why did you stop instances of your monolith before the Microservices version was mature and ready???
brimstedt 9mo ago
I do not agree fully with this article, but it does give food for thought and have some valid points: - don't blindly jump into a new architecture because it's cool - choose wisely the size of your services. It's not binary, and often it makes sense to group responsibilities into larger services. - microservices have some benefits, moduliths (though not mentioned in the article) and monoliths have theirs. They all also have their set of disadvantages. - etc But anyway, the key lesson (which does not seem like a conclusion the author made) is: Don't put a halt to your product/business development to do technician only work. I.e if you can't make a technical change while still shipping customer value, that change may not be worth it. There are of course exceptions, but in general you can manage technical debt, archtectural work, bug fixing, performance improvements, dx improvements, etc, while still shipping new features.
shraddha92 9mo ago
what did i just read
aee 9mo ago
"No fluff" is the GPT5 em dash
deleted 9mo ago
[deleted]
amelius 9mo ago
That building in the right half of the image doesn't look like a monolith to me.
deleted 9mo ago
[deleted]

51 points by leptoniscool 9mo ago

One thing I’ve learned is that you should be wary of spending too much time on things that customers don’t see. Customers don’t care about backend engineering unless it results in benefits they can actually see, and if you spend too long on invisible features they’ll think your platform is stagnant and move somewhere else.

CharlieDigital 9mo ago
> ...you should be wary of spending too much time on things that customers don’t see I don't think this is entirely true because there are some things that will help you ship faster like good architecture and a system design that is as simple as possible. These are worth investing, despite their obscurity to the end user, because doing it well can result in a faster pipeline and more stability.
- dedge 9mo ago
  I would say this is fine, provided it’s in service of releasing value. It’s when the invisible stuff becomes a chore, and blocks or slows down releasing value, such as worrying about micro services.

analogpixel 9mo ago

this goes to show that one person can make a difference, the lead architect all by himself was able to destroy a company and moral.

jiggawatts 9mo ago

Ironically posted on Medium, which showed me the text, then blanked the whole screen to replace the text with light grey polyfills, and then showed me the same text again... several seconds later. That's because Medium is a bunch of APIs and (micro) services, not a monolith like it should be. Heck, it could be plain static HTML because it's just text for crying out loud! Instead, it uses a GraphQL query through JSON to obtain the text of the article... that it already sent me in HTML. Total page weight of 17 MB, of which 6.7 MB is some sort of non-media ("text") document or script. This is user-hostile architecture astronaut madness, and is so totally normal in the modern internet that nobody even bats and eye when text takes appreciable amounts of time to render on a 6 GHz multi-core computer with 1 Gbps fibre Internet connectivity. Your customers hate this. Your architects love it because it keeps them employed.

ameliaquining 9mo ago
Monoliths vs. microservices has nothing to do with server-side rendering vs. GraphQL. Architecturally monolithic Web apps use GraphQL all the time. I'm not sure why Medium does the weird blanking thing but my guess is that it's because it's deciding whether to let you read the article or instead put up a paywall. There are a lot of SPA sites out there, many of which aren't particularly economical with frontend resources, and they generally don't do that unless they're trying to enforce some kind of paywall or similar.
- simfree 9mo ago
  Monoliths generally server side render. Server side rendering is fast, consistent and performant, the state of the client won't get into wonky territory since they are a button click away from getting current, known good state from the server.
  - jdlshore 9mo ago
    That’s not a microservice vs monolith thing. That’s a client-side single-page app vs server-side rendering thing. Although, granted, I more often see microservice architectures with single-page apps than with server-side rendering.
- jiggawatts 9mo ago
  > Architecturally monolithic Web apps use GraphQL all the time. Sure, but a significant motivation for using GraphQL is to stitch together a bunch of microservices into a cohesive API for the front end. My comment about Medium using microservices was just an informed guess, but a good one. They started migrating from a monolith to microservices back in 2018: https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f https://medium.engineering/microservice-architecture-at-medi... Is it a coincidence that that's around the time frame that I noticed the Medium web site becoming slower than it used to be?
  - ameliaquining 9mo ago

ameliaquining 9mo ago

Does this story seem kinda…fake…to anyone else? Like, obviously companies do sometimes make decisions this stupid, but the way this is written seems a little too carefully optimized to make for a morality play of the kind HN enjoys. (And there's a potential motive, since there's a whole bunch of links to paid books and such, somewhat clumsily tied to the main narrative.)

temp_praneshp 9mo ago
100%. The writing style put me off too, not sure exactly what about is weird though
- tills13 9mo ago
  Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.
  - Proofread0592 9mo ago
    Agree on it being AI, but what really screamed "AI slop" to me was the emojis. I don't know any tech bloggers who use emojis, but everything that ChatGPT or Gemini generates always has too many emojis.
- yongjik 9mo ago
  Also, it starts with > Microservices didn’t scale our startup. They killed it. ...and then at the end, > We lost 6 months. We lost some good engineers. We burned through money we didn’t have. But we survived. ...So did microservices kill the startup or not?
altmanaltman 9mo ago
> “It’s not complex if you do it right. Netflix — “ > “WE’RE NOT NETFLIX!” I finally snapped. “Netflix has 500 engineers. We have 4. Netflix has dedicated DevOps teams. We have one guy. Netflix has millions of users. We have 50,000.” Then > Lesson 5: The Monolith Isn’t Your Enemy > A well-structured monolith can: > Scale to millions of users (Shopify, GitHub, Stack Overflow prove this) Because Shopify, Github and Stack Overflow have 4 engineers each as well. It kind of seems real because it reads like the it's written by the kind of person that would make high level arch decisions without even understanding what the f they are doing.

blackoil 9mo ago

Microservices solve people problem not technical. Till ~20 backend devs no point in moving to it. Monoliths are better in terms of performance, reliability and dev speed.

hinkley 9mo ago
You can’t solve social problems with technology. Microservices solve a logistical problem. Rob wants to push code every two days. Steve wants to push every three. Thom deals with business who wants to release at whim and preferably within a few hours. Their commissions and bonuses are not reduced by how much chaos they case the engineering team. It’s an open feedback loop. As you add more employees they start tripping over each other on the differences between trunk and deployed. Thats when splitting into multiple services starts to look attractive. Unfortunately they create their own weather and so if you can use process to delay this point you’re gonna be better off. Everyone eventually merges code they aren’t 100% sure about. Some people do it all the time. However microservices magnify this because it’s difficult to test changes that cross service boundaries. You think you have it right but unless you can fit the entire system onto one machine, you can’t know. And distributed systems usually don’t concern themselves with whether the whole thing will fit onto a dev laptop. So then you have code in preprod you are pretty sure will work but aren’t completely sure. Stack enough “pretty sure”s over time and as team sizes grow and you’re gonna have incidents on the regular. Separate deployment reduces the blast radius, but doesn’t eliminate it. Feature toggles reduce it more than an order of magnitude, but that still takes you from problems every week to a couple a year. Which in high SLA environments still makes people cranky.

another_twist 9mo ago

I am pretty sure it was a lack of demand that killed the startup. Either of these are valid problems and quite easy to deploy and work with.

hinkley 9mo ago
One of the tricks of the startup dance is attaching improvement to revenue. Any work that’s done to support new customers will get approved. And work that looks like a loss leader, such as to retain existing customers, they may lean on the business or support people to paper over.

nodesocket 9mo ago

Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup which is absurd (unless your startup is high frequency trading or something).

hinkley 9mo ago
There’s a Venn diagram of different delusions and they overlap a lot. You don’t have a market fit and you’re running your dev team like a larger company? What are the odds? Pretty high actually.

hdaz0017 9mo ago

please give us $200 ;) but sorry we can't even get the title right!

rambojohnson 9mo ago

Premature distribution killed the startup, not microservices. You split the system before the boundaries were real, paid the tax in latency and coordination, and skipped the hard parts that make it viable: event-driven boundaries, local read models, and boring failure handling and comprehensive logging. Start with a modular monolith, earn your boundaries, then extract.

hinkley 9mo ago
Ask your coworkers how many of them got any formal training in distributed systems in college. You’re going to find out it’s not many. So far I haven’t found anyone who didn’t go to Berkeley or UIUC. WTF is going on with universities?

condwanaland 9mo ago

The mistake here is having an architect who is not shipping product. Architects who's job it is to define 'rules' and 'patterns' without actually impending anything are almost always a bad idea. Just focus on shipping. Have at least one experienced engineer who can guide the development but don't give those decisions over to some 'architect' who is not even going to write 10 lines of code in your codebase

salomonk_mur 9mo ago
Having members of the tech team who don't write code in some way or another is bad practice in general
LucaMo 9mo ago
> We had 4 backend developers and a DevOps guy who was already stretched thin. The mistake here was having an architect full stop. The team is too small, a good tech lead can manage to plan a service with 50k MAU (and way beyond) without an architect. The problem with some companies that get millions in seed funding is that they need to spend the money and they do so by adding roles that shouldn't exist at that stage.
- sshine 9mo ago
  > and a DevOps guy who was already stretched thin Another favourite antipattern: making devops a bottleneck. Don’t over-engineer production, don’t buy abstraction you can’t afford, and educate your colleagues to lower the bus factor. Dedicated devops that aren’t co-founders are notorious for cv optimizing: working with cool, but time-consuming stuff they don’t yet master, at the cost of delivery-time risk.
hinkley 9mo ago
I vastly prefer architecture as a responsibility shared by all the staff+ or lead devs than as a role. But that starts to fall down too any time too many people are talking about software they aren’t responsible for deploying or fixing.

Olumde 9mo ago

> But we survived > And ironically? Now that we’re back on a monolith and shipping fast again, we’ve started growing again. Customers are happier. The team is happier. So Microservices did not kill your startup? And why did you stop instances of your monolith before the Microservices version was mature and ready???

brimstedt 9mo ago

I do not agree fully with this article, but it does give food for thought and have some valid points: - don't blindly jump into a new architecture because it's cool - choose wisely the size of your services. It's not binary, and often it makes sense to group responsibilities into larger services. - microservices have some benefits, moduliths (though not mentioned in the article) and monoliths have theirs. They all also have their set of disadvantages. - etc But anyway, the key lesson (which does not seem like a conclusion the author made) is: Don't put a halt to your product/business development to do technician only work. I.e if you can't make a technical change while still shipping customer value, that change may not be worth it. There are of course exceptions, but in general you can manage technical debt, archtectural work, bug fixing, performance improvements, dx improvements, etc, while still shipping new features.

shraddha92 9mo ago

what did i just read

aee 9mo ago

"No fluff" is the GPT5 em dash

deleted 9mo ago

[deleted]

amelius 9mo ago

That building in the right half of the image doesn't look like a monolith to me.

deleted 9mo ago

[deleted]