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

261–270 of 328 posts

Re: Why Segment Went Back to a Monolith

#261

Post by danenania »

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.

"Sharing databases across services (micro or not) is generally a pretty bad idea"

I don't think such a blanket statement is justified. There are plenty of situations where it may make sense to pull out some functionality into its own service--so it can be written in a different language, scaled independently, isolated from failures, or whatever--but where giving that service its own separate database would be serious overkill, complicating ops and introducing potential data integrity issues for no real benefit.

"If your deployment relies on synchronized service deployments you really dont have independent services at all."

So what? That's really the point: blindly following the Microservices (TM) doctrine is often a mistake. It's better to just solve whatever problem you're facing in the simplest possible way. While that may mean by-the-book microservices with independent databases, in many cases something in between is a better choice.

Re: Why Segment Went Back to a Monolith

#262

Post by ChrisMarshallNY »

FpUser wrote: post #246
ChrisMarshallNY wrote: post #212

Earlier quoted context omitted.

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.

Note the "-ish". I know that they aren't actually new, and that many "new paradigms" are actually rebranded old stuff (I have been writing software since the early 1980s, and have seen these waves sweeping through the industry; often, with some amusement).

What does happen, though, is that a canon develops, based on these technologies, and [actual] new techniques get created, based on them.

Some of these are nightmares, and need to be strangled before they can crawl off the slab, but sometimes, a gem comes up.

I write about some of my experiences around that here: https://littlegreenviper.com/miscellany/concrete-galoshes/#e...

I remember writing "object-oriented" software for classic C, in the late 1980s. I called it the "faux object" pattern, and was based in state being kept in a structure that was passed around functions. I refined and formalized the idea when I encountered Apple's QuickDraw GX in the early '90s (I suspect that may be the only good thing that I ever got from that sad debacle).

I used the faux object pattern in an SDK I designed in 1994, and it's still being used to this day. Back then, you couldn't pass OOP across module connections, so we had to figure out a way to do it with C.

Nowadays, I can easily pass Swift extensions and virtual implementations across SDKs; no sweat. It's cool.

Re: Why Segment Went Back to a Monolith

#263

Post by chrisan »

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

I mean you admit it yourself, far too often the splitting off is inappropriate. Normally an inappropriate microsservices is a net negative over all that costs you money in the long run. Just because its working doesn't mean it is efficient.

My last two "assimilations" where because one microservice was written in Java. The original guy left and no one (around the company) likes to touch Java (or pretend they don't know/do it) which means it was alaways me who had to update it. It was a very small service, likely why he thought small = micro! but it was about 3 hours of work in the monolith. Now anyone can update/contribute to it and not bug me every time

The other was a microservice that only served the monolith. New features required the monolith to be updated in order to realize the new features.

Re: Why Segment Went Back to a Monolith

#264

Post by afiori »

FpUser wrote: post #246
ChrisMarshallNY wrote: post #212

Earlier quoted context omitted.

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.

In my uninformed opinion many of these "nothing new" cases happen because the newcomer actually solved some (maybe minor) pain point in usability of the old solution. Maybe combined with some good old nostalgia.

In general I agree that people should study more the past, but I do not see any point in dismissing new trends just because the do not market their full genealogy upfront.

Re: Why Segment Went Back to a Monolith

#265

Post by xorcist »

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.

But this was true in the middleware type of products too, and you can't get more monolithic than that.

Re: Why Segment Went Back to a Monolith

#266

Post by afiori »

FpUser wrote: post #179
mbrameld wrote: post #116

Earlier quoted context omitted.

A distinction without a difference.

There is a difference. OOP is just one of many tools to help accomplish a task. Many other tools as well. It is up to the people how to use tools for a job and what tools for what job. You equating OOP with the dangerous things that should be kept away has no basis in programming.

The concept of footgun exists.

Re: Why Segment Went Back to a Monolith

#267

Post by hmeh »

realntl1 wrote: post #192
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…

Why do you assume they have more fault tolerance scenarios simply because they have more deployable units? In every service architecture I've worked with in the last few years, you could theoretically run every single "service" within the same physical process -- provided they all shared the same runtime/lang the way a monolith does. I tend to start service architectures using Ruby exclusively with the Eventide toolk…

I'm currently working with realntl on a transition to Eventide from a Rails monolith for a client project. We reached a point where the monolith was getting harder and harder to change. This is inevitable in my experience, no matter how careful you think you are.

Though the transition is still in progress, I can say that the path forward is clear and hopeful. This company had previously explored other "SOA" paths (distributed monolith) and it was clear that those were very problematic. Luckily, we were able to steer them to an actual evented architecture.

As I said, it's still early days for this particular project, but if you're feeling your monolith is getting harder and harder to develop on, you should start looking into evented architectures. Eventide (ruby)/messagedb (postgresql) are awesome technologies and would be the first I'd consider. Eventide also has a nice slack community filled with people that are learning and improving their software design skill both in the large (architecture) and the small (individual classes/etc). It's small, but they're good people.

Re: Why Segment Went Back to a Monolith

#268

Post by JamesBarney »

chrisan wrote: post #263
JamesBarney wrote: post #245

Earlier quoted context omitted.

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

I mean you admit it yourself, far too often the splitting off is inappropriate. Normally an inappropriate microsservices is a net negative over all that costs you money in the long run. Just because its working doesn't mean it is efficient. My last two "assimilations" where because one microservice was written in Java. The original guy left and no one (around the company) likes to touch Java (or pretend they don't kn…

Makes total sense.

Re: Why Segment Went Back to a Monolith

#269

Post by dpix »

danenania wrote: post #261
dpix wrote: post #231

Earlier quoted context omitted.

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.

"Sharing databases across services (micro or not) is generally a pretty bad idea" I don't think such a blanket statement is justified. There are plenty of situations where it may make sense to pull out some functionality into its own service--so it can be written in a different language, scaled independently, isolated from failures, or whatever--but where giving that service its own separate database would be serious…

I didn't mean it as a completely blanket statement, hence why I said "generally". In my experience it's a lot harder to manage a contract between a db schema and multiple codebases over managing versioned contracts between APIs.

"It's better to just solve whatever problem you're facing in the simplest possible way."

I completely agree with this, but I dont beleive that syncronizing deployments across multiple services is ever simple - have been in this situation at a past company where it would take an entire week every 3 months to do a deployment

Post reply on HN