Why Segment Went Back to a Monolith • Hacker News Board

Re: Why Segment Went Back to a Monolith

#11

Post by TeeWEE » Wed, Apr 29, 2020, 9:52 AM UTC

It seems like they introduce microservices for the wrong reason. Instead of having a service per team, the focussed on services to solve a technical problem:

"Having a code repository for each service was manageable for a handful of destination workers"

Microservices should be introduced to make teams go faster, not to decouple external api endpoints....

Re: Why Segment Went Back to a Monolith

#12

Post by yehosef » Wed, Apr 29, 2020, 9:53 AM UTC

pulse7 wrote: post #3

TL;DR: "If microservices are implemented incorrectly ... you're drowning in the complexity."

Could it be valid to say that even if microservices are implemented correctly, you're swimming (if not drowning) in complexity? But for some problems and teams, that's better than the alternative.

Re: Why Segment Went Back to a Monolith

#13

Post by silvestrov » Wed, Apr 29, 2020, 9:53 AM UTC

I see it like organization of large companies: you have to split it into divisions, but you can't make every single person their own division.

Don't make the divisions too large, don't make them too small.

The art is to make them the proper size for the particular company.

If you have a small company you don't need divisions. If you have a large one, you need to make divisions as you no longer can speak to every single employee.

Re: Why Segment Went Back to a Monolith

#14

Post by thinkharderdev » Wed, Apr 29, 2020, 9:53 AM UTC

rapsey wrote: post #5

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.

Or they just drowned in their micro service complexity and never made it back.

Exactly, I would wager that very few organizations go from monolith to microservices and back. Getting organization buy-in to do the "big rewrite" is hard. Getting buy-in to do the second "big rewrite" after the first one didn't go well is going to be even harder.

Re: Why Segment Went Back to a Monolith

#15

Post by xxs » Wed, Apr 29, 2020, 9:54 AM UTC

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.

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.

Re: Why Segment Went Back to a Monolith

#16

Post by PopeDotNinja » Wed, Apr 29, 2020, 9:56 AM UTC

james_s_tayler wrote: post #6

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.

Just waiting for O'Reilly to drop a book called "Microservices to Monolith"

A few years ago when the topic of outsourcing/offshoring development was a hot topic for conversation, I bumped into a consultant at a bar. We got to talking about offshoring, and he said he has two folders full of notes, one about offshoring & one about bringing resources in-house. He said he whenever one approach starts to peak, he starts pitching the other one.

Re: Why Segment Went Back to a Monolith

#17

Post by okal » Wed, Apr 29, 2020, 9:58 AM UTC

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

Re: Why Segment Went Back to a Monolith

#18

Post by MatekCopatek » Wed, Apr 29, 2020, 9:58 AM UTC

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.

Re: Why Segment Went Back to a Monolith

#19

Post by nickcw » Wed, Apr 29, 2020, 10:01 AM UTC

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 monolith up and have the same team managing lots of microservices you've made a lot more work for the team without the organisational decoupling which are the real win of microservices.

In my experience it is really difficult to fight Conway's law, you have to work with it and arrange your business accordingly.

Re: Why Segment Went Back to a Monolith

#20

Post by guywhocodes » Wed, Apr 29, 2020, 10:02 AM UTC

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…

Absolutely, you probably can't succeed with microservices without selforganizing teams. You just get more hot potatoes to drop