INDIVIRTUAL - TECHNISCH PARTNER IN DIGITALE DIENSTVERLENING

JAX London 2019

October 17, 2019

JAX London 2019

JAX London maakt deel uit van een serie van conferenties georganiseerd door S&S Media Group met onderwerpen in de volle breedte van software ontwikkeling. JAX vindt zijn oorsprong in Duitsland, waar het nog altijd het meest actief is, maar organiseert tegenwoordig vele conferenties over de hele wereld. In 2016 is Indivirtual ook aangewezig geweest op JAX London.

De brede opzet van JAX maakt de conferentie erg interessant, maar het is duidelijk dat JAX een achtergrond heeft als Java georiënteerde conferentie. Dit is wel belangrijk om mee te nemen als je ooit een bezoek aan JAX overweegt.

Sinds een aantal jaar heeft JAX een prima locatie gevonden in het Business Design Center in hartje Londen. Een conferentiecentrum in de wijk Islington met een prachtige klassieke centrale hal. Alleen jammer dat JAX daar geen gebruik van maakte en wij in de kleinere achterzaaltjes van het complex zaten weggestopt. Daar voelen It’ers zich blijkbaar meer thuis.

De conferentie beslaat in totaal 4 dagen, 2 dagen workshop en 2 reguliere conferentie dagen. Zowel op de workshop dagen als op de conferentie dagen kan je kiezen uit 5 parallelle tracks. Interessant om te zien dat we ook op de workshop dagen veel keus is. Wat wel jammer was is dat sommige workshops al tijdens het boeken uitverkocht waren en we dus noodgedwongen moesten uitwijken naar andere workshops. Dit ondanks dat op de dag zelf voldoende plaats over leek te zijn. Mocht je dus van plan zijn je ook de workshops te bezoeken is het dus zaak om er op tijd bij te zijn!

Met een kleine delegatie (Rutger Gerritsen en Arno van Lammeren) was Indivirtual de volle 4 dagen in Londen van de partij!

IMG 20191008 132531-2

Java in 2019

OpenJDK

Waar de aangekondigde release cyclus van Oracle de eerste jaren met het nodige wantrouwen in de gaten werd gehouden zie je nu dat deze nieuwe route juist nieuwe initiatieven tot stand weet te brengen. Zoals op JAX London ook vertegenwoordigd door onder andere AdoptOpenJDK, Oracle en Azul, is er een veelvoud van alternatieve op OpenJDK gebaseerde distributies beschikbaar. Zowel gratis of in commerciële enterprise edities, ook weer variabele prijsmodellen op basis van functionaliteit en support. Zoals in meerdere sessies uitgelicht is interessant om te zien dat dit in de Java community nu echt op gang is gekomen met deze verandering!

Oracle JDK

Naast de verandering in de distributie van de JDK volgen de nieuwe versies van Java zich inmiddels in rap tempo op. Versie 13 is onlangs nog uitgekomen. De meeste aandacht gaat wel uit naar de zogenaamde Long Time Support versies (LTS), zoals Java 8 (nog wel), Java 11 (en elke 3 jaar in het vervolg met als eerst volgende editie Java 17). De tussentijdse releases komen elke 6 maanden en richten zich vooral op nieuwe features, maar het is daarnaast ook heel interessant om te zien dat er daarnaast ook prioriteit ligt bij het optimalisatie van Java en diens runtime. In de tijden van microservices is het goed om te zien dat bijvoorbeeld de opstarttijden weer flink verbeterd zijn.

20191009 122549-2

Microservices

MicroProfile

Emily Jiang liet ons zien dat in een tijd waarin Spring Boot en Spring Cloud de Java Microservice wereld domineert er ook alternatieven zijn voor het implementeren van Microservices in Java. MicroProfile is zo’n alternatief waarbij eigenlijk alles kan dat je ook met Spring Boot (Cloud) kan gebruiken bij het opzetten van Microservices. Via https://start.microprofile.io/ creeër je eigen project op een vergelijkbare manier als de Spring Initializ. Hierbij kan je zelf aangeven welke server runtime je zou willen gebruiken.

micro-profile

Als je dus geen gebruik wil, of kan, maken van Spring lijkt MicroProfile een interessant platform om te overwegen.

Meer info en achtergrond op o.a.: https://openliberty.io/guides/

Microservices en CI/CD

Een microservice architectuur stelt ons in staat om vele verschillende software oplossingen te creëren waarbij je geheel in vrijheid kan bepalen welke technologie je daarvoor inzet. Nir Koren toonde hoe je grote hoeveelheden Microservices (200+) over meerdere teams op een goede manier beheersbaar houdt in combinatie met CI/CD. Nir geeft zelf stellig aan dat het beter is om juist niet allerlei verschillende technologie in te zetten omdat de kans groot is dat alleen maar chaos creëert.

Nir’s doelen en best practices voor CI/CD met microservices:

  • Alle microservices gebruiken dezelfde relevante tools en versies;
  • Alles testen draaien op dezelfde soort manier;
  • Transparantie voor alle Ops en Dev teams over alle microservices (kennis overdraagbaar);
  • Gebruik project (generators (Archetypes) voor standaard structuur;
  • Maak eigen maven of npm plugins om een eigen standaard te kunnen maken. Voor taken die alle MicroServices moeten uitvoeren. (Dit geeft je ook flexibiliteit om standaard plugins te vervangen die beter aansluiten op je eigen deployment process);
  • Maak gebruik van een parent pom om standaard dependencies te definiëren voor alle microservices. (zet versienummers in de omgevingsvariabelen zodat niet iedereen manueel versies hoeft bij te werken);
  • Post-build actions: gebruik governance tools om allerlei soorten violations de build te laten falen! Forceer code standaarden en code kwaliteit. (Maven extensions geven je nog meer flexibiliteit bij pre en post actions van Maven commands en het triggeren van allerlei automatische checks);
  • Gebruik een unified deployment pipeline proces: alle microservices gebruiken dezelfde pipeline structuur

Micro frontends

De hele microservice architectuur vindt voornamelijk plaats op de backend, maar wat heb je aan een superflexibele microservice backend als je alles laat samenkomen in één grote frontend monoliet? Audrey Neveu gaf via een case study hoe zij en haar team een implementatie hebben gedaan van een zogenaamde micro frontend. Een frontend implementatie waarin meerdere teams zo onafhankelijk mogelijk kunnen ontwikkelen binnen het domein van de microservice waarbinnen zij zich bevinden.

Audrey gaf in haar sessie aan dat het lang niet zo eenvoudig was om een werkbare situatie te creëren voor hun team. Uiteindelijk is het haar team gelukt om een zo onafhankelijk mogelijke implementatie te doen middels een “Layout as Library” principe: verpak je gedeelde layout van je applicatie in en (NPM) library en injecteer deze in de eigen domein gedreven implementatie van de frontend.

Interessant om te weten dat IKEA en Zalando ook al pogingen hebben ondernomen van een dergelijke implementatie.

Zie de gehele sessie over Micro frontends bij Devvox van eerder dit jaar:
Embedded content: https://www.youtube.com/watch?v=DczecISRKVU

Domain-driven Design en microservices

Domain-driven Design (DDD) is een term die je verrassend genoeg heel vaak hoort vallen als er tegenwoordig over Microservices gesproken wordt. Grappig is eigenlijk dat Domain-driven Design al best oud is. De terms is bedacht door Eric Evans en kwam pas echt to leven bij diens gelijknamige publicatie ‘Domain-driven design’ in 2003!

De vrijheid die je geniet bij het implementeren van een Microservice architectuur kan er voor zorgen dat elke microservices echt op zich zelfs staat. De keuze voor bijvoorbeeld platform, programmeertaal maar ook het gebruik van modellen en patterns. Dat kan negatieve gevolgen hebben voor de beheersbaarheid van de software. Door een wildgroei aan gebruikte technieken en patterns kan een chaotische architectuur ontstaan.

Daarnaast zie je in de praktijk vaak dat microservices helemaal niet zo op zichzelf staan. Microservices kunnen afhankelijk gemaakt zijn van één of meerdere andere microservices, of bijvoorbeeld gebruik maken van dezelfde data access layer of zelfs database.

Voor beide scenario’s kan Domain-driven Design een helpende hand bieden. Zoals Carola Lilienthal in haar sessie over Domain-driven Design in combinatie met Microservices benadrukt. Microservices moet zo veel mogelijk op zichzelf staan: eigen modellen en eigen data. Indien Microservices toch een afhankelijkheid op elkaar hebben, dan zou dat alleen het geval moeten zijn als de microservices zich in hetzelfde logische domein bevinden. Ook is de voorwaarde dat de microservices een afhankelijkheid van elkaar hebben op diens interface, en niet onderwater.

lilienthal microservices 6

Interessant is dat Domain-driven Design tegen een principe als DRY (don’t repeat yourself) kan ingaan: soms is het beter om code te dupliceren, dan een bijvoorbeeld gebruik te maken van gedeelde modellen.

Voor de conferentie heeft Carola een zeer uitgebreid artikel geschreven over dit ontwerp.

Technical debt

Vele van ons zullen de term technical debt wel kennen binnen ons dagelijks werk. Maar wat is technical debt nu eigenlijk en hoe ontstaat het, of beter nog, hoe voorkomt je technical debt? Carola Lilienthal ging in een tweede sessie van haar in op deze vraag.

Technical debt is een metafoor voor allerlei soorten keuzes en besluitvorming binnen een softwareontwikkeling traject die (uiteindelijk) niet de juiste te blijken voor het goed en eenvoudig beheer en doorontwikkeling. De langere doorlooptijd die nodig is voor het kunnen werken aan nieuwe features of het oplossen van bugs is het gene waar je als het ware voor extra voor betaald.

Technical debt hoeft niet alleen te maken met implementatiekeuzes binnen de software, maar bijvoorbeeld ook met missende documentatie, te weinig unit testen of verkeerde keuzes die gemaakt zijn in de architectuur van een systeem (slecht ontwerp).

Technical debt wegwerken blijkt in de praktijk lastig. Slecht beheerbare code krijgt pleister op pleister tot je op een punt komt waar je besluit het compleet los te laten en een geheel nieuwe implementatie te schrijven. Dit wordt ook wel de zogenaamde CRAP cycle (Create/Repair/Abandon/rePlace) genoemd.

technical-debt

Carola heeft zelf uitgebreid onderzoek gedaan naar hoe je technical debt goed kan oplossen. Zoals wel vaker met het oplossen van problemen blijkt het voorkomen vaak beter dan genezen. We zijn meer tijd kwijt aan het interpreteren van code (70%) dan aan het schrijven ervan (10%). Met goed interpreteerbare complexe systemen valt veel tijdwinst te behalen en kan technical debt (grotendeels) worden ingeperkt.

code-comprehension

Maar hoe creëer je nu een goed interpreteerbaar systeem? Carola heeft hierbij vooral gekeken naar de cognitieve vaardigheden van mensen. Mensen zijn vooral succesvol bij het opnemen van kennis als systemen zijn opgeknipt (modulair) en gebruik maken van hiërarchie en schemas (patterns). Dit is dan ook letterlijk wat Carola adviseert:

  • Zet software zo modulair mogelijk op (high cohesion/lose coupling en separation of concerns);
  • Maar gebruik van hiërarchische lagen;
  • Kies één (of een beperkt aantal) patterns en hou hier aan vast!

Daarnaast is het belangrijk om (eigen) code standaarden op te stellen en hier actief op te controleren. Uiteraard is het ook essentieel om zo veel mogelijk unit testen te schrijven.

cognitive-mechanisms

In een sessie van een aantal jaar terug bespreekt ze hetzelfde probleem binnen de context van Domain-driven Design.

Embedded content: https://www.youtube.com/watch?v=eJjadzMRQAk

Carola is de schrijfster van het boek ‘Sustainable Software Architecture: Analyze and Reduce Technical Debt’. Interessant als je meer wilt weten over dit onderwerp!

GraalVM

GraalVM is momenteel één van de grootste hypes in (Java) software development. GraalVM is een high performance meertalige virtual machine ontwikkeld door Oracle Labs die de mogelijkheid heeft om meerdere verschillende talen in dezelfde runtime te draaien. Het idee achter deze meertalige VM is om ontwikkelaars de vrijheid te geven om een eigen programmeertaal te kiezen, maar in runtime met optimale performance.

Naast dat het als doel heeft om een optimale performance te bieden, wil het ook de mogelijkheid bieden om verschillende talen in dezelfde VM te kunnen draaien. Men heeft het dan ook over een Polyglot VM. Het concept gaat zelf zo ver dat je een applicatie kan creëren, geschreven in meerdere talen, waarbij je de mogelijkheid hebt om code in andere talen te kunnen gebruiken. Je zou dus, bijvoorbeeld vanuit je Java code, andere code in de applicatie, geschreven in JavaScript, kunnen aanroepen. Voor de GraalVM is hiervoor een speciale API beschikbaar gesteld waardoor je dit zonder al te veel moeite zou moeten kunnen doen. Op het moment van schrijven voor en de volgende talen ondersteund: JavaScript, Python, Ruby, R, JVM gebaseerde talen zoals Java, Scala, Groovy, Kotlin, Clojure, en LLVM gebaseerde talen zoals C en C++.

In het specifiek wordt GraalVM geroemd om zijn kleine footprint en mogelijkheid voor snelle opstarttijd door middel van ahead-of-tim compilatie in plaats van just-in-time compilatie.

Op JAX genoot Graal ook de nodige aandacht. De sessie van Chris Thalinger van Twitter heeft in zijn sessie toegelicht hoe Twitter met GraalVM experimenteerd ten behoeve van betere code en kostenreductie. Bij Twitter heeft dit zelfs een ethische reden en probeert vooral ook bewust te kijken naar de negative effecten alle benodigde rekenkracht. Dat geeft wel aan hoe serieus de interesse is vanuit het werkveld is voor deze nieuwe techniek.

GraalVM is een onderwerp dat we vermoedelijk de aankomende jaren veel voorbij zullen zien komen op de nodige conferenties. Een zeer interessant project om in de gaten te houden!

Ook interessant om te lezen: Chris Seaton’s: “Top 10 Things To Do With GraalVM”.

Tot slot

JAX London is voor ons een succes geweest. Londen is een uitstekende stad om een conferentie te bezoeken en JAX was met zijn locatie prima bereikbaar. De conferentie was goed georganiseerd en naar onze mening vooral niet té groot. Bij echt grote conferenties is het vooral moeilijk keuzes maken omdat er veel verschillende tracks zijn en soms ook met grote loopafstanden.

Inhoudelijk was er met onze Java achtergrond in ieder geval voldoende diepgang te vinden. Het is het goed om te zien dat een trend als Microservices zijn plek duidelijk heeft veroverd en het stempel van ‘nieuwe techniek’ duidelijk heeft afgeschud. Je merkt dit vooral aan het aantal sessies met onderwerpen rondom de volgende stap met microservices. Persoonlijk verraste het mij vooral hoe vaak de term Domain-driven Design viel tijdens de sessies. De behoefte aan goede structuur binnen de microservice architectuur is duidelijk iets waar men DDD probeert te omarmen. Zeker iets om je verder in te verdiepen!

Met de verbeteringen van Java zelf, en spraakmakende nieuwe technieken als GraalVM is het interessant om te zien dat er veel meer focus ligt op optimalisatie en het beperken van de footprint van onze applicaties.

Het heeft ons in ieder geval weer de nodige dosis inspiratie gegeven om aan de slag te gaan met nieuwe ontwerpen. Op naar onze volgende conferentie!

Arno van Lammeren

Arno van Lammeren

Senior Java Developer