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

281–290 of 328 posts

Re: Why Segment Went Back to a Monolith

#281

Post by topher200 »

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…

Segment's business in particular has them integrating with dozens of unique endpoints. There's an inherent desire for code-reuse in a system like that, along with customization required per endpoint.

Re: Why Segment Went Back to a Monolith

#282

Post by [deleted] »

rhizome wrote: post #279
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…

The thing that jumps out to me: there are WAY more page-loading indicators now than there has ever been before. Lots more jumping content, lots more laggy content population, many more elements sliding around...I know "worse is better" is a truism of sorts in technology, but this is ridiculous. What good do any of these architecture decisions make when the experience for the user, the customer , is measurably worse?…

[deleted]

Re: Why Segment Went Back to a Monolith

#283

Post by NewEntryHN »

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.

If you have zero coupling, it means you have multiple products.

Re: Why Segment Went Back to a Monolith

#284

Post by folmar »

dpix wrote: post #231
gregmac wrote: post #221

Earlier quoted context omitted.

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…

Sharing databases across services (micro or not) is generally a pretty bad idea exactly for reasons around versioning. Versioning APIs is a pretty standard way to get around this. If your deployment relies on synchronized service deployments you really dont have independent services at all.

Writable views or stored procedures are a pretty standard way to versioning database access from clients.

Re: Why Segment Went Back to a Monolith

#285

Post by phodge »

My org is starting to migrate from a PHP Monolith to Microservices as a way of freeing ourselves from PHP.

Microservices will require more time spent writing interservice APIs, and code execution will be slower since many procedure calls will require data serialization and network requests. But we believe it will be worth the overhead to not be locked into PHP for every new component of the project.

Re: Why Segment Went Back to a Monolith

#286

Post by brown9-2 »

cturner wrote: post #98
yowlingcat wrote: post #81

Earlier quoted context omitted.

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?

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.

Re: Why Segment Went Back to a Monolith

#287

Post by Tobani »

JamesBarney wrote: post #245
Tobani wrote: post #217

Earlier quoted context omitted.

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.)

Honestly it doesn't work well now as a developer. It is about a week worth of work away from being a great developer experience. They'll come around. Honestly every time I have split out a separate service it is because the current state of affairs is bad and there is a distinct need. Those handful of things have been rock solid and needed very little attention, but it has been a last resort.

Re: Why Segment Went Back to a Monolith

#289

Post by brown9-2 »

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…

> 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.

They don’t measure how often 100% or their services are up because perfect uptime is not the goal and is too expensive (if it’s even possible). If an internally facing service being down doesn’t affect a core metric like number of stream starts by customers, then it’s foolish to treat it as needing 99.999% uptime.

Re: Why Segment Went Back to a Monolith

#290

Post by tabtab »

DrScientist wrote: post #165
ajsharp wrote: post #157

I see quite a few people defending microservices; the org is the problem, they must not have written the software correctly, etc. Most org structures are not great. Most software is not great. If you expect the exception to be the rule you're setting yourself up for a career full of disappointment. Microservices are a modern re-branding of service-oriented architecture, but 'microservices' sounds cuter and less like…

> split along domain lines with minimum inter-service dependencies. Exactly, and done right that quite often means big 'microservices'. All too often I see the 'functional programming disease' where the aim is to deconstruct to the smallest possible reusable functions ( 'micro' services right? ), often prematurely, creating high levels of compositional complexity and with zero tools to help you understand how the act…

It's sometimes said that in software, there hasn't been anything truly new under the sun since the 1970's, just incremental refinements or repacking under a different name. And Lisp has been around since about 1960.

So if any fad/trend comes along promising the sun and stars of simplicity or productivity, search IT history and find the downsides and trade-offs.

I wish there were more KISS pundits than fad pundits.

Post reply on HN