Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices Killed Our Startup. Monoliths Would've Saved Us

medium.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#21

Post by altmanaltman »

ameliaquining wrote: post #6

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

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

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#22

Post by dedge »

CharlieDigital wrote: post #14
dabinat wrote: post #2

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.

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

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.

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#23

Post by ameliaquining »

jiggawatts wrote: post #16
ameliaquining wrote: post #5

Earlier quoted context omitted.

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

I do in fact think it's pretty unlikely that any performance degradation you observed was directly caused by microservices, as opposed to changes that directly affected the frontend.

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#24

Post by condwanaland »

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

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#25

Post by Olumde »

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

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#26

Post by jiggawatts »

ameliaquining wrote: post #23
jiggawatts wrote: post #16

Earlier quoted context omitted.

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

I do in fact think it's pretty unlikely that any performance degradation you observed was directly caused by microservices, as opposed to changes that directly affected the frontend.

I politely disagree. Microservices are the large government bureaucracy of software architecture with similar efficiency outcomes for similar reasons.

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#27

Post by jdlshore »

simfree wrote: post #9
ameliaquining wrote: post #5

Earlier quoted context omitted.

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…

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.

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.

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#28

Post by salomonk_mur »

condwanaland wrote: post #24

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

Having members of the tech team who don't write code in some way or another is bad practice in general

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#29

Post by LucaMo »

condwanaland wrote: post #24

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

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

Re: Microservices Killed Our Startup. Monoliths Would've Saved Us

#30

Post by brimstedt »

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.

Post reply on HN