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

221–230 of 328 posts

Re: Why Segment Went Back to a Monolith

#221

Post by gregmac »

dpix wrote: post #203

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Microservices might let you ship faster if you are really good at deciding where to draw the lines between services and really good at managing multiple deployment pipelines and all the infra - that's a pretty tough ask. Also, if you have a monolith it's perfectly fine…

I've found it most helpful to think in terms of deployments: Each (micro)service effectively gets deployed independently.

One implication of this is you need to ensure your APIs are backwards compatible with any other services - even if it's only one service that your team also manages. This also includes databases, if shared by multiple services (which I won't get into, suffice to say congrats, your database schema is now also a crappy API).

As soon as you start having concurrent deployment dependencies -- that is, the updates for service a + b both have to be deployed at the same time or things are broken -- you've effectively built a monolith anyway, just with an annoying code layout (eg, spread across multiple repositories).

You can use orchestration to tie these deployments together, but this means you're effectively building a monolith with a microservice architecture. Is that really what you want?

Re: Why Segment Went Back to a Monolith

#224

Post by goodpoint »

beastcoast wrote: post #136
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)

Amazon does SOA with 1 service 3 to 10 engineers.

This is much bigger than the typical microservices, and by choice.

Re: Why Segment Went Back to a Monolith

#225

Post by hinkley »

dionian wrote: post #202
hinkley wrote: post #188

Earlier quoted context omitted.

Mostly these were white boarded, but essentially I/we would draw a collaboration diagram (although I could have sworn these used to be called something else). They showed what data was needed to make certain decisions (eg, a conditional drop down that is populated based on another piece of data, or complex validation steps) and where to get data that already existed.

activity diagram?

Yeah it looks like the activity diagram was substantially altered in UML 2.0. What we called an activity diagram then looks more like a collaboration diagram now.

Re: Why Segment Went Back to a Monolith

#226

Post by hinkley »

> "If microservices are implemented incorrectly or used as a band-aid without addressing some of the root flaws in your system, you'll be unable to do new product development because you're drowning in the complexity."

Which is nearly verbatim what some of us have been telling you since before the term microservices was coined.

Coupling is the problem. Yes, microservices add friction to coupling, but they don't prevent it. Coupled microservices exist (boy howdy), and they're resource intensive, resistant to evolution, or both.

Re: Why Segment Went Back to a Monolith

#227

Post by goodpoint »

pjc50 wrote: post #67
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"!

Spot on. In Amazon's SOA, having different services that need to be deployed at the same time is a no-no.

Re: Why Segment Went Back to a Monolith

#229

Post by zzbzq »

pjc50 wrote: post #66
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.

There are circumstances where they are equivalent, but they're very different overall. Namely, if you use a service, you update it once and see the new behavior everywhere. If you use a shared library, you have to update and redeploy every service. Libraries are strictly inferior in that scenario. This sounded, to me, like it was Segment's problem. They were updating shared libraries all over the place all the time.

I generally avoid creating shared libraries, they're a trap. They have a very narrow band of usefulness squeezed in between the more palatable solutions of creating new services or just copy & pasting code and allowing it to diverge for each different use-case.

Re: Why Segment Went Back to a Monolith

#230

Post by malisper »

If you take a look at some of Segment's open source code, it isn't hard to see why they wound up struggling with microservices. It looks like they subscribe to the "left-pad" style of software development. They have tons of repositories that have less than 10 lines of code. They have a two line repository for calling preventDefault[0], a four line repository for getting the url of a page[1], and a eight line repository for clearing the browser state that calls into eight different packages[2].

Disclaimer: I run a Segment competitor. I'm pretty biased, but still...

[0] https://github.com/segmentio/prevent-default/blob/master/lib...

[1] https://github.com/segmentio/canonical/blob/master/lib/index...

[2] https://github.com/segmentio/clear-env/blob/master/lib/index...

Post reply on HN