Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Netflix really uses Java

infoq.com

Post reply on HN
Print view View original

21–30 of 100 posts

Re: How Netflix really uses Java

#21

Post by hombre_fatal »

scintill76 wrote: post #14
iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

One of my peeves on Disney+ on Roku, is scrolling down to ~third row for Continue Watching, takes another 3 seconds to load that list while I stare at the silhouette thumbnails or whatever. I can (barely) understand that they want to advertise their new content prominently above, but it’s just sloppy to make such a common flow (continue watching) feel so slow and irritating.

My peeve with Roku is that the Roku Express' processor is too slow for a smooth UI experience. It's always a few button presses behind.

You shouldn't have to buy the more expensive Roku 4K just to have a device powerful enough to run its own interface smoothly. Granted it's only $10 more but had I known the UI was sluggish I would have paid it from the start even though I don't need 4K. But now I've bought both.

Re: How Netflix really uses Java

#22

Post by __xor_eax_eax »

kagakuninja wrote: post #12
iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I'm interviewing at Disney Streaming, lol

Fix it!

Re: How Netflix really uses Java

#23

Post by criddell »

John23832 wrote: post #20
throwitaway222 wrote: post #9

I bought into the "RX Java/JS/etc.." years back. Everyone I showed the code couldn't handle it, and we just backed off to other methods, and things worked just fine. RX has some interesting ideas, but from a practical standpoint, at companies not netflix, it just doesn't work

Even at Netflix RxJava is not fully accepted. When I was there I wrote a service which called many downstreams. It orchestrated test user creation. I used RxJava because it was being pushed by the platform team, and coupled well with our internal GRPC api handlers. I shared with the team and people complained about the complexity… so I ended up ripping it out. What people wanted was a test user creation service that…

Looking back, do you think choosing practical reasons over efficiency was the right call?

Re: How Netflix really uses Java

#24

Post by gorjusborg »

torcete wrote: post #7

I never worked with micro services, but I have this question. Do micro services require more and better management? I can imagine that you need to keep track of all these services, along with information about dependencies, code version, API version and others. Of course, monolithic services also require these this sort of management, but it should be less complex.

The whole microservices thing is a little crazy.

Someone just looked at what devs came to realize worked well, slapped a name on it and it blew up as a hot thing.

Since then, I've seen so much wrong done in the name of 'microservices'. It shouldn't be some aspirational goal to work with them.

Also, the fact that the word 'micro' is in the name makes the cargo culters split atoms to reach some tiny nirvana. The size isn't the point. The real point is in having the system/component boundaries closely match the problem domain, and that a single group 'maintains' it.

Re: How Netflix really uses Java

#25

Post by mtlmtlmtlmtl »

This is mostly off-topic I suppose but I recently noticed that Netflix, and Netflix on my TV(WebOS) specifically is absolutely spamming my router with DNS requests sometimes several times a minute, most of them for nrdp-ipv6.prod.ftl.netflix.com. I'm not blocking them btw, so it's not some buggy retry thing going on.

Even if I do a hard reboot of my TV and don't start the app, my TV is still happily resolving away. I'm gonna have to set up a local cache or something just to save on my NextDNS quota.

Edit: I just asked Netflix support about it. Worse than useless, just kept telling me to either try a different internet connection(no idea why), then they told me to take it up with my ISP and immediately closed the chat. I'm gonna wait an hour or so, open another chat, and tell them my ISP said this was purely a Netflix issue, I suppose.

Re: How Netflix really uses Java

#26

Post by doctorpangloss »

John23832 wrote: post #20
throwitaway222 wrote: post #9

I bought into the "RX Java/JS/etc.." years back. Everyone I showed the code couldn't handle it, and we just backed off to other methods, and things worked just fine. RX has some interesting ideas, but from a practical standpoint, at companies not netflix, it just doesn't work

Even at Netflix RxJava is not fully accepted. When I was there I wrote a service which called many downstreams. It orchestrated test user creation. I used RxJava because it was being pushed by the platform team, and coupled well with our internal GRPC api handlers. I shared with the team and people complained about the complexity… so I ended up ripping it out. What people wanted was a test user creation service that…

Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex. In my opinion and in the opinion of other adopters, it is a more expressive way to define correct behavior.

This is essentially the same tension between static and dynamic typing.

No matter what, all bug free code is complex. Correct code can be written in any paradigm.

But productful code ships with bugs.

Does test user creation need to be bug free? I don’t know. It feels like something where productful test user creation can ship with bugs, even if in reality your test code harnesses should not be buggy.

You can step even further back and ask: when you have essentially unlimited resources, why ship buggy code at all? Netflix has unlimited capital, and it isn’t in a hurry anywhere. Engineers should never choose productful over bug-free. You learn nothing (Netflix’s product problem will never resemble your startup’s product problem) and you forfeit the opportunity to learn (ReactiveX is a good, expressive paradigm).

This is a startup forum, is this true for startups? IMO, yes. Your startup is going to fail. You will not learn valuable product lessons from the journey. I mean people certainly pretend and say they do, but even in the situation of success, Brian Chesky still hasn’t become Walt Disney last I checked. But once you have enough money to be employed for a year, as an engineer, you know, fucking learn how to do something the right way, bug free and performantly.

So I agree your coworkers are fundamentally making an error.

Re: How Netflix really uses Java

#27

Post by Nican »

I have been out of the loop with Java. Is Virtual Threads the answer to asynchronous I/O? (Much like Go/C# async/node.js?)

That looks like an interesting solution to support asynchronous I/O without breaking all the APIs, and having the async/await mess that C# created.

Re: How Netflix really uses Java

#28

Post by swozey »

I've deployed multiple open sourced netflix java services and each one of them was archived and no longer maintained according to the repos.

Are they still being developed internally and the foss repos are basically without the secret sauce? Or are these projects "done"? Did Netflix move on to replacement tools?

I'm referring to things like hystrix and .. a queue system I can't recall right now. This was a long time ago but that queue system was a bit of a rough roll out and IIRC I had to make a fair amount of code changes to get going.

Not biting the hand that feeds me, just curious about how netflix treats projects like those. I'm usually extremely apprehensive about deploying archived things but a few teams wanted to use them. I don't know if things are archived because they're done, perfect, terrible, cooked, deprecated, insecure..

edit: Oh I hadn't looked at it in a long time, the hystrix repo explains it well on the readme. I'm not sure if the other project I used did that.

Re: How Netflix really uses Java

#29

Post by wesleytodd »

mtlmtlmtlmtl wrote: post #25

This is mostly off-topic I suppose but I recently noticed that Netflix, and Netflix on my TV(WebOS) specifically is absolutely spamming my router with DNS requests sometimes several times a minute, most of them for nrdp-ipv6.prod.ftl.netflix.com. I'm not blocking them btw, so it's not some buggy retry thing going on. Even if I do a hard reboot of my TV and don't start the app, my TV is still happily resolving away. I…

Not my area of work, but pretty sure that is expected behavior to resolve an ever changing set of services being called out to. Better to do dns resolution than for a call to fail and have to re-resolve while you wait on a loading screen right?

Re: How Netflix really uses Java

#30

Post by wiradikusuma »

Meanwhile, if you're building something smaller than Netflix, I'm writing a book just about that (https://opinionatedlaunch.com/).

It's about mobile apps, but I talk about backend at great length, especially since my background is Java. The book is called "opinionated" because I cover Quarkus (https://quarkus.io/), monolith, Fly.io, and no K8s. No fancy stuff to pad your CV, just to get things done the simplest way possible, with the least headache in maintenance (I'm lazy).

Post reply on HN