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

11–20 of 100 posts

Re: How Netflix really uses Java

#11

Post by pgoggijr »

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.

At Netflix scale, there most certainly is a service discovery registry where each service registers itself. The registry can be used for other services to find out how to reach each service, what regions those services are deployed in, how many instances of each service there are, what operations that service supports, etc.

https://devopscube.com/service-discovery-explained/

Re: How Netflix really uses Java

#12

Post by kagakuninja »

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

Re: How Netflix really uses Java

#13

Post by lbhdc »

Solvency wrote: post #3

In theory... would Go be (1) as performant for Netflix's scale/speed needs, and (2) be practical in 2024 from a platform/ecosystem perspective?

I think that depends. One of the advantages that the jdk offers is jit. I haven't seen the inside of netflix, but I am guessing it is similar to other big tech companies where they have a large portion of there instances on all the time, and receiving a lot of traffic. This can be an advantage for the jit.

I think there is a great ecosystem for building large systems with go (check out cncf for a ton of go projects targeting the cloud), but a lot of big tech companies open source their java frameworks, tools, and systems. If you are looking for something really specific there may not be an equivalent in go.

I think go is great, and it is close enough for me to continue to choose it for this kind of work.

Re: How Netflix really uses Java

#14

Post by scintill76 »

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.

Re: How Netflix really uses Java

#15

Post by jedberg »

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

RX definitely requires some non-standard thinking to do well, but any competent engineer can get it if they want to dedicate the time to it.

But you're right, the same things can be accomplished in other ways with less up front effort. But where it really shines is when you hit massive scale. Having RX and its concepts in place ahead of growth makes the growth easier.

Re: How Netflix really uses Java

#16

Post by [deleted] »

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.

[deleted]

Re: How Netflix really uses Java

#18

Post by 4pkjai »

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

I had a close look at RxJava and decided I wasn't smart enough to understand it. I intentionally didn't tell my colleagues about it, they would have loved it and I would have been in big trouble.

Re: How Netflix really uses Java

#19

Post by schainks »

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.

Lol the Disney+ app UX is honestly terrible. Not to mention the regular app crashes on apple devices.

Disney has _how_ much money to spend on their streaming services technology stack and they just... don't?

Just feels like they'll piss on the customerwhen given the chance because people will still pay for that sweet Disney juice regardless.

Re: How Netflix really uses Java

#20

Post by John23832 »

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 worked well and could be maintained… not one that was the most efficient.

Post reply on HN