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

241–250 of 328 posts

Re: Why Segment Went Back to a Monolith

#241

Post by yowlingcat »

strictfp wrote: post #195
yowlingcat wrote: post #79

Earlier quoted context omitted.

What is your alternative? Tying "the existence of internal software components to people's livelihoods" across the expanse of the entire codebase is the only remotely effective approach I've seen to scaling the SDLC at scale.

Think of all the open source libs. Generally speaking, anyone can contribute to any part of the project. That's not to say that some people are better than others at certain parts of the codebase, but you don't want people fighting to keep old cruft in because it's on their job title (figuratively speaking). You can organize around customers, use-cases, platforms, concerns or other things. Some might naturally map 1-…

I see, you meant things in a more literal sense. I generally agree with you in that case, that the customer experience should be the thing which the team owns, which incidentally involves owning software components. But on the other hand, it's also certainly the case that at a company of a given size or in a given sector, certain kinds of software components and infrastructure are not directly customer facing and yet must be owned in house, and logistically serve as one of (if not the only) competitive advantage over competitors.

Is it wasteful to have whole teams at GOOG, FB et al owning and improving the state of the art of infrastructure? It depends. At a certain point, there are enough internal customers for teams to reach contribution margin positive on engineering initiatives that have no direct but only second order effects on customer experience.

Re: Why Segment Went Back to a Monolith

#242

Post by cytzol »

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…

This, this, this! It's been said elsewhere in these comments, but the term "micro"-services really do them a disservice, like it's expected that you need to break your application up into little pieces, to eliminate complexity. But many applications are inherently complex, and splitting them up isn't going to get you anywhere.

I've been trying to advocate for a "solar system model of services", where you have a big core application in the middle (the sun), surrounded by helper services of various kinds. Your important business logic can be left alone, but the database, other data stores, functions, timers, queues, integrations with third-party systems, one-off jobs, and other things can all stay in orbit.

There are benefits that you get from multiple services that you don't get from a monolith: having to rely on service discovery instead of hard-coding addresses or passwords, being unable to assume that the server your code is running on will live forever, and requiring a concrete CI-CD pipeline to get your code up-and-running are all good things to have, no matter your model, so it's important to have a clearly-defined process for them. A service-oriented architecture can give you that — put down the pickaxe, you don't need to split the monolith in two.

Re: Why Segment Went Back to a Monolith

#243

Post by kelnos »

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…

> People get really gung-ho about reusing code and creating shared libraries, but reusing code is actually bad most of the time.

Disagree here, in general. I'm not in the ruby hyper-DRY camp, but copypasta is not the solution to dependency management problems.

Creating shared libraries does require discipline; you should do your best to just avoid breaking changes ever, and on the rare occasion you must, you need heavy communication and testing to ensure consumers find out about the change. And you can only change the API of the library; you can never incompatibly change how the library interacts with other services. I get that this is hard, but it's worthwhile if you can do it right.

We have thousands (maybe even tens of thousands) of lines of share library code at this point. Some of it is probably not necessary, but most of it we'd be completely lost without. Reimplementing core logic and utility classes and auth code over and over again is a great way to burn out your developers and create bugs. And these bugs are even worse than your garden-variety bugs, because you have to track them down and fix them over and over, and each fix is slightly different because each reimplementation is slightly different.

I agree that sometimes sharing code is a bad idea, but asserting it's bad "most of the time" is completely antithetical to my experience.

Re: Why Segment Went Back to a Monolith

#244

Post by SquishyPanda23 »

gregmac wrote: post #221
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…

> 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 way to split off microservices as they're needed.

I'm sure somebody has done work along these lines.

Re: Why Segment Went Back to a Monolith

#245

Post by JamesBarney »

Tobani wrote: post #217
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…

At my current place of work we have 1 monolith and 2 "Micro-Serivces" Working in the monolith is fine, but running tests is slow because it is a giant rails app that is 7+ years old. There is 1 "microservice" that does its thing and the few people who need to interact with it like it. the second microservice was created, deployed and abandoned. Now people want to move it into the core monolith. It is a distinct unit…

If it's working well why change it?

If your co-workers argument is just "microservices bad" then obviously they are making a mistake. But in the general I've seen far more frequent inappropriate splitting of monoliths than inappropriate combining of microservices. (this is honestly the first time I've heard of it.)

Re: Why Segment Went Back to a Monolith

#246

Post by FpUser »

ChrisMarshallNY wrote: post #212
FpUser wrote: post #181

Earlier quoted context omitted.

Lots of words. What's the conclusion? OOP is bad? Or maybe it is incompetent people who manage to f.. things up no matter what you give them or people with the agenda going on holy crusades?

No, OOP is not "Bad." I'm not feeling particularly argumentative. I apologize if what I wrote upset you. I suspect that we may actually agree on most things. In some cases, it is not the best tool for the job, but I find that I tend to use OOP for almost everything I do; large or small. It isn't of much use in small utility scripts, though, and some languages are just not written to natively support it. In those case…

"There are new-ish methodologies, like functional programming, and protocol-oriented programming, that deprecate "classic" OOP. Some folks are using these as backing for declaring OOP "dead."

Those are anything but new-ish. In programming new often means that some old concept suddenly becomes fashionable. Myself I do not restrict to any single paradigm and use what I believe is the most suitable for current task.

Re: Why Segment Went Back to a Monolith

#247

Post by leogout »

> One of the key takeaways was that spending a few days or weeks to do more analysis could avoid a situation that takes years to correct.

Exactly my point when I was working on a new project architecture and we had to choose between two authentication methods. Because once all your applications rely on an authentication system you can't just switch to the other one like that... Sadly we did not take the time six month ago and today we are working on a migration which could have been avoided.

Re: Why Segment Went Back to a Monolith

#248

Post by [deleted] »

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…

[deleted]

Re: Why Segment Went Back to a Monolith

#249

Post by herval »

dodobirdlord wrote: post #176
herval wrote: post #127

Earlier quoted context omitted.

Is there any example where this works (articles, presentations, etc)? In particular, anywhere with more than a couple dozen developers?

Amazon has a famous love for what they call “two-pizza teams” and you can find writeups about the philosophy by searching the term. The joke is that a team should be small enough that you only need to order two pizzas to feed them all. The philosophy is about the number of participants in the decision-making process. Keep teams small and give them total ownership of decision making so that decisions can be made by a…

Amazon is very well known for having A LOT of middle managers too, so I'm not sure it's a good example?

Re: Why Segment Went Back to a Monolith

#250

Post by mynegation »

leogout wrote: post #247

> One of the key takeaways was that spending a few days or weeks to do more analysis could avoid a situation that takes years to correct. Exactly my point when I was working on a new project architecture and we had to choose between two authentication methods. Because once all your applications rely on an authentication system you can't just switch to the other one like that... Sadly we did not take the time six mont…

Why don't you share your insights?
Post reply on HN