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

21–30 of 328 posts

Re: Why Segment Went Back to a Monolith

#21

Post by guywhocodes »

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.

I think this, approaching DDD, is the most common reason engineers push for it these days.

Re: Why Segment Went Back to a Monolith

#22

Post by jbverschoor »

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…

Well.. just consider every "microservice" a separate company, exposing its own product/service. Also think about all the overhead that comes with it - product managers, finance, recruitment etc.

Re: Why Segment Went Back to a Monolith

#23

Post by me551ah »

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 come up with an architecture which is midway between those two. A few months ago I had read an article about Data Oriented Architecture on HN which comes close though I'm wondering if there are others.

Re: Why Segment Went Back to a Monolith

#24

Post by he0001 »

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…

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

Re: Why Segment Went Back to a Monolith

#25

Post by crispyporkbites »

jbverschoor wrote: post #22
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…

Well.. just consider every "microservice" a separate company, exposing its own product/service. Also think about all the overhead that comes with it - product managers, finance, recruitment etc.

If all the services that the microservice needs are also services behind an API, what's the overhead? Something like:

hire("developer", 10, "10x).addToPayroll().office("openplan", "wfh").enforceHRPolicies()

Is all you need

The best thing about this is that you can keep everything in change control and just rollback whenever you need to, or spin up new companies at will.

Re: Why Segment Went Back to a Monolith

#26

Post by camillovisini »

he0001 wrote: post #24
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…

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

> Melvin Conway, who introduced the idea in 1967.

Re: Why Segment Went Back to a Monolith

#27

Post by bencollier49 »

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.

Re: Why Segment Went Back to a Monolith

#28

Post by pknopf »

guywhocodes wrote: post #21
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.

I think this, approaching DDD, is the most common reason engineers push for it these days.

It isn't worth the added friction though.

And if you happen to leak concerns in your services (in a monolith), it's really easy to adjust, as opposed to having to coordinate the deployment of 5+ services.

And even then, a distributed monolith is still a risk.

Micro-services add cement to your project. Be prepared to keep boundaries you write for a long time.

Re: Why Segment Went Back to a Monolith

#29

Post by ChrisMarshallNY »

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 architectures; it’s about changing architectures to match scale.

It’s difficult as hell to make these changes, because people get invested in methodology, and insist on applying the same lens to everything we do.

It sounds like they had the right idea, but they probably had the wrong people.

Re: Why Segment Went Back to a Monolith

#30

Post by FpUser »

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?
Post reply on HN