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).
Microservices Killed Our Startup. Monoliths Would've Saved Us
11–20 of 58 posts
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#12Does 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.)
100%. The writing style put me off too, not sure exactly what about is weird though
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#13please give us $200 ;) but sorry we can't even get the title right!
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#14One 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.
> ...you should be wary of spending too much time on things that customers don’t see
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#15Ironically 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…
> light grey polyfills
Those grey loading placeholders for text are called skeleton loaders BTW, polyfills are libraries used to support newer browser APIs in older browsers and not something you can exactly see on a website (without checking the devtools)
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#16Ironically 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…
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 resour…
> 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-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?
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#17Does 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.)
100%. The writing style put me off too, not sure exactly what about is weird though
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.
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#18Ironically 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…
> light grey polyfills Those grey loading placeholders for text are called skeleton loaders BTW, polyfills are libraries used to support newer browser APIs in older browsers and not something you can exactly see on a website (without checking the devtools)
TIL
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#19Does 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.)
100%. The writing style put me off too, not sure exactly what about is weird though
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?
Re: Microservices Killed Our Startup. Monoliths Would've Saved Us
#20Premature 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.