Live data from Hacker News

Why Segment Went Back to a Monolith

infoq.com

321–328 of 328 posts

Re: Why Segment Went Back to a Monolith

#321
post #2

How many places have gone from monolith to microservices and back to monolith? I'm sure there's been quite a few.

Just waiting for O'Reilly to drop a book called "Microservices to Monolith"

Like Computer Lib / Dream Machines, where you flip it over backwards to get the other book! ;)

And of course the Microservices section should be really thin, while the Monolith section is extremely thick.

Like PopeDotNinja pointed out, you can just flip the book over when one approach starts to peak.

https://computerlibbook.com/

https://www.youtube.com/watch?v=dcfwLhDDMz4

>VCF East XI -- Ted Nelson: Ted Nelson designed the Xanadu hypertext software and wrote the two-in-one personal computing book, Computer Lib / Dream Machines, in 1974. His work deeply influenced the personal computing revolution. Ted earned two Ph.D.s and penned several other well-regarded academic papers and books about ethical, historical, and moral issues in computing.

https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines

>Computer Lib/Dream Machines is a 1974 book by Ted Nelson, printed as a two-front-cover paperback to indicate its "intertwingled" nature. Originally self-published by Nelson, it was republished with a foreword by Stewart Brand in 1987 by Microsoft Press.

>In Steven Levy's book Hackers, Computer Lib is described as "the epic of the computer revolution, the bible of the hacker dream. [Nelson] was stubborn enough to publish it when no one else seemed to think it was a good idea."

Re: Why Segment Went Back to a Monolith

#322
post #68

Earlier quoted context omitted.

> A team that fails to understand how to write modular code, is just going to write spaghetti RPC calls This is interesting. I always assumed we were talking about good developers here. I wonder what's a more likely cause for a failed attempt at microservices. Is it developer incompetence and lack of discipline, or is it environmental factors related to the product and the organization?

For almost all works produced by more than one developer the "good developer / bad developer" dichotomy is just useless social darwinism. Talking about the team, organisation, incentives, or business is far more useful. (My favourite example is John Romero, part of the very small team that produced Doom - but who also produced Daikatana, which keeps showing up on lists of notoriously bad games.)

That was pure hubris, foreshadowing GamerGate (and inventing the self-Pwn)! As you say, it's all about the team, not the technique. And talking about that particular team:

https://en.wikipedia.org/wiki/Daikatana

>One advert for the game became notorious; a 1997 poster containing the phrase "John Romero's About To Make You His Bitch[. Suck It Down.]". According to Mike Wilson, the advert was created by the same artist who designed the game's box art under order of their chosen advertising agency. Originally, both he and Romero thought it was funny and approved it. Romero had second thoughts soon after but was persuaded by Wilson to let it pass. Speaking ten years later, Romero said while wary of the slogan at the time, he went along with it as he had a reputation for similar crass phrases. In the same interview, he noted that reactions to the poster tarnished the game's image long before release, and continued to impact his public image and career. In a 2008 blog post concerning the recent activities of Wilson, Romero attributed him for the marketing tactic. This prompted a hostile exchange of public messages between the two at the time.

At least he apologized, though:

https://www.youtube.com/watch?v=BF_sahvR4mw

John Romero Apologizes for Trying to Make You His Bitch:

https://v1.escapistmagazine.com/news/view/100748-John-Romero...

>I'm going to quote our very own Shamus Young here for a moment: For almost a decade, Ion Storm's Daikatana has been the example of "industry waste, arrogance, and incompetence, as well as a universal punchline for things that suck." The shooter was supposed to be an epic vision, the masterpiece of John Romero - the mastermind behind genre-defining Doom and Quake.

>Then it came out in May of 2000, and it sucked. The arrogance and hubris that crippled Daikatana have been well chronicled over the years, but none of it is quite as infamous as the ad you see here to the right: "John Romero's About to Make You His Bitch. Suck it Down." It was a pretty ballsy statement in itself, but after the game's failure simply became laughable.

John Romero Is So Sorry About Trying To Make You His Bitch:

https://kotaku.com/john-romero-is-so-sorry-about-trying-to-m...

>Game designer John Romero and John Romero's hair ruled the roost during the 1990s. With titles like Doom and Quake, he not only helped popularize the first-person shooter, he defined it. Then the unthinkable happened. He made Daikatana.

>[...] Romero, who now says he is resigned to the ad, dished on the ad back in 2008, which evoked a saucy response from the marketer that spearheaded the suck-it-down campaign.

Romero Dishes on the Ad:

https://web.archive.org/web/20081225071219/http://kotaku.com...

>[...] these are the kinds of jackass stunts he pulled [...]

Suck-It-Down Campaign Marketer's Saucy Response:

https://web.archive.org/web/20081225070532/http://kotaku.com...

>[...] and ill advised breast implants strewn across this fair nation [...]

Re: Why Segment Went Back to a Monolith

#323

Earlier quoted context omitted.

This person has been stalking me across threads and topics and deliberately trying to ignite conflict. Please warn.

I see you were being sarcastic about there being zero chance you would ever communicate with me again, because you just did one hour later, so I'll reply: Freedom of speech doesn't give you the right to not be replied to: that's not how it works, and you aren't the dictator of what I "need". But it's 100 percent in your hands to not reply to me, after you proclaim there's zero percent chance you ever will. Since you…

Stalking people and trying to incite conflict is against the rules on HN. Freedom of speech allows you to be racist, sexist and start verbal battles in the real world. Not here. You do not have freedom of speech on HN.

You need to back down now because not only are you violating the rules, you are deliberately stalking me to try to start conflict. This is a flagrant violation.

You are not disagreeing with me, you are trying to start a fight. Go away. I am telling you right now, whether you disagree or agree with me or not, I will not have any further conversations with you. It is pointless for you to continue unless your goal is to start shit, In which case you need to stop now because that is a violation.

You want to disagree, than disagree. Your initial comment was not a disagreement, it was an insult based off of another insult you made on another thread. Back the fuck off.

@dang, please moderate. Or please add a feature where you can block certain abusive users from replying.

Re: Why Segment Went Back to a Monolith

#324
post #315

Earlier quoted context omitted.

The way people use OOP causes them to move the complexity in a particular way. That's why the distinction doesn't make a difference in this context. You're right, technically it wasn't OOP that was writing the code, it was the person. We would have never figured that out without your guidance, we all just though OOP was banging away on the keyboard.

"The way people use OOP causes them to move the complexity" Why don't you try to read carefully what you've just said in the sentence above

Why? I wrote it, I know exactly what it means. Maybe you should take a closer look? If everyone who uses OOP moves the complexity in the same way because they're adhering to OOP, then it is a distinction without a difference because the complexity is moved regardless. It's a nuanced concept so don't beat yourself up if you don't understand.

Re: Why Segment Went Back to a Monolith

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

This thread considered an issue: whether services and microservices are equivalent concepts. They are not. There is a quality that is held by Microservices, yet which is not universally held by Services.

You have observed that other services also have that quality. Indeed. Nowhere did I say, "all services with decoupled deployment are microservices".

Re: Why Segment Went Back to a Monolith

#326

Earlier quoted context omitted.

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.

This thread considered an issue: whether services and microservices are equivalent concepts. They are not. There is a quality that is held by Microservices, yet which is not universally held by Services. You have observed that other services also have that quality. Indeed. Nowhere did I say, "all services with decoupled deployment are microservices".

Revisit. I can where brown9 is coming from. I could have avoided leaving that interpretation open by writing, "here is an example of a quality that is held by all X, yet not by all Y".

Re: Why Segment Went Back to a Monolith

#327
post #300
post #183

Earlier quoted context omitted.

A monolith can run distributed and be scaled across data centers. It's not a mainframe application with one host. One process can crash without affecting system stability.

Where you can get into trouble is if the problem affects all your instances across the entire cluster. If all your organization's code is running in the same process, if any of that code has a severe memory leak or other serious issue, it could impact the stability of everything else. Not to say that wouldn't happen for SPOF microservices (e.g. your auth servers), but the surface area is potentially larger for monoli…

On the other hand, if a memory leak concerns one key microservice your whole operation is also likely to suffer, even if 99% of services run fine.

Re: Why Segment Went Back to a Monolith

#328
post #249

Earlier quoted context omitted.

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

Seems sorta reasonable that if you need a manager for every 6-8 engineers, you would end up with a lot of managers.

OP’s post was “ Aggressively small teams, with no hands-off middle-management layer”. 6-8 swe teams + hands off people manager reporting to middle manager, who reports to director, is how Amazon organizes teams, therefore it isn’t an example of what their suggestion was...
Post reply on HN