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

31–40 of 328 posts

Re: Why Segment Went Back to a Monolith

#31

Post by kitd »

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…

As with a lot of things, it comes down to communication. Between teams, and between the services they write. Which is just another expression of Conway's Law.

IIRC Fred Brooks pointed out that the # of bugs in a system correlates closely with the # of lines of communication within and between the teams. Joshua Bloch recommends in "Effective Java" that, if possible, 3 potential clients should participate in the design of an API, for the same reason. So a well-designed interface or OpenAPI spec is worth its weight in gold.

Ofc, "microservices" here means separate running instances available on a network. But monoliths can be "service"-oriented as well. OSGi was good for this in Java, but any system able to load shared objects or plugins dynamically can follow the same pattern. And the benefit is that, if your app hits the jackpot and needs to scale outwards, the service interfaces, ie the lines of communication, are already well-defined.

So, service-oriented monolith first, then microservices if needed.

Re: Why Segment Went Back to a Monolith

#32

Post by vegannet »

MatekCopatek wrote: post #18

I always felt like the biggest benefit of microservices (for the average company that just jumped on the band wagon) was simply the fact it forced them to break things up. Yes, they could achieve the same result with none of the overhead on a monolith, but it would take... discipline. It's much easier to just enforce a hard external constraint. Realizing this and circling back is still a useful life lesson.

If your code is bad in a monolith, it’ll be bad with Microservices. If you can’t build a good monolith, you can’t build a good Microservices architecture — because it introduces even more complexity and requires even more consideration.

Discipline is fundamental to good software engineering: you can’t force it with Microservices.

Re: Why Segment Went Back to a Monolith

#33

Post by swah »

pjmlp wrote: post #7
fouc wrote: post #2

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

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…

I feel this at my current work - and the worst thing is that they have some really smart folks which can understand the whole thing and make it work for a few years more.

Re: Why Segment Went Back to a Monolith

#34

Post by FpUser »

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

Re: Why Segment Went Back to a Monolith

#35

Post by thinkharderdev »

bencollier49 wrote: post #27
me551ah wrote: post #23

I'm just curious if there is a middle ground somewhere? On one end you have a giant monolith. All services rolled into one which includes your API, Middle ware and then Database. One the other end you have microservices which bundle services into individual distinct units with each service being responsible for its API, middleware and database. Are there any preexisting patterns which seek to combine these two and co…

> which includes your API, Middle ware and then Database Layered microservices are an antipattern. In most cases, functionality is best divided by domain.

This is why I struggle with microservice architectures. It seems like there is a basic contradiction. On the one hand, it's vitally important that the microservices are carved into the correct modules otherwise you get a nightmare of operational complexity where simple functional changes require coordinated changes across multiple services. But defining the correct way modules requires a bird's-eye architectural view of the entire system, which seems contradictory to idea of self-organizing, independent teams. I can see how it works when the right way to divide things up is obvious or when you are dealing with IaaS or PaaS services, but in a complex business domain who decides how to carve things up?

Re: Why Segment Went Back to a Monolith

#36

Post by he0001 »

camillovisini wrote: post #26
he0001 wrote: post #24

Earlier quoted context omitted.

But does conway’s law require microservices? It doesn’t say anything about microservices.

> Melvin Conway, who introduced the idea in 1967.

Yes, I don’t think that you need microservices to be able to tackle Conway's law. At least it doesn’t have anything to do with each other.

You could still do microservices and still fail to deal with Conway’s law.

Re: Why Segment Went Back to a Monolith

#37

Post by Tomis02 »

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?

With microservices there's no way around it, as there's additional overhead when splitting a for loop between multiple services. Won't stop people from jumping on the bandwagon though.

Re: Why Segment Went Back to a Monolith

#38

Post by sweeneyrod »

okal wrote: post #17
rvz wrote: post #9

Still waiting for Monzo's following blogpost on cutting down their outrageous number of 1500 microservices [0] and moving some back into monoliths. I'm not sure if I would be too excited over the number of microservices if there is a degree of complexity involved here. That is just too many here. [0] https://monzo.com/blog/we-built-network-isolation-for-1-500-...

Why do you think/feel that there are "too many"? What's the threshold for an acceptable number of microservices? (Not asking this to be confrontational. Just curious, because it's a sentiment I've seen before, without the reasoning behind it being articulated.)

One per developer seems like a fairly loose upper bound.

Re: Why Segment Went Back to a Monolith

#39

Post by tartrate »

pjmlp wrote: post #7
fouc wrote: post #2

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

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?

Re: Why Segment Went Back to a Monolith

#40

Post by detaro »

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?

They're clearly not saying that. If your team is too large to effectively work on a monolith, splitting it up can make sense, but you also need to split the team into smaller groups responsible for different parts. And if you don't end up with teams responsible for individual services, you likely split to small. And quite possibly, your staff isn't large enough to warrant it.
Post reply on HN