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

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

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.

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

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.

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.

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.

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.

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.

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

what did i just read

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

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.