Live data from Hacker News

Why Segment Went Back to a Monolith

infoq.com

51–60 of 328 posts

Re: Why Segment Went Back to a Monolith

#51

>Shared libraries were created to provide behavior that was similar for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

That sounds like an overly broad generalisation.

They might well all share the same basic framework code, of course. Why not share code for recurring concerns like auth?

Re: Why Segment Went Back to a Monolith

#52
post #34

Earlier quoted context omitted.

"Turning everything into an object can make a small program into a big program, so it’s maybe not such a good idea for small-scale stuff." In my experience OOP actually makes programs smaller. Assuming of course they have good programmers/architects and the program itself is larger than "Hello world".

In my experience, OOP makes programs different. Might be bigger or smaller, but the real difference is complexity. Not in that it makes things more or less complex, but in that it moves the complexity around to different places. Those places being complex (and others simpler) might make it easier or harder to maintain your program, which is what makes these decisions highly dependent on your particular systems and te…

OOP does not "move" complexity. People do.

Re: Why Segment Went Back to a Monolith

#53
Without knowing more about their architecture it is difficult to comment beyond the conclusion Alexandra Noonan came to, stated at the beginning of the article. It looks like to me that the architectural assumptions were changing too quickly due to the demands of a fast growing business. Having all their code in a single repository means that they can control dependencies, versioning and deployment centrally, it gives them central control of their software development lifecycle. I can't see how they could not have had the same benefits of the monolith if their microservices existed in a single repo to begin with and had the appropriate tooling to enforce testing, versioning, deployment across all services in the repo. I guess this is the whole monorepo debate and tooling.

This article for me is more about the complexity of managing a large team across different sites where the architecture needs to change rapidly when modularity is absent. They did get a measurable benefit around performance, though. I wonder if Alexandra will comment on the challenges of running a team in an environment of this complexity?

Re: Why Segment Went Back to a Monolith

#54
post #34

This sounds like the old arguments about OOP. Turning everything into an object can make a small program into a big program, so it’s maybe not such a good idea for small-scale stuff. http://www.solipsys.co.uk/new/TheParableOfTheToaster.html However, in my experience, OOP made it possible to do really big stuff. It’s all about not having a “one-size-fits-all” approach. I don’t think it’s just about scaling architectur…

"Turning everything into an object can make a small program into a big program, so it’s maybe not such a good idea for small-scale stuff." In my experience OOP actually makes programs smaller. Assuming of course they have good programmers/architects and the program itself is larger than "Hello world".

Sounds pretty unlikely. You don't need OOP to have fairly DRY and well organized code that is nice and small.

Re: Why Segment Went Back to a Monolith

#55
post #15
post #2

How many places have gone from monolith to microservices and back to monolith? I'm sure there's been quite a few.

Truth be told, no one stops you from having modular 'monolith'. It feels the name was invented just to sell books and conference tickets (and yummy consulting fees). There is no substitute for a good model and responsibility separation, (micro)services or otherwise.

I agree.

Writer Michael Feathers has an article where he suggests that Microservices are a replacement to encapsulation, all we have to do it use encapsulation well.

https://michaelfeathers.silvrback.com/microservices-and-the-...

Re: Why Segment Went Back to a Monolith

#56

>Shared libraries were created to provide behavior that was similar for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

Reinventing all parts for every microservice sounds wasteful to me. Especially if they handle the same data and/or use the similar business logic.

Re: Why Segment Went Back to a Monolith

#57

>Shared libraries were created to provide behavior that was similar for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

That sounds like an overly broad generalisation. They might well all share the same basic framework code, of course. Why not share code for recurring concerns like auth?

Idea is that you have a service that authorizes transactions

Re: Why Segment Went Back to a Monolith

#58
> Also, a proper solution for true fault isolation would have been one microservice per queue per customer, but that would have required over 10,000 microservices.

I'm a bit confused, they seem to imply that they need a microservice per costumer/destination, but you generically have one instance (aka process) per costumer not an entire separate codebase. The article seem to use the same term for two different concepts. Or i am missing something?

Re: Why Segment Went Back to a Monolith

#59

> Also, a proper solution for true fault isolation would have been one microservice per queue per customer, but that would have required over 10,000 microservices. I'm a bit confused, they seem to imply that they need a microservice per costumer/destination, but you generically have one instance (aka process) per costumer not an entire separate codebase. The article seem to use the same term for two different concept…

Sounds like a job for Erlang

Re: Why Segment Went Back to a Monolith

#60

>Shared libraries were created to provide behavior that was similar for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

That sounds like an overly broad generalisation. They might well all share the same basic framework code, of course. Why not share code for recurring concerns like auth?

Because if you share something (like auth for example), you should have microservice for that. The question is not about duplicate code, but about duplicate libraries that handle the same thing. Decoupling the auth process into separate microservice removes the bottleneck.
Post reply on HN