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

301–310 of 328 posts

Re: Why Segment Went Back to a Monolith

#301

Post by SquishyPanda23 »

dpix wrote: post #253
SquishyPanda23 wrote: post #244

Earlier quoted context omitted.

> this means you're effectively building a monolith with a microservice architecture. Is that really what you want? I actually kinda do want that, although maybe it's a niche thing. It would be nice to be able to deploy a monolith that's already cut at seams where there's an obvious API boundary. At one extreme, you could imagine a single binary where processes communicate via RPC. What that would give you is an easy…

This is actually a similar approach to how next.js deployed to vercel (previously zeit) works by default. Each page or api endpoint is served by an individual lambda function so they can scale up or down independently https://nextjs.org/docs/deployment#optimized-for-nextjs

Awesome thank you

Re: Why Segment Went Back to a Monolith

#302

Post by parasubvert »

Retric wrote: post #220
parasubvert wrote: post #147

Earlier quoted context omitted.

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

I am not saying that’s how SOA was defined, just that it was used to refer to such team organization around architecture. EX: Amazon famously uses a Service-oriented architecture where a service often maps 1:1 with a team of 3 to 10 engineers. https://en.wikipedia.org/wiki/Microservices At the beginning Microservice was generally viewed as more granular than SOA, though that’s been backed off of.

The general view of microservices was largely invented out of thin air ;) when you look at Martin Fowler’s wiki or Adrian Cockcroft’s presentations which were the originating popularizers of the term , it was all a reasonable refinement of SOA.

But then you’d get some that would make bizarre claims like a microservices must be under 100 lines of code. :shrug:

Re: Why Segment Went Back to a Monolith

#303

Post by [deleted] »

brown9-2 wrote: post #286
cturner wrote: post #98

Earlier quoted context omitted.

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.

I don’t think this is accurate. I’ve worked at companies that did “service-oriented architecture” long before the rise of the term “microservice” and it was clearly recognized that different “services” shouldn’t be so coupled together you can’t redeploy them separately.

[deleted]

Re: Why Segment Went Back to a Monolith

#304

Post by Retric »

parasubvert wrote: post #302
Retric wrote: post #220

Earlier quoted context omitted.

I am not saying that’s how SOA was defined, just that it was used to refer to such team organization around architecture. EX: Amazon famously uses a Service-oriented architecture where a service often maps 1:1 with a team of 3 to 10 engineers. https://en.wikipedia.org/wiki/Microservices At the beginning Microservice was generally viewed as more granular than SOA, though that’s been backed off of.

The general view of microservices was largely invented out of thin air ;) when you look at Martin Fowler’s wiki or Adrian Cockcroft’s presentations which were the originating popularizers of the term , it was all a reasonable refinement of SOA. But then you’d get some that would make bizarre claims like a microservices must be under 100 lines of code. :shrug:

People where not pulling that from thin air.

Cockroft’s Rule of Thumb

Can complete a service in two weeks or less Completed = coded, tested, and in production • Fits in “one or two developers’ heads”

At that rate you quickly hit hundreds of services.

Re: Why Segment Went Back to a Monolith

#305

Post by scaryclam »

brown9-2 wrote: post #286
cturner wrote: post #98

Earlier quoted context omitted.

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.

I don’t think this is accurate. I’ve worked at companies that did “service-oriented architecture” long before the rise of the term “microservice” and it was clearly recognized that different “services” shouldn’t be so coupled together you can’t redeploy them separately.

Yes, you're right. A system that requires services to be deployed together is just a distributed monolith.

Re: Why Segment Went Back to a Monolith

#307

Post by oblio »

malisper wrote: post #299
didip wrote: post #296

Earlier quoted context omitted.

What does segment.io do and what does your company do?

Sure. I'm the founder of freshpaint.io. The premise of segment.io is that there are lots of tools that take user behavior data from your site and it's a lot of work to integrate them all. For example, when a user signs up, you may tell multiple different tools that a user signed up: - You tell Mixpanel so you can create graphs of how many people signed up. - You tell Google Ads so Google knows a specific ad just resu…

This is both interesting and horrifying when I remember how much we are being tracked.

Re: Why Segment Went Back to a Monolith

#308

Post by cgrealy »

throwaway894345 wrote: post #280
cgrealy wrote: post #276

Earlier quoted context omitted.

>> If you have a monorepo, good build tooling, and a good infrastructure as code tool, Yep, and so many organisations ignore these. Especially after a less successful transition to micro-services. "you mean you want to spend more time doing non-customer visible development? You just did that micro services thing a while ago!" "Yes, but to take proper advantage of that we need to invest in the right infrastructure and…

Honestly, that sounds like the devops team didn't communicate well with the business when they pitched them microservices. The business can't reasonably know that moving to microservices entails a change in infrastructure and tooling--you have to build that into your high level estimates.

Often, they didn’t. How many stories have we all heard about “wow.. transitioning to microservices was way harder than we expected” followed by a move back to monolith instead of fixing the issues.

That doesn’t mean a micro service architecture is wrong... just that you have to either learn from your mistakes or hire an amazingly talented team... that have learned from mistakes somewhere else.

Re: Why Segment Went Back to a Monolith

#309

Post by andy_ppp »

quickthrower2 wrote: post #294
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.

Or an NPM package works nicely (or .NET assembly, Ruby Gem, Java whatever, etc.)

Library code for sensibly defined pieces 100%... but if you aren't sure of the abstraction, copying code can be more forgiving than making a mess.

Re: Why Segment Went Back to a Monolith

#310

Post by DrScientist »

zzbzq wrote: post #208
gowld wrote: post #170

Earlier quoted context omitted.

> Why can't you have both independently deployed microservices and a shared code base? This is what everyone does, so I can't even comprehend what Segment was doing. Maybe they were deploying a fleet of microservices inside a monolithic deployment? If so, there's no wonder it failed.

We do separate code repos, my last place did separate repos, place before that did monolith(s) but still did separate repos for anything not in the same monolith. I'm pretty sure it's more common to do separate repos, rather than mono-repo, for separate services. Seems to me, though, the problem is people trying so hard to reuse code. That's the main problem cited in the article. People get really gung-ho about reusi…

Ok I see - part of the root of the problem is you are probably using git rather than a version control system that works naturally with large shared repo's like svn?

So it's easier to just have separate repo's - and then that makes sharing code sensibly a nightmare without additional tooling... etc etc because there isn't a single versioning system.

Everything as a separate git repo has a lot to answer for in my opinion.

Post reply on HN