Why Segment Went Back to a Monolith

Post by dpix » Wed, Apr 29, 2020, 6:20 PM UTC

gregmac wrote: post #221

dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

I've found it most helpful to think in terms of deployments: Each (micro)service effectively gets deployed independently. One implication of this is you need to ensure your APIs are backwards compatible with any other services - even if it's only one service that your team also manages. This also includes databases, if shared by multiple services (which I won't get into, suffice to say congrats, your database schema…

Post by eweise » Wed, Apr 29, 2020, 6:26 PM UTC

dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

Post by afarrell » Wed, Apr 29, 2020, 6:44 PM UTC

eweise wrote: post #233

dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

Post by afarrell » Wed, Apr 29, 2020, 6:49 PM UTC

beh9540 wrote: post #153

kitd wrote: post #31

Earlier quoted context omitted.

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…

> 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. This is so accurate. I've heard engineers give state not needing to communicate, chillingly, as a positive for microservices, like "we won't need to talk to each other if all of us are working on different services". My other favorite is using microservices a…

Post by mikepurvis » Wed, Apr 29, 2020, 6:56 PM UTC

afarrell wrote: post #235

eweise wrote: post #233

Earlier quoted context omitted.

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

I once worked in a monolith that was structured in a way that it could have been easily decoupled. It never was because the codebase was so modular and well-tested that the only time we ever felt the need was when trying to assign ownership to runtime exceptions. https://gocardless.com/blog/getting-started-with-coach/ was the framework.