Bezoekverslag JFall 2019 – part 2

Events

Vorige week vond weer de grootste Java conferentie van Nederland plaats: JFall. Onze collega Christiaan Rudolfs was erbij en doet in 2 delen verslag. Hieronder deel 2 van zijn verslag!

Developing with Kubernetes

Spreker: Ray Tsang

In deze sessie vertelt Ray Tsang (werkzaam bij Google) over de keuzes die hij in een van zijn projecten heeft moeten maken met betrekking tot het ontwikkelen van een applicatie in een Cloud Native stack op een Kubernetes platform.

De sessie begint met een introductie over de Twelve-Factor App methode (12factor.net) en de afwegingen die gemaakt moeten worden bij de keuze voor een mono-repo versus een multi-repo.  Een demo volgt waarin Ray in een sneltrein vaart laat zien hoe je een Spring Boot applicatie met Spring Cloud GCP (Google Cloud Platform) maakt en naar een Kubernetes cluster deployed en welke tools je kunt gebruiken voor de lokale ontwikkeling met Kubernetes. Onder andere K3S, Jib, Skaffold en Kustomize komen aan bod en hij demonstreert de IntelliJ Cloud Code plugin waarmee het lokale Kubernetes ontwikkel proces wordt vereenvoudigd. Een belangrijke boodschap in deze sessie is dat het verschil tussen lokale Kubernetes en productie Kubernetes enorm is en dat je services hoogst waarschijnlijk niet in één keer zullen werken op productie. Probeer lokaal dus geen Service Mesh (bijvoorbeeld Istio) op te tuigen, aangezien de inrichting hiervan nooit gelijk zal zijn aan productie in verband met het verschil in o.a. netwerk en beveiliging condities.

Een interessante en leerzame sessie. Hier wordt maar weer eens aangetoond dat een gedistribueerde service architectuur een stuk complexiteit met zich meebrengt en dat er ook op ontwikkel vlak veel zaken zijn waar je rekening mee moet houden. Gelukkig zijn er verscheidene tools beschikbaar waarmee de ontwikkelaar een deel van deze complexiteit te lijf kan gaan.


Jfall1.png

My Kotlin is better than your Java

Sprekers: Paulien van Alst & Brian Vermeer

In deze sessie gaan Paulien en Brian de Kotlin vs Java battle aan. De (grote) zaal zat goed gevuld, ondanks dat deze sessie al eerder dit jaar werd vertoond tijdens J-Spring 2019. In een aantal rondes worden verschillende aspecten van zowel Kotlin als Java tegen het licht gehouden en wordt geprobeerd te bepalen waarin Kotlin nu eigenlijk uitblinkt ten opzichte van Java, of misschien toch juist minder uitblinkt dan dat (Java) ontwikkelaars altijd denken…

In ronde 1 wordt de stelling gedeponeerd dat Kotlin ‘Yet Another Language’ is. We hebben eerder nieuwe JVM talen gezien zoals Scala en Groovy en zien we deze talen nog veel gebruikt worden in onze huidige projecten? In de top 20 ‘most used programming languages’ staan Java en JavaScript nog altijd op plaats 1 en 2, terwijl Kotlin ergens onderaan bungelt. Wat betreft de continuïteit in projecten, is het dan niet veel eenvoudiger om Java ontwikkelaars te vinden in plaats van Kotlin ontwikkelaars? Aan de andere kant is Kotlin een nieuwe taal die ‘het beste van alle andere werelden’ in zich heeft. Maar is Kotlin niet gewoon ‘syntactic sugar’ voor Java en moeten we met z’n allen niet eens zorgen dat we Java updaten binnen onze projecten…?

Ronde 2 heeft als onderwerp ‘Less is more’. Kotlin heeft data classes, iets waar je in Java veel boilerplate code voor nodig hebt, al valt dit met Lombok wel weer mee. Het is belangrijk dat code efficiënt geschreven, maar vooral gelezen kan worden. Is ‘verbosity’ dan zo slecht? En waarom zou je in een Data Transfer Object niet gewoon ‘public’ fields mogen gebruiken zonder alle getters en setters..? Tot slot heeft Java heeft inmiddels List.of en Map.of methodes, waarmee de code een stuk compacter wordt.

Don’t write code for machines, write code for people, daar gaat het over in ronde 3. Is operator overloading in Kotlin nu eigenlijk wel zo handig? Wat is het gedrag als ik twee ‘Foo’ classes bij elkaar optel? Extension functions in Kotlin, super handig, maar is het duidelijk waar ze gespecificeerd zijn?

Na ronde 3 is het tijd voor een voorlopige stem ronde. Het blijkt dat iets meer dan de helft van de aanwezigen in de zaal de handen omhoog steekt voor Java. Tijd voor Kotlin dus om in de volgende drie rondes meer zielen te winnen…

In ronde 4 komt aan bod dat Kotlin geen null kent. Kotlin is namelijk null safe en dat is écht lekker!

Ronde 5 bespreekt ‘laziness’. De Java Streams API gebruikt namelijk lazy evaluation, terwijl Kotlin standaard eager evaluation gebruikt. In Kotlin kun je lazy evaluation afdwingen met .asSequence methode.

De laatste en 6e ronde gaat over ‘behaviour’. Hierin wordt gesteld dat gedrag in Kotlin niet expliciet is onder andere door het gebruik van Extension Functions en Operator Overloading.

Deze hele sessie is uiteraard bedoeld om de ontwikkelaars op scherp te zetten en te laten inzien dat Kotlin niet de ‘heilige graal’ is. We moeten onze huidige projecten nu niet ineens allemaal in Kotlin willen gaan schrijven, maar zoals voor alle technologie geldt: weet wat je doet en gebruik het daar waar het goed voor is. En als je het nog niet gedaan hebt: upgrade naar Java 11 of hoger!

Multiplayer Pac-Man with RSocket

Spreker: Oleh Dokuka

Welk protocol is nu het meest geschikt om een real-time multiplayer pac-man spel te maken? Deze sessie introduceert RSocket: een binair, multiplexed, transport agnostisch, bi-directioneel, backpressure aware protocol dat ‘reactive’ principes omarmt.

De spreker laat verschillende manieren zien hoe een multiplayer pac-man game gemaakt kan worden en maakt daarmee duidelijk waar RSocket haar toegevoegde waarde ligt. De demo pac-man applicatie is gemaakt met Spring Framework 5, Project Reactor 3 en Protobuf aan de backend kant en Phaser 3, Reactor-JS, TypeScript en Protobuf aan de frontend kant.

De game wordt live door het publiek (in een browser) gespeeld in 4 verschillende versies: de eerste versie is gebaseerd op Http/1.x, de tweede versie maakt gebruik van WebSockets, de derde versie gebruikt gRPC (stevig gekoppeld aan Http/2) en afsluitend uiteraard een versie met RSocket. Zoals verwacht resulteert de Http/1.x versie in hoge latency, maar ook de gRPC versie laat dit zien en dit wordt voornamelijk veroorzaakt doordat de communicatie vanuit de browser nog steeds op basis van Http/1.x verloopt via gRPC-web.

De voordelen en nadelen van Http/1.x en Http/2, WebSockets, Socket.io en gRPC passeren de revue. Socket.io is een erg goede keuze aan de JavaScript kant en gRPC is een uitstekende keuze voor server naar server communicatie en biedt uitstekende integratie met Spring via @GRpcService. Helaas bieden deze opties geen antwoord op de eisen die gesteld worden aan resilience in high-performance reactive (stream) scenario’s. RSocket dekt hier wel de volledige lading en wordt inmiddels actief onderhouden door grote namen zoals Facebook, Pivotal en Netflix. Volgens de spreker heeft Netflix inmiddels afstand gedaan van gRPC en wordt de overstap naar RSocket gemaakt.

Interessant om de ontwikkeling van RSocket in de gaten te houden!


Jfall2.png

Afsluiting

Na een lange, gezellige dag met interessante sessies is er afsluitend nog tijd om onder het genot van een hapje en drankje na te praten met een aantal (oud) collega’s.

Wat opvalt is dat GraalVM sterk in opmars is en dat steeds meer (Microservice) frameworks zoals Quarkus, Micronaut en Spring dit (gaan) omarmen. Er is veel aandacht voor cloud-native ontwikkelingen op het gebied van Microservice architectuur, Kubernetes en Serverless.

Java is ‘all over the place’ en nu nog sneller en meer ‘lightweight’ dan ooit!

Gerelateerde berichten