Java is dead, long live Java

Hi! Today I want to bring here another resource from my “to-read” list: the talk from Paul Bakker (Staff SWE at Netflix) about “How Netflix Really Uses Java”.

I have found this talk really interesting and well provided, with not too many details and with clear explainations: I want to point out the key takeaways I got from it.

Java is alive and kickin’

Java 8 was massive, AFAIK for the banking environment is still the foundational stone but is now time to fade out.

We have the example of skipping Java 11 and jump right to Java 17 but the important part is the evaluation step: Netflix did some tests, they tried out Java 11 and also migrated some services to it but they realized that the effort was to much for the benefit they could get. They found out that they were using non-compatible libraries out of the box and that the language version “new” features were just not game-changing enough.

They did the same evaluation with Java 17 and now their tradeoffs balace went positive and they started the big jump migration. With this, also the migration to Java 21 will be easier and they are already testing it to leverage the new version killer features like Virtual Threads.

Evolution and iteration

Netflix architecture is based on Microservices, the Micro in the word does not relate to the size but to the single responsibility that a service has.

They faced the same problem that B2C applications face and the biggest one was bringing to the user all the informations needed in the most reduced time frame possible having all chunks of information coming from different sources.

This is a fan-out: you decompose a big request that reaches a single entry point into smaller parallelizable ones and reconcile all the responses together.

They iterated over this, first with Java+Groovy BfFE, they found some soft spots:

• FE dev working on BE things (they needed to define which informations they wanted from the BfFE).
• REST is not flexible enough and lead to over-fetching.
• Reactive programming (that is an efficient way to handle the fan-out) require Devs to change their “mental approach” in a more complex one.

They realized that GraphQL was the next step with a lot of benefit:

• FE dev only need to agree with BE devs on the GraphQL schema: friction is reduced.
• Fan-out is still there but is a built-in behaviour for the GraphQL approach: complexity is reduced.
• Reactive approach is not needed anymore: other complexity goes away.

Identify a problem, provide a solution, test it, identify the soft spots, improve the solution, iterate.

Community > In-house framework

A lot of companies have their self-built framework stuffed with libraries they added while wolking down the path of the company historical business. Netflix did as well but they challanged this status-quo to move to the de-facto standard of the Java framework: Spring (boot).

Obviusly this is an outcome of a more detailed analysis but we get some key insight about it:

• Using a widely used framework is easier: more experience, more documentation, developers already used to it etc…
• Why Spring-boot and not Quarkus, Micronaut or something else: because of the popularity and the trust Spring ecosystem (and maintainers) earned in the history.
• Out-of-the-box or even built-in plugins for commons features.

This is only my little recap but I suggest you to invest 50 minutes of your time, maybe in the evening on the couch because is not an “heavy” talk, listening to Paul because, beside the interesting content, also the way he delivered the talk is a valueable thing to learn!

Thanks for reading, see you next time 😎

Lorenzo