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

91–100 of 328 posts

Re: Why Segment Went Back to a Monolith

#91

Post by jjgreen »

ChrisMarshallNY wrote: post #74
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".

Don't get me wrong. I love OOP, and have been using it since before it was cool. It's been a standard wrench in my toolbox for decades. In fact, I have been running into folks, these days, that don't understand it, as, apparently, OOP is becoming "uncool." I've always been a "right tool for the right job" kind of guy. I started off with ML (Machine Language , not Machine Learning ). I am quite comfortable, sitting do…

Please write a blog post called "Horrific OOP chimeras" and post a link on HN ...

Re: Why Segment Went Back to a Monolith

#92

Post by Autowired »

pestaa wrote: post #78
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…

2 pizza team? Well finally I might get my own microservice after all.

This metric is also unsuitable for Europe, where generally pizzas are individual.

Re: Why Segment Went Back to a Monolith

#93

Post by Retric »

jrochkind1 wrote: post #83
andy_ppp wrote: post #43

Earlier quoted context omitted.

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.

That's not what the person you are replying to said though, "the organizational structure is wrong". More like: It is a mistake to use microservices UNLESS you have a certain organizational structure/capacity already. I think they were saying something more aligned with your opinion than you read it as.

We are dealing with poorly defined terms. However, services mapping ~1:1 teams was generally called service oriented architecture not micro services. Micro services involved breaking things into even smaller chunks, so backing off of that idea really just means SOA as originally defined is a bad idea.

Re: Why Segment Went Back to a Monolith

#94

Post by 7777fps »

boffinism wrote: post #65

That final paragraph is pretty brutal. Are engineers really so reliably obnoxious?

In general, yes.

Everyone seems to have their preferred style of coding, and it is an easy defence mechanism, when presented with anyone who tries and finds it wanting, to say that "Well they didn't do it properly".

You find that with Microservices vs Monolith, Strong types vs Weak types, Exception Handling vs Results, Agile vs Waterfall.

People fragment into camps which turn into echo chambers and it's easy to dismiss anyone who doesn't commit to that cult as being unpure and not worthy of being in the cult anyway.

Re: Why Segment Went Back to a Monolith

#95

Post by axegon_ »

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…

Mmmmyes and no. Depending on the size of your project, that may not be the case. I've had to work with two titans of monoliths, maintained by relatively small teams(anywhere between 2 and 6-7 people for several million lines of code). At some point managing a codebase this big within a single project becomes a huge burden, for both developers and even more so for those who develop and do code-reviews(first hand experience right here). At times I've spent 3 weeks straight doing code reviews with 2 notebooks filled with notes and diagrams of the different components inside the code. And at that point, the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice with the adequate amounts of tests. For small projects, microservices make little absolutely no sense. But in the case of something the size of AdWords(which my two such experiences can be compared to), you are playing with a raging lion if you decide to go monolith.

My argument here is that it's not so much the size of your team but rather the size and scale of your project that needs to be taken into consideration.

Re: Why Segment Went Back to a Monolith

#96

Post by lllr_finger »

yowlingcat wrote: post #81
andy_ppp wrote: post #43

Earlier quoted context omitted.

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.

I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?

I agree with you, but I find some value in people using that term - it signals to me that I should consider the the architecture was prematurely split-up and could suffer from the various pitfalls associated with microservices.

Re: Why Segment Went Back to a Monolith

#97

Post by gilbetron »

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…

Conway's Laws isn't a law, it's just an interesting thought experiment. Organization and architecture bidirectionally effect each other, but not directly, and not completely. I hate how current discourse invokes these different "Laws" as if they are physical properties of the universe. I've worked at places with a strong, hierarchical organization that created a wonderful set of "micro" services, and I've worked at places with a chaotic environment that developed monoliths.

There are shitty hierarchies and shitty flat organizations, just like there are shitty monoliths and shitty microservices.

Sorry if you actually agree with this more nuanced view, it's just that I've seen Conway's "Law" invoked more than once in this discussion and it drives me bonkers. I get the same way when someone ("Medium Developers" I call them, more than green but less than seasoned who swallow everything the read on Medium as gospel and run around quoting it zealously) quoted liskov substitution principle at me as if it was one of Newton's Laws.

Re: Why Segment Went Back to a Monolith

#98

Post by cturner »

yowlingcat wrote: post #81
andy_ppp wrote: post #43

Earlier quoted context omitted.

Yeah, the problem with microservices is because the organisation structure is wrong. I’ve literally heard every excuse about microservices at this point. My architecture is better but it doesn’t have a snappy name; it’s called the smallest possible number of services that can be reasoned about and network partitions are NOT necessary to create bounded contexts in a codebase, often just a directory is FINE.

I agree. I hate the term microservice for the same reason I hate superlative infected clickbait titles. There's no need for half of the word to exist. Service. What's wrong with service?

Microservice implies systems that are decoupled for deployment purposes. For example, Microservice A could restart to a new version while Microservice B keeps running. This is a more complicated interaction contract than services where their deployment is coordinated in concert.

Re: Why Segment Went Back to a Monolith

#99

Post by Cthulhu_ »

TeeWEE wrote: post #11

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

I mean you are right of course, but at the same time I can't knock the superficial idea of having one codebase for one domain-specific application. Applications / codebases like that are usually not the problem; it's integrating them into the larger whole where things start getting fucky.

Re: Why Segment Went Back to a Monolith

#100

Post by hedora »

gridlockd wrote: post #73
ChrisMarshallNY wrote: post #29

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 architectur…

This phenomenon can be described as "excessive factoring" and it can easily happen under any paradigm. Perhaps it's more prevalent with OOP programmers, but perhaps it just appears that way because the boilerplate for classes is a bit larger than the boilerplate for functions and structs.

The “micro” in “microservices” implies “excessive factoring”. Otherwise they’d be services.
Post reply on HN