Hacker News Reader

Comment by cbb330 | Hacker News Reader

Speaking as a current engineer at LinkedIn,

Big Tech companies will often conflate micro service with large distributed system.

These services are by no means at all micro.

As a former LinkedIn engineer, let me ask, what happened? LI was using protobufs and BJSON like ten years ago. That was part of the whole conversion from Java serialization to rest APIs. This article implies that tossed everything, went back to text based JSON, and then said, “Well somabitch! Binary formats are faster than uncompressed text after all!”

There are 19,000 LinkedIn employees world wide according to my cursory Kagi. That means more than two endpoints for every employee. I feel like regardless of micro or macro that’s an enormous sprawl of entropy.

Are we verbing kagi now?

I'd whynot this.

In which case I'll decisively nope that.

More seriously though, I wish we used generic terms instead of using brands. "Look up" (or lookup as a noun) or "search" can't be too hard to use. We don't need to turn our thoughts into ads at every corner.

(so, yes, I'll take your nope for my whynotting)

Now, if you are launching a search engine, you need to name it wisely for when people verb it. As a brand you probably want this to happen. Duck Duck Go was not very wise.

Given that’s already happened with Google that’s a bit late. I’d rather support Kagi than reinforce Googles brand.

The term “endpoint” is pretty fuzzy. Often it’s meant how many different url handlers there are (eg a service exposing “customers” might have dozens of endpoints for searching them, listing them, creating, updating and deleting them etc.

So number of endpoints can quickly grow to a big number.

Curious to know how many macroservices or monoliths LinkedIn has currently

Our interlinked system of distributed monoliths includes one in AWS region af-south-1, another on the Moon, and a third orbiting Jupiter. All of these services are yours, except for the fourth on Europa. Attempt no POSTing there.

Ok for Jupiter and Europa, you need some redundancy and to be close to your users, but AWS would is a bit unexpected with LinkedIn belonging to MS.

Then again, GitHub still uses AWS IIRC.

Convert all of my JSON to protobuf to get 60% performance improvement?

I'm sorry Dave, I'm afraid I can't do that.

I feel that wholly depends on how you’re classifying those.

What makes a service micro vs macro?

It’s micro if it pulls <1gig of dependencies </s>

I have seen 5 table micro services. A solo backend developer had created "3 micro services" and as I joined the team, their argument was that we're doubled in strength so there were a series of architectural meetings to split everything nicely into 5 different services.

Hello world in NodeJS?

* clones hello_world repo

cd hello_world

npm install

* watches text scroll for five hours

There's certainly a spectrum, but you can have huge clusters of even the most monolithic monolith.

The real semantic fun begins when you have monolithic codebase/deployments that could do everything, but each instance gets assigned a specialized role it serves to its peers _ (I think I've seen someonevdescribing that approach somewhere). I'd consider that micro if there are more than a handful of "roles", perhaps with some qualifier, but it would hopefully be easy to agree than no description is entirely wrong.

I’ve used this approach before, I wonder if there is a name for it ?

we would call it different "installations"

I haven't, but if I had and if I was trying to place it in the conference circuit, I'd call it morphoservice.

(and the actual me who has never reached beyond consumer side in conferences sure hopes that conferences would resist unless a less ridiculous name was found)

It's micro if it is so small that you question why this wasn't done as a library call in the same process.

How’s Ember.js doing these days at LinkedIn?

Pretty good tbh!

Reply on news.ycombinator.com