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

61–70 of 328 posts

Re: Why Segment Went Back to a Monolith

#61

Post by FpUser »

fouc wrote: post #54
FpUser wrote: post #34

Earlier quoted context omitted.

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

Sounds pretty unlikely. You don't need OOP to have fairly DRY and well organized code that is nice and small.

You do not need a lot of things to write software. Does not mean you can no benefit from those when applied with good reasons. OOP concepts can help while coding certain domains and yet other can benefit from a different style.

Re: Why Segment Went Back to a Monolith

#62

Post by pjc50 »

strictfp wrote: post #44
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…

Noo! Building teams around software components cements your architecture and prevents most cross-cutting improvements. I'll claim that splitting a well-structured monolith into microservices will always make it less maintanable, but it might be worth it if you need to for some reason like elasticity or failure tolerance. But for the love of god, keep the design open. Don't tie the existence of internal software compo…

The opposite of "has a team around it" is "abandoned". Or at least low down on somebody's priority list.

Re: Why Segment Went Back to a Monolith

#63

Post by boffinism »

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…

There's what DHH calls the 'Citadel' architecture, which is basically you carve off a few small chunks from your monolith where needed and call them 'outposts':

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Re: Why Segment Went Back to a Monolith

#64

Post by alkonaut »

klohto wrote: post #60
MaxBarraclough wrote: post #51

Earlier quoted context omitted.

That sounds like an overly broad generalisation. They might well all share the same basic framework code, of course. Why not share code for recurring concerns like auth?

Because if you share something (like auth for example), you should have microservice for that. The question is not about duplicate code, but about duplicate libraries that handle the same thing. Decoupling the auth process into separate microservice removes the bottleneck.

Eventually you'll have a service to format phone numbers in the format that the company needs to be standard across all services.

If you don't want to do that, then you need a simple shared library for that.

The problem is that there is no easy way to draw the line between "this is obviously a trivial library function we should just link into our code" and "this is something we can't share because it would create friction or break our isolation".

Auth is obviously a "service" but phone number formatting as a service seems extreme.

Re: Why Segment Went Back to a Monolith

#66

Post by pjc50 »

kkapelon wrote: post #46

>Shared libraries were created to provide behavior that was similar for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

This is really a time-of-binding argument; the difference between a "library" and a "service" is that one is in-process and accessed over function calls, and the other is out-process and accessed over RPC.

If you change code that other services are using, you can break those other services. No way round that.

Re: Why Segment Went Back to a Monolith

#67

Post by pjc50 »

thedevopsguy wrote: post #53

Without knowing more about their architecture it is difficult to comment beyond the conclusion Alexandra Noonan came to, stated at the beginning of the article. It looks like to me that the architectural assumptions were changing too quickly due to the demands of a fast growing business. Having all their code in a single repository means that they can control dependencies, versioning and deployment centrally, it give…

If the microservices are in a single repo and tested and deployed together then they are arguably no longer microservices but a "distributed monolith"!

Re: Why Segment Went Back to a Monolith

#68

Post by pjc50 »

tartrate wrote: post #39
pjmlp wrote: post #7

Earlier quoted context omitted.

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?

For almost all works produced by more than one developer the "good developer / bad developer" dichotomy is just useless social darwinism. Talking about the team, organisation, incentives, or business is far more useful.

(My favourite example is John Romero, part of the very small team that produced Doom - but who also produced Daikatana, which keeps showing up on lists of notoriously bad games.)

Re: Why Segment Went Back to a Monolith

#69

Post by gridlockd »

kkapelon wrote: post #46

>Shared libraries were created to provide behavior that was similar for all workers. However, this created a new bottleneck, where changes to the shared code could require a week of developer effort, mostly due to testing constraints. That is a big red flag. Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

> Microservices that suffer from shared code changes are not really microservices, but a distributed monolith instead.

In other words, if you can share a lot of code between services, a monolith is actually an appropriate architecture.

Re: Why Segment Went Back to a Monolith

#70

Post by pjc50 »

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.

See Coase and the "Theory of the Firm": https://en.wikipedia.org/wiki/Theory_of_the_firm

Occasionally companies actually do this by fragmenting divisions into separate companies, such as outsourcing IT. It has a very broad range of outcomes, from saving to destroying the business.

Post reply on HN