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

71–80 of 328 posts

Re: Why Segment Went Back to a Monolith

#71

Post by ratww »

tartrate wrote: post #39
pjmlp wrote: post #7

Earlier quoted context omitted.

I bet plenty of them. A team that fails to understand how to write modular code, is just going to write spaghetti RPC calls, while having to deal with all the traditional failures and performance issues of distributed computing. Naturally it is a recipe doomed to fail in the large majority of cases, but it doesn't matter because whoever drove the change is no longer at the company and a new consulting team/new hire g…

> A team that fails to understand how to write modular code, is just going to write spaghetti RPC calls This is interesting. I always assumed we were talking about good developers here. I wonder what's a more likely cause for a failed attempt at microservices. Is it developer incompetence and lack of discipline, or is it environmental factors related to the product and the organization?

IME it is always environmental factors.

When you have 200 developers working on the same product without well defined boundaries it will be a mess with a monolith, and a mess with microservices.

Also arbitrary rules such as "one service per team" or "one service per employee" that force engineers to jerry-rig things that don't belong together. Either allow them to make a new service, make or a new team, or admit that microservices are not single-purpose and are just a blob of multipurpose code. I've seen this way too much.

Also pure organizational inertia working against good engineering practices: sometimes a team will be severely overworked while others are overstaffed. But god forbid there's a temporary reorganization to improve the work of engineers, so people send tasks to other teams, but there's minimal communication between engineers.

Re: Why Segment Went Back to a Monolith

#72

Post by gridlockd »

Microservice-Architecture is one of these trends where the value is unproven, the upfront costs are high and the unknowns are unknown.

There's also a clear conflict of interest with SAAS and Cloud providers benefiting from the perception that microservices are the way to go.

Under these circumstances, letting someone else figure out all the issues is the wise thing to do. Thanks to the authors for doing just that.

Re: Why Segment Went Back to a Monolith

#73

Post by gridlockd »

ChrisMarshallNY wrote: post #29

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…

This phenomenon can be described as "excessive factoring" and it can easily happen under any paradigm.

Perhaps it's more prevalent with OOP programmers, but perhaps it just appears that way because the boilerplate for classes is a bit larger than the boilerplate for functions and structs.

Re: Why Segment Went Back to a Monolith

#74

Post by ChrisMarshallNY »

FpUser wrote: post #34
ChrisMarshallNY wrote: post #29

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

Don't get me wrong. I love OOP, and have been using it since before it was cool. It's been a standard wrench in my toolbox for decades.

In fact, I have been running into folks, these days, that don't understand it, as, apparently, OOP is becoming "uncool."

I've always been a "right tool for the right job" kind of guy. I started off with ML (Machine Language, not Machine Learning). I am quite comfortable, sitting down with a breadboard, and flashing an OS.

But I remember the old days of OOP, where "classic" structured programmers didn't "get" OOP, and designed these horrific chimeras.

I always make it a point to understand my methodology and drivers "to the bone." Just because someone at a conference said it, doesn't mean that I should use it for everything.

Re: Why Segment Went Back to a Monolith

#75

Post by thedevopsguy »

pjc50 wrote: post #67
thedevopsguy wrote: post #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 give…

If the microservices are in a single repo and tested and deployed together then they are arguably no longer microservices but a "distributed monolith"!

I'm referring to having the same testing, deployment,packaging,versioning policies etc being consistently applied across projects within the same repository not deploying, testing and releasing together.

It's the drift and inconsistencies across these concerns across projects that makes deployment and operations less predictable.

Re: Why Segment Went Back to a Monolith

#76

Post by barrkel »

kkapelon wrote: post #46

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

Sharing code or reinventing the wheel repeatedly is inevitable once you have more than one concern by which you can divide services.

For example: let's say you have lots of integrations, and you need to scale compute, and parse and generate common data sent to and from the integrations.

You can either have a monolithic integration service which you scale out on load; or you can have integration-specific services that scale out on load and share your data parsing & generation library. Due to multiple concerns, there's no "best slice".

FWIW, scaling out compute is a stronger argument to me for a service boundary than responsibility segregation. Scaling out requires distribution; scaling up complexity doesn't, though it can help for other reasons, like CI/CD. I prefer FaaS architectural patterns with the freedom to share libraries in different functions (images) to services, especially if long-running state is not needed.

Re: Why Segment Went Back to a Monolith

#77

Post by deltron3030 »

This older "breaking up the monolith" GraphQL talk from Prisma is interesting: https://invidio.us/watch?v=_MmyTahR9ok

Especially if you consider RedwoodJS, a new full stack JS framework that's build on Prisma technology (their stuff is an alternative to Rails Active Record ORM). My takeaway is that they provide a similar monolith like experience by acting as a glue between different services.

Re: Why Segment Went Back to a Monolith

#78

Post by pestaa »

lifeisstillgood wrote: post #10

I have this thing about micro-services/complexity in that it follows Conway's Law - the architecture follows the organisational structure. If you push authority and decision making and responsibility for a service to a (2 pizza) team then guess what, microservices work really well. If you have vast monolithic centralised production operations teams, and no way in hell is their C-Exec going to assign two of them to lo…

2 pizza team?

Well finally I might get my own microservice after all.

Re: Why Segment Went Back to a Monolith

#79

Post by yowlingcat »

strictfp wrote: post #44
nickcw wrote: post #19

I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monol…

Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software compo…

What is your alternative? Tying "the existence of internal software components to people's livelihoods" across the expanse of the entire codebase is the only remotely effective approach I've seen to scaling the SDLC at scale.

Re: Why Segment Went Back to a Monolith

#80

Post by dmix »

FpUser wrote: post #30
nickcw wrote: post #19

I think that the problem here was that they were fighting against Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. I think microservices work well in organizations that are big enough to have a team per microservice. However if you've just split your monol…

So you are saying something in line of: let's increase our development staff X-fold and then we can finally do the same thing that way fewer people doing just fine right now?

Just because monoliths may have diminishing returns at certain team/project scale doesn't mean the scale itself is the problem...
Post reply on HN