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

Why Segment Went Back to a Monolith

infoq.com

Post reply on HN
Print view View original

251–260 of 328 posts

Re: Why Segment Went Back to a Monolith

#251

Post by JamesBarney »

eweise wrote: post #233
dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

Monolith -> microservices : difficult refactoring

Microservices -> monolith : difficult refactoring

Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.

Re: Why Segment Went Back to a Monolith

#252

Post by BerislavLopac »

As it is so often the case, the choice between monolith and microservices is not a binary one; rather, it is a sliding scale between two extremes.

On one end we have a real monolith: a single executable binary, with no external dependencies apart from the OS bindings. This is very rare in practice, and most commonly found in games and probably mobile apps; when it comes to Web-based services, even a traditional idea of single-codebase app usually has a SQL database as an external dependency.

On the other end of the scale there is a complex system consisting of hundreds or even thousands [0] of tiny services that require complex orchestration mechanisms such as a service hub or service mesh.

So each team (in a wide sense: could be a company, organisation, department etc) needs to consider where they fall in the continuum, considering a) which architecture will provide most benefit while b) still being maintainable by the team; both the architecture and the team need to evolve together.

[0] https://qconlondon.com/london2020/presentation/monzo

Re: Why Segment Went Back to a Monolith

#253

Post by dpix »

SquishyPanda23 wrote: post #244
gregmac wrote: post #221

Earlier quoted context omitted.

I've found it most helpful to think in terms of deployments: Each (micro)service effectively gets deployed independently. One implication of this is you need to ensure your APIs are backwards compatible with any other services - even if it's only one service that your team also manages. This also includes databases, if shared by multiple services (which I won't get into, suffice to say congrats, your database schema…

> this means you're effectively building a monolith with a microservice architecture. Is that really what you want? I actually kinda do want that, although maybe it's a niche thing. It would be nice to be able to deploy a monolith that's already cut at seams where there's an obvious API boundary. At one extreme, you could imagine a single binary where processes communicate via RPC. What that would give you is an easy…

This is actually a similar approach to how next.js deployed to vercel (previously zeit) works by default. Each page or api endpoint is served by an individual lambda function so they can scale up or down independently

https://nextjs.org/docs/deployment#optimized-for-nextjs

Re: Why Segment Went Back to a Monolith

#254

Post by eweise »

JamesBarney wrote: post #251
eweise wrote: post #233

Earlier quoted context omitted.

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

Monolith -> microservices : difficult refactoring Microservices -> monolith : difficult refactoring Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.

"Monolith -> microservices : difficult refactoring" I guess my point is that it doesn't have to be complicated if you architect the monolith carefully. That usually doesn't happen though because frameworks don't necessarily promote the practice and projects are short sighted.

Re: Why Segment Went Back to a Monolith

#255

Post by JamesBarney »

eweise wrote: post #254
JamesBarney wrote: post #251

Earlier quoted context omitted.

Monolith -> microservices : difficult refactoring Microservices -> monolith : difficult refactoring Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.

"Monolith -> microservices : difficult refactoring" I guess my point is that it doesn't have to be complicated if you architect the monolith carefully. That usually doesn't happen though because frameworks don't necessarily promote the practice and projects are short sighted.

It's also really hard. Trying to determine how to split up any code base into logical divisions such that you when adding the next 5 years of functionality you'll have the fewest number of cross division processes is hard.

This is why Martin Fowler recommends starting with a monolith and refactoring into microservices unless you have extensive experience building out very similar applications in the same domain.

Re: Why Segment Went Back to a Monolith

#256

Post by pjmlp »

axegon_ wrote: post #198
BareNakedCoder wrote: post #103

Earlier quoted context omitted.

Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for e…

Oh, all of those were heavily modularized to begin with. But that wasn't enough to keep them manageable. So at the end what we did is figure out which are the core components between the different modules, isolate what they did and put them aside in a smaller microservices, which were easier to track, maintain and monitor. What was once the monolith is now arguably just an interface/API for all the heavy lifting whic…

The fun is that we have seen this so many times.

Sun RPC, CORBA, DCE, DCOM, XML-RPC, SOAP, REST, gRPC,....

Re: Why Segment Went Back to a Monolith

#259

Post by throwaway894345 »

cytzol wrote: post #242
dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

This, this, this! It's been said elsewhere in these comments, but the term "micro"-services really do them a disservice, like it's expected that you need to break your application up into little pieces, to eliminate complexity. But many applications are inherently complex, and splitting them up isn't going to get you anywhere. I've been trying to advocate for a "solar system model of services", where you have a big c…

Another aspect no one seems to talk about is whether your deployment is monolithic or fragmented. It seems like a lot of the pain of managing microservices comes from designing a coherent CI/CD pipeline, how to share libraries between various microservices, etc. If you have a monorepo, good build tooling, and a good infrastructure as code tool, I think much of that pain goes away, but none of those things are easy and the precise selection and combination of tools depends a lot on your organization (I wouldn't recommend Bazel or Nix--build tools--to a small or medium-sized organization, for example).

Re: Why Segment Went Back to a Monolith

#260

Post by ryanthedev »

Poor design. Sharing code between microsercices is always a design smell.

You are just building services on top of another monolith...

Sounds like you needed to abstract the work being send to the worker, instead of abstracting the worker around the work.

Meaning don't have many workers for one payload type. Abstract the payload and have a single worker...

That's why most systems become complex and spaghetti. Poor abstraction, so you use shared code to fix it...

Post reply on HN