Why Segment Went Back to a Monolith

#1

Post by BerislavLopac » Wed, Apr 29, 2020, 9:25 AM UTC

Why Segment Went Back to a Monolith
infoq.com

Re: Why Segment Went Back to a Monolith

#2

Post by fouc » Wed, Apr 29, 2020, 9:40 AM UTC

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

Re: Why Segment Went Back to a Monolith

#3

Post by pulse7 » Wed, Apr 29, 2020, 9:41 AM UTC

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

Re: Why Segment Went Back to a Monolith

#4

Post by the_mitsuhiko » Wed, Apr 29, 2020, 9:43 AM UTC

pulse7 wrote: post #3

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

I want to see the microservice architecture where you don't drown in complexity.

Re: Why Segment Went Back to a Monolith

#5

Post by rapsey » Wed, Apr 29, 2020, 9:44 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.

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

Re: Why Segment Went Back to a Monolith

#6

Post by james_s_tayler » Wed, Apr 29, 2020, 9:44 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.

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

Re: Why Segment Went Back to a Monolith

#7

Post by pjmlp » Wed, Apr 29, 2020, 9:44 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.

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 gets the money to drive everything back to the monolith.

So goes the money around on plenty of consulting gigs.

Re: Why Segment Went Back to a Monolith

#8

Post by davedx » Wed, Apr 29, 2020, 9:44 AM UTC

My experience of moving to a microservice architecture: the most important consideration with microservices is "who will develop, maintain and operate them?". You can split them down functional lines, architectural lines, whatever you like, but if you don't have teams with definite ownership of each microservice (and that aren't swamped by maintaining lots of them like it seems happened with Segment), it will become impossible. The "operational complexity tax" is a real thing but is manageable if your engineer:service ratio is sensible and considered.

Re: Why Segment Went Back to a Monolith

#9

Post by rvz » Wed, Apr 29, 2020, 9:51 AM UTC

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

Re: Why Segment Went Back to a Monolith

#10

Post by lifeisstillgood » Wed, Apr 29, 2020, 9:51 AM UTC

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 look after the user-login service, you might not do so well.

Like most things, the organisation needs to change to get the best out of the opportunities software offers. Those that don't will face increasing friction and eventually die off.