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

141–150 of 328 posts

Re: Why Segment Went Back to a Monolith

#141

Post by curryst »

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…

> As a researcher, the monitoring and fault-propagation / modeling work they’ve done to get it to stay up at all is impressive, but it’s not clear all of that tooling would be necessary if they didn’t have to reason about N^2 fault tolerance scenarios, where N = 100’s of microservices. That’s on the order of one fault tolerance scenario for each atom in the universe.

That doesn't seem true. I would imagine that at Netflix scale, you probably have request tracing libraries that can give you a graph of service dependencies. Whether it's worthwhile to consume that, or easier to just let Chaos Monkey run rampant is another question.

Also, I very rarely have issues with Netflix. Typically when I do I can just exit the stream and restart it. Anecdata, but I could count on one hand the number of times I've had a title just not play, or Netflix be down entirely.

Re: Why Segment Went Back to a Monolith

#142

Post by revskill »

Whatever monothlic or microservice, it's all about modularity. Monothlic or microservice is just the implementation on how you achive modularity.

So the problem here, to me, is how you design the modularity for your system, not how you implement it.

Re: Why Segment Went Back to a Monolith

#143

Post by corpMaverick »

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?

It is probably too late to change the name. But you have a good point, the "micro" prefix is highly misleading. Furthermore, there is little guidance in the literature on how big the microservices are.

Re: Why Segment Went Back to a Monolith

#144

Post by DrScientist »

I'm struggling to understand the problem with shared code and the desire to fragment the code repo!

Why can't you have both independently deployed microservices and a shared code base?

If the deployment lifecycle is different for each microservices and each deployment is self-contained, then they can be deployed with different versions of the code - even if they use the same source tree and share code.

Obviously the shared code needs to be properly maintained and evolved, but it seems to me a lot of the software engineering problems occur when people move away from source code dependencies - with great tooling - versioning, diffs, debuggers - to other types of dependencies ( shared libs etc ) where the tools are non-existent or very simple.

Now granted if you needed to fix a critical bug in the shared code - that would require a redeploy of everything, but that happens much less frequently than the need to deploy a single service with immunity as long as your keep your microservice contract. It also means the discipline of making sure every services is deploy-able at anytime is kept to.

And if you didn't share code - you probably wouldn't be fixing a single bug once, you'd have much more code, with many more bugs.

Re: Why Segment Went Back to a Monolith

#145

Post by corpMaverick »

he0001 wrote: post #36
camillovisini wrote: post #26

Earlier quoted context omitted.

> Melvin Conway, who introduced the idea in 1967.

Yes, I don’t think that you need microservices to be able to tackle Conway's law. At least it doesn’t have anything to do with each other. You could still do microservices and still fail to deal with Conway’s law.

You don't tackle Conway's law. You can't. You use it on your favor by creating organizational structures that reflect the design that you want in your software.

Re: Why Segment Went Back to a Monolith

#146

Post by curryst »

alkonaut wrote: post #64
klohto wrote: post #60

Earlier quoted context omitted.

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

One of the lines is going to be acceptable performance. Your phone number formatting microservice is going to be orders of magnitude slower than a client library.

The auth service will likely have to hit a DB anyways. Assuming the microservice call has roughly the same network latency as the DB call and the DB has 0 response time, it would double the total time to perform the auth. It only gets more favorable as DB response times go up.

More generally, I think microservices make sense in scenarios where the time to process the request is longer than the network latency incurred by making it a microservice. Things that have to hit a DB are generally okay. Pure functional things that just compute on CPU and RAM are generally not, unless they're very computationally expensive like running a simulation or something like that.

Re: Why Segment Went Back to a Monolith

#147

Post by parasubvert »

Retric wrote: post #93
jrochkind1 wrote: post #83

Earlier quoted context omitted.

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.

That’s not quite right, SOA as originally defined had no mapping to team structure or deployment runtime, it was mostly about defining discrete service interfaces and ensuring your clients used that contract rather than back channels to communicate. Most often you had a dozen services running in a single app server cluster. Conway’s law was rarely discussed (with some exceptions).

Microservices tended towards a single runtime per service, ensuring the deployment lifecycle was tied to the build lifecycle and thus allowing for independent evolution.

Re: Why Segment Went Back to a Monolith

#148

Post by kkapelon »

barrkel wrote: post #76
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.

Sharing code or reinventing the wheel repeatedly is inevitable once you have more than one concern by which you can divide services. For example: let's say you have lots of integrations, and you need to scale compute, and parse and generate common data sent to and from the integrations. You can either have a monolithic integration service which you scale out on load; or you can have integration-specific services that…

Sorry for not being clear.

Having a shared library is not a bad thing on its own. Making the library a bottleneck is the anti-pattern.

If you wish to have a shared-library of microservices you should be prepared to have multiple versions of it running at the same time without any pressure to update everything at once.

If your shared library is the bottleneck, it means that your microservices are tighly coupled (hence the distributed monolith)

Re: Why Segment Went Back to a Monolith

#149

Post by alyricalgenius »

Problem with micro-services is that it comes with a huge amount "that's the RIGHT way to do it" and infinite articles talking about what they are and developers fighting over if your services are too big or too small.

That usually results in abandoning the effort to actually map the use case of your particular application, model your services to the size that make sense to your project... Any big enough system will need some services or workers beyond a single monolith, it doesn't matter if they say they follow micro-services, if they follow any other type of SOA or whatever, these silver bullets are killing engineering. Every project needs to take time to be planned, thought it, refactored, analyzed. If you read a bunch of shit on HN and go applying you end up with a random monster.

Re: Why Segment Went Back to a Monolith

#150

Post by kkapelon »

dx034 wrote: post #56
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.

Reinventing all parts for every microservice sounds wasteful to me. Especially if they handle the same data and/or use the similar business logic.

Let me clarify because I wasn't clear in the parent comment.

Microservices using shared libraries -> ok

Microservices "suffering" from shared libraries -> not ok.

Post reply on HN