Why Segment Went Back to a Monolith • Hacker News Board

Re: Why Segment Went Back to a Monolith

#131

Post by tinkertamper » Wed, Apr 29, 2020, 2:51 PM UTC

joshdick wrote: post #124

BareNakedCoder wrote: post #103

Earlier quoted context omitted.

Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for e…

You're right, and I think you've highlighted what makes a good monolith so hard to build and maintain. You need to be disciplined to keep a monolith highly modularized. For microservices, in contrast, their architecture encourages modularization.

I don’t know that you need to be much more disciplined to write a large application in a module way vs writing any application in a modular way. A monolith could definitely get messy though if you write them how I see people write microservices.

Re: Why Segment Went Back to a Monolith

#132

Post by 87zuhjkas » Wed, Apr 29, 2020, 2:53 PM UTC

I think we can have both architectures Monolith and Microservices peacefully co-existing, with their own pros and cons.

Re: Why Segment Went Back to a Monolith

#133

Post by stepanhruda » Wed, Apr 29, 2020, 2:54 PM UTC

> There is now a single code repository, and all destination workers use the same version of the shared library.

What if I told you this is unrelated to microservices? You can keep all of their sources in the same repository, sharing dependencies.

Re: Why Segment Went Back to a Monolith

#134

Post by marcosdumay » Wed, Apr 29, 2020, 2:55 PM UTC

bencollier49 wrote: post #27

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.

> In most cases, functionality is best divided by domain.

So, SOA?

Re: Why Segment Went Back to a Monolith

#135

Post by zerotolerance » Wed, Apr 29, 2020, 2:55 PM UTC

Having read their articles a few times, the issues that they were attributing to microservice architecture were really CI problems.

Re: Why Segment Went Back to a Monolith

#136

Post by beastcoast » Wed, Apr 29, 2020, 2:56 PM UTC

hedora wrote: post #105

Are there any case studies where microservices went well? From an end user perspective, Netflix runs in “constantly degraded” mod. From an engineering perspective, they track “number of successful stream starts”, instead of percentage of the time 100% of their services are working. That’s a huge red flag. As a researcher, the monitoring and fault-propagation / modeling work they’ve done to get it to stay up at all is…

Amazon does micro services (or SOA) extremely well. In fact they practically invented the concept. It’s intricately linked with the 2 pizza team and service ownership concept (you build it, you support it)

Re: Why Segment Went Back to a Monolith

#137

Post by 87zuhjkas » Wed, Apr 29, 2020, 2:58 PM UTC

musingsole wrote: post #125

gilbetron wrote: post #97

Earlier quoted context omitted.

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

Conway's Law is a physical law in the same sense as Murphy's Law. It's also obviously true. The organization builds the architecture. The architecture either helps or hinders the organization. The organization builds a new architecture. There's no indirect connection here. If you've seen hierarchical organizations implement microservices, it's because that organization's complement was a microservices architecture. A…

> Conway's Law is a physical law in the same sense as Murphy's Law. It's also obviously true.

It's like a tautology: "In logic, a tautology is a formula or assertion that is true in every possible interpretation."

Re: Why Segment Went Back to a Monolith

#138

Post by momokoko » Wed, Apr 29, 2020, 3:01 PM UTC

fennecfoxen wrote: post #130

BareNakedCoder wrote: post #103

Earlier quoted context omitted.

Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for e…

I think this is actually one of the reasons that microservices became a thing to begin with: teams wouldn't actually apply engineering best practices. Microservices actually make you encapsulate your code, at least within the microservices, because you can't call out to it directly. They don't necessarily force you to implement the single responsibility principle, but they do a good job of pushing you. Microservices…

> They don't necessarily force you to implement the single responsibility principle, but they do a good job of pushing you.

In my experience, if your services are developed by the same people, and not separated by teams, engineers will often tightly couple the services with fragile and opaque dependent changes regardless.

While in monolith this is painful, at least you have a complete stack trace and the ability to run things through a step debugger you orient yourself. In a distributed system tribal knowledge tends to be your only savior.

When we design systems, we need to spend more time thinking about what is most likely to happen as opposed to what we feel should happen.

Re: Why Segment Went Back to a Monolith

#139

Post by debrice » Wed, Apr 29, 2020, 3:02 PM UTC

"Monolith vs Micro-services?" is philosophy at this point. It's a good brain exercise, a great starter for debate, it reveals a lot of insights... all because there is no actual answer.

Re: Why Segment Went Back to a Monolith

#140

Post by [deleted] » Wed, Apr 29, 2020, 3:04 PM UTC

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…

[deleted]