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

111–120 of 328 posts

Re: Why Segment Went Back to a Monolith

#111

Post by abraxas »

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…

There is nothing wrong with most developers working on and communicating about the entire code base. Having teams work in silos is not a benefit. You're touting as a benefit what is one of microservices' gravest issues - teams stop communicating beyond the surface level of their respective APIs.

Re: Why Segment Went Back to a Monolith

#112

Post by ChrisMarshallNY »

jjgreen wrote: post #91
ChrisMarshallNY wrote: post #74

Earlier quoted context omitted.

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

Please write a blog post called "Horrific OOP chimeras" and post a link on HN ...

Oh...the stories I could tell...

But I have made it a point of personal ethos not to post criticism or polemics, denigrating/excoriating the work of others.

I know that could buy me a lot of clicks (and probably some considerable HN Above The Fold time), but I think we have enough negativity and finger-pointing on the Internet.

If you read my stuff, you won't see much of that. I may, in a rather vague way, allude to something that gives me a frowny-face, but I don't want that to be part of my "personal brand," so to speak.

I do take tremendous personal pride in my work; both coding and writing, and hold myself to a high bar. I may even project that bar onto others (only in some circumstances), but I don't think it's helpful to do so in public.

I find it most gratifying to write a "This is how I do this..." post, as opposed to a "This isn't how you should do it..." post.

Re: Why Segment Went Back to a Monolith

#115

Post by mbrameld »

87zuhjkas wrote: post #109
hedora wrote: post #105

Are there any case studies where microservices went well? From an end user perspective, Netflix runs in “constantly degraded” mod. From an engineering perspective, they track “number of successful stream starts”, instead of percentage of the time 100% of their services are working. That’s a huge red flag. As a researcher, the monitoring and fault-propagation / modeling work they’ve done to get it to stay up at all is…

Well, lets assume N = 999, then N^2 = 998001, so nowhere near the number of atoms in the universe, which is estimated to be about 10^80.

I think the person you're replying to meant 2^N based on the context. They're saying you have to account for every possible combination of services being down.

Re: Why Segment Went Back to a Monolith

#116

Post by mbrameld »

FpUser wrote: post #52
darkerside wrote: post #42

Earlier quoted context omitted.

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.

A distinction without a difference.

Re: Why Segment Went Back to a Monolith

#117

Post by bpyne »

The takeaway is about trade-offs. They made a rational decision to improve fault isolation by dividing the app into smaller building blocks managed separately. After working with it for a while, they realized the higher operational overhead made the architecture a bad choice for them. So they went back to a monolith architecture and tried to do fault isolation within the boundaries of that architecture, which might have made fault isolation not as good as in the micro-services architecture but it was acceptable.

It's incredibly tough to know the full effect of a trade-off on your organization until you start going down that path.

We're early in the process of adopting a micro-service architecture. With only a handful of services so far, I can already see how a team of two is going to spend a lot more time with operational issues and debugging.

Re: Why Segment Went Back to a Monolith

#118

Post by marcosdumay »

abraxas wrote: post #111
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…

There is nothing wrong with most developers working on and communicating about the entire code base. Having teams work in silos is not a benefit. You're touting as a benefit what is one of microservices' gravest issues - teams stop communicating beyond the surface level of their respective APIs.

Have you tried coordinating entire teams to work on a shared codebase?

Honestly, I have never been in an organization so large that this became a necessity (if you solve tens of different problems, that would require almost thousands of developers). But coordinating single developers without an API is hard enough already, I can only assume for teams its nearly impossible.

Re: Why Segment Went Back to a Monolith

#119

Post by sealthedeal »

They went to 50+ services in a few months, were applying the same policies across all services. It sounds like they didn't plan well enough and jumped straight into it, without any good DevOps or infrastructure mindset. It was a disaster waiting to happen. This shouldn't be an article that people read and say "Oh Im never using Microservices". This should be an article people read and say WOW that is exactly the right way to NOT break apart a monolith.

Re: Why Segment Went Back to a Monolith

#120

Post by vorpalhex »

yowlingcat wrote: post #81
andy_ppp wrote: post #43

Earlier quoted context omitted.

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.

I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?

There was a period of time when Service had a different meaning than microservice. A service traditionally may exist across bounded contexts and be almost a mini-monolith whereas a strict microservice should touch very few data models and exist strictly in a bounded context.

Of course real life is messy and plenty of people realized writing small single purpose services was valuable, and plenty of people build giant "microservices" that have nothing to do with the original term and are just badly constructed monoliths.

Post reply on HN