Voxxed Days 2018

Toen ik in oktober bij JDriven begon, had ik al toegangskaartjes voor het Voxxed Microservices congres in Parijs op zak. Die had ik gewonnen via de Java User Group in Utrecht. JDriven regelde met alle liefde vervoer en verblijf, en zo kwam ik zondag al aan in Parijs om even van de stad te genieten, alvorens maandag 29 oktober in Espace Charenton te kijken of het beloofde ontbijt me op de been ging kunnen houden voor een dag vol sessies van mij grotendeels onbekende sprekers die gelukkig allemaal Engels spraken.

Daar het programma pas vrij laat bekend was, wist ik niet zo goed wat ik moest verwachten. Met een thema als microservices kun je je verliezen in de technologie (getuige de CNCF landscape, maar ook wild gaan op waarom het als concept alles oplost of juist een bak vol problemen is. Gelukkig bleken de mensen achter Voxxed Parijs een coherent programma te hebben samengevoegd met goede sprekers. Niet alles was nieuw voor me, maar het vormde een goed geheel. Ik zal trachten de rode draad en uitschieters hier te delen. Voxxed Microservices heeft inmiddels de opnames van de sessies online gezet op https://www.youtube.com/playlist?list=PLRsbF2sD7JV... .

Waarschuwing: Veel sprekers leken niet voorbereid te zijn op 45 minuten spreektijd en raasden daarom door hun verhaal heen. Ik had de korte pauzes hard nodig om het te laten bezinken.

Dag 1

Diverse behulpzame Fransen hielpen me op weg met het metronetwerk, en ik arriveerde als eerste bij Espace Charenton. Het was goed te vinden, al was ik even bang de weg kwijt te zijn toen ik langs zelfbouw huisjes met golfplaten daken op een verlaten treinspoor liep. Bij de ingang werd mijn tas op verdachte voorwerpen doorzocht door security, maar daarna mocht ik de betrekkelijk kleine foyer in waar de mini croissants en hartige broodjes op mij wachtten naast de koffie en thee. Het werd gefaciliteerd door wat leek op werknemers van een lokale bakker, die trots vertelde over de typisch Franse broodjes. Een volwaardig ontbijt was het niet, maar het was gratis en lekker dus vooruit dan maar.

Introductie: Antonio Gonsalves, Java User Group Parijs

Als hoofdorganisator beet de sympathieke Antonio Gonsalves het spits af. Hij nam de aanwezigen door een stukje geschiedenis van gedistribueerde systemen: Corba, clusters, microservices... Zijn ontnuchterende boodschap: Gedistribueerde systemen waren altijd al ingewikkeld om over na te denken en onder controle te houden, en dat zal ondanks de op dit congres gepresenteerde technieken en verhalen zo blijven. Blijf scherp en kritisch, en maak je architectuur niet ingewikkelder dan nodig.

Keynote: Ken Finnigan, Red Hat

Het grote nieuws in de nacht voorafgaand aan het congres was de overname van Red Hat door IBM. Dit was zo goed onder de pet gehouden, dat sprekers als Ken Finnigan het tegelijk met de rest van de wereld hoorden en last minute nog een grap en een IBM logootje aan hun slides hadden toegevoegd. Ook Ken ging voor een reis door de tijd, waarbij hij begon met mainframes en een aantal zorgen van de eerste gedistribueerde systemen herhaalde voor de systemen van nu:

• Zorg voor netwerk latency monitoring; het is de 'silent killer' van gedistribueerde systemen.Zorg voor failure detection en retry logica.
• Zorg voor een lookup/service registry zodat systemen elkaar kunnen vinden, in plaats van tight coupling.
• Zorg voor caching om netwerkverkeer te minimaliseren.

Ken herhaalde Antonio's punt dat je je moet afvragen of je wel microservices moet gebruiken voordat je al deze zorgen uitnodigt in je project. Nog twee in het oog springende opmerkingen:

• Een systeem in "Quiescent State" is een systeem waarvan componenten en connecties gewijzigd kunnen worden zonder het in zijn geheel te hoeven stoppen. (Kramer & Magee)
• Wat Corba deed met IDL, doet Kubernetes met YAML.

Keynote: Bridget Kromhout, Microsoft

Ik had Bridget al eens eerder gezien op het DevOps Days congres in Amsterdam, eerder dit jaar. Een aantal opvallende punten:

• "Kubernetes is al 4 jaar oud en daarmee al bijna legacy." Confronterend voor mensen bij wijze van spreken nog met hun eerste vlieguren bezig zijn. Tegelijk een hart onder de riem voor mensen die het bij hun project of klant willen introduceren: het is inmiddels wel proven tech.
• "We replace our monolith with microservices so that outage could be more like a murder mystery." Ook hier weer een waarschuwing: gedistribueerde systemen zijn moeilijk te bouwen en nog moeilijker te troubleshooten.
• Microservices helpen om de "blast radius" te verkleinen van een fout. Los van de gave analogie is dit wat mij betreft een zeer belangrijk punt om in het achterhoofd te houden: als wijzigingen en fouten telkens meerdere microservices raken, doe je iets verkeerd en heb je onvoldoende profijt van je modulaire architectuur.
• Kennelijk is YAML de nieuwe incarnatie van het kwaad; Bridget is niet de enige die erop afgeeft. Helm is een tool die de scheepvaart naamgeving van Docker overneemt en middels Charts inzage biedt in Kubernetes services zodat je niet je YAML hoeft door te spitten om er wijs uit te kunnen.
• Brigade is een tool die je met Helm kunt gebruiken om met JavaScript event driven taken toe te voegen aan je Kubernetes cluster, om zo samen met Helm CI/CD pipelines voor containers in een Kubernetes cluster te kunnen bouwen.
• Kashti is een dashboard voor Brigade om de build pipelines inzichtelijk te maken - dit omdat Conway's Law ook geldt voor een Kubernetes cluster met services die door diverse teams worden onderhouden; zichtbaarheid van zowel de architectuur als de delivery pipeline is onontbeerlijk in de communicatie tussen teams, wat weer benodigd is om een effectief en efficiënt microservices landschap onder controle te houden.

Keynote: Susanne Kaiser

In haar keynote begon Susanne te vertellen over Thomas Thwaites' project om een toaster te bouwen uit zelfgemaakte onderdelen (http://www.thomasthwaites.com/the-toaster-project/ ) Deze analogie gebruikte ze om een punt te maken wat voor mij een key takeaway bleek: "Build the things that differentiate you and offload the things that don't". Dit borduurt logisch voort op iets wat me van Jez Humble is bijgebleven: zorg dat je in staat bent om jezelf te onderscheiden en te reageren op de markt, in plaats van al je energie te steken in het volledig implementeren van één idee.

Wat valt er te offloaden dan binnen de wereld van microservices? Aardig wat; eigenlijk alles wat niet business logic is. Maar daarvoor moet je eerst de principes en primitieven van het domein 'onloaden', w.w.z. eigen maken:

1. Zo zijn er alle CNCF infrastructure building blocks. Het is goed om op zijn minst de categorieën te kennen en op zijn minst 1 tool per categorie te kennen als referentiemateriaal.

2. Een microservice moet één doel dienen.

3. Een microservice moet zichtbaar (observable) zijn.

4. Een microservice moet zijn lifecycle kunnen laten beheren door het orchestration platform.

5. De image van een microservice moet het "build once, deploy many" principe volgen (goed voor de audit trail en voor het vermijden van snowflake servers)

6. Een microservice moet self-contained zijn: buildtime provisioned dependencies en runtime verschafte configuratie.

7. Een microservice moet disposable zijn middels externalized (of geen) state. (Shared mutable state wordt algemeen gezien als het grote kwaad)

8. Een microservice moet runtime confined zijn v.w.b. CPU, geheugen e.d.. Het moet m.a.w. niet kunnen gebeuren dat er "resource starvation" optreedt doordat een andere service de toegewezen resources claimt.

Nu zijn dit zaken waar Docker containers en Kubernetes bij helpen, maar er is meer dat geoffload kan worden dat geen business logic is: networking concerns. Denk aan load balancing, circuitbreaking, bulkheads, en service discovery: Dit wil je liever op het niveau van Kubernetes services geregeld hebben dan op het niveau van individuele containers/applicaties, en in ieder geval lost Kubernetes dat niet per se voor je op. Hiervoor is o.a. het service mesh van Istio voor bedacht.

Een logisch verlengde van het wegmanagen van je cognitive load is dat je nog meer buiten de business logica, vervat in functies, wegmanaget, is dat je alles behalve de inhoud van dergelijke functies laat managen door een daarvoor bestemd platform. M.a.w. serverless. Althans: het klinkt als een logische vervolgstap, maar zelf heb ik gemerkt dat een serverless architectuur niet eenvoudiger is te overzien, en dat niet alle problemen zich zomaar laten vertalen naar naar losse functions die kort bestaan. En voor een serverless architectuur heb je weer andere principes en primitieven te onloaden, waar Susanne helaas niet op in ging. Desalniettemin een verhaal wat voor mij cognitive load als belangrijke metric onder de aandacht heeft gebracht.

Hexagonal at scale with DDD and microservices, Cyrille Martraire, Arolla

Cyrille is één van velen die tegenwoordig begrip van Domain Driven Design en dan met name Bounded Contexts als onontbeerlijk ziet voor het correct opknippen van business logic om er microservices van te maken. Dat is echter makkelijker gezegd dan gedaan. Cyrille biedt daarom een helpende hand:

1. Verdeel je domein niet over layers: Web/Logic/DAO/DB.

2. Verdeel je domein niet per technologie: ESB / MongoDB / NodeJS.

3. Verdeel je domein niet per entiteit: User / Product / Aankoop.

4. Verdeel je domein op basis van het jargon dat door mensen in je customerfacing business units wordt gebruikt. Dit is slechts een indicatie, maar helpt je wel om te realiseren dat één fysieke entiteit meerdere manifestaties kan hebben. Zo is een ingelogde gebruiker van wie je een aflever adres wilt hebben in een checkout proces iets anders dan een klant die je servicedesk belt, en ook weer iets anders dan iemand die je catalogus aan het doorbladeren is om zich te oriënteren. Woorden die de verschillende business units dan zouden kunnen bezigen, zijn bijv. customer, account en recipient. Het is dus belangrijk om met je collega's naar synoniemen te zoeken voor entiteiten, om bounded contexts te kunnen ontwaren.

Na dit punt te hebben gemaakt, komen er nog wat veel voorkomenden indicatoren voorbij van bounded contexts:

1. Afdelingen van je organisatie (sales, support, logistiek, etc)

2. Verschillend gebruik van hetzelfde ding (een product in een winkelwagen vs een product in een zoekresultatenpagina vs een product in aankoophistorie)

3. Verschillende modellen van hetzelfde ding. Wees dus niet te snel met het verenigen van verschillende perspectieven op iets. Een consolidatie van al die perspectieven en meningen om één model te creëren (denk attributen van een object) kan in die zin meer kwaad dan goed doen.

4. Synoniemen voor hetzelfde ding, zoals hierboven genoemd. Het is hierbij belangrijk om verschillen in jargon te waarderen. Ik heb zelf wel vaker meegemaakt dat een afdeling andere afdelingen overtuigde om, om verwarring te voorkomen, te convergeren naar één naam voor een ding. Als gevolg bleek het ding onderhevig aan diverse meningen en veranderingen waardoor bloat optrad in de implementatie.

5. Werkwoorden die als zelfstandig naamwoord worden gebruikt (bijv. sales, search, support). Sowieso zijn search & reporting vrijwel altijd bounded contexts, aldus Cyrille.

6. Verschil in 'Tech Pressure' kan een indicator zijn van een Bounded Context. Dat wil zeggen dat als bijv. de ene verzameling requirements zich leent voor CQRS, maar een andere meer voor CRUD met een relationele database, je wellicht te maken hebt met 2 Bounded Contexts.

7. Een gezegde wat ik miste in Cyrille's verhaal maar wat ik wel vaker hoor en m.i. hier thuishoort, is "things that change together should be together".

Bij het zoeken naar dergelijke indicatoren kun je gebruik maken van Event Storming. Daar gaat Cyrille helaas niet op in. Wel waarschuwt hij dat een verdeling in bounded contexts tijd nodig heeft om stabiel en duidelijk te worden, en dat daarom de eerste stappen naar modularisatie liggen op het gebied van gescheiden packages en een streven om dependencies daartussen te vermijden. Aan het goede gebruik "DRY" (Don't repeat yourself) mag hierbij best gezondigd worden; duplicatie is immers misschien geen duplicatie net zoals synoniemen nog steeds verschillende woorden zijn.

Stop reinventing the wheel with Istio, Mete Atamel, Google

Mete neemt zijn publiek mee in een verhaal waar hij de centrale lijn van dit congres nog eens uiteenzet:

1. Docker ontzorgt door in isolatie te voorzien van je applicatie omgeving.

2. Kubernetes ontzorgt daarna doordat het voorziet in het managen van services/applicaties en niet machines/containers.

3. Istio ontzorgt vervolgens door het zorg draagt voor het verbinden, beveiligen, managen en monitoren van services, zodat je daar op applicatie (container of node) niveau niet telkens mee bezig hoeft te zijn.

Istio doet dit door het sidecar design pattern te gebruiken: iedere k8s pod bevat naast een applicatie ook een Envoy proxy, waar alle communicatie langs gaat. Istio faciliteert bovendien een control plane bestaande uit Pilot (discovery & config management), Citadel (certificering & identificatie) en Mixer (telemetry & connectivity policies). Dit alles tezamen (al zijn de onderdelen ook los te gebruiken) stelt Istio in staat om shared concerns tussen k8s pods weg te managen, zodat je je energie kunt steken in unieke applicatie (business) logica. De Envoy proxy komt overigens van Lift en heeft een verwaarloosbare impact netwerk latency.

Voorbeelden van zaken die Istio op k8s service niveau faciliteert zodat je er niet op lager niveau (applicatie, container, pod) over na hoeft te denken:

- Traffic management, circuit breaking, A/B testen, Canary releasen.

- Fault injection: introduceer willekeurige vertragingen, errors en outages in je service. Een soort virtuele Chaos Monkey dus.

Microservices & SPA's, Manfred Steyer, softwarearchitekt.at

Hoe kun je een SPA modulariseren? Voor iemand die uit de MVC/JSP/progressive enhancement wereld komt als ik, is het soms frustrerend om te zien hoe de Angular crowd kampt met problemen die ik al eerder opgelost heb zien worden. Maar deze spreker weet op komische wijze uiteen te zetten hoe je een afweging kunt maken tussen de voordelen van een SPA (uniformiteit in UI, shared/small dependencies, shared state zonder server request) en de voordelen van modulariteit (deployability, changeability).

Habitat, Romain Sertelon

Chef heeft Habitat geïntroduceerd. Dit is een meer developer-first benadering van DevOps, waar je niet vanuit infrastructure as code kijkt hoe je de landingsbaan voor een applicatie kunt wegautomatiseren, maar juist hoe je het bouwen en verpakken van de applicatie kunt aanvliegen om het op enig welk platform uit te rollen. Het bouwen van een applicatie met Habitat leidt tot een artifact dat alles bevat om op een doel platform te kunnen draaien. Het concept leek analoog aan het bouwen van fat jars die zelf een servlet container bevatten in plaats van een WAR te bouwen die je in een Tomcat moet plaatsen.

Not born in the cloud: From a legacy monolith to a scalable SaaS application, Melanie Rao & Rachel Orti, IBM

Dit verhaal is een reisverslag van de ontdekkingsreis die de sprekers hebben gemaakt van Java development via Docker, Kubernetes en Helm naar cloud native. Hier enkele constateringen en valkuilen:

• Begin met de juiste mensen. Niet iedere developer omarmt DevOps; niet iedere developer wil werken met containers en infrastructuur.
• Gebruik officiële base images; ga niet alles from scratch bouwen.
• Gebruik niet "latest" versies. Ken de versie die je kiest en wees bewust van wat je binnenhaalt met nieuwe versies.
• Maak backups van gebruikte publieke images naar een interne registry; neem niet aan dat iedere versie en iedere tag van de door jouw gebruikte publieke image zal blijven bestaan.
• Controleer dat Java weet dat het in een Docker container draait. Versies van Java jonger dan 8u131 negeren bijv. limieten die door Docker worden opgegeven.
• Kubernetes zorgt dat de orkestratie (managen/scalen) van containers via pods in services gebeurt, maar als containers van elkaar afhankelijk zijn, moet je dat nog steeds expliciet regelen, omdat k8s pods in willekeurige volgorde opstart.
• Vertrouw op k8s voor high availability, maar daarvoor moet je wel expliciet endpoints exposen.
• Plan vooruit welke configuratie aspecten je gaat willen kunnen configureren, want het is moeilijk om dat later alsnog te doen.
• Alhoewel Helm syntax een leercurve heeft, bieden Helm charts meer logica (if-then, for loops, config placeholders) om k8s YAML minder bewerkelijk te maken. Gebruik Helm om deployment van je k8s applicaties te managemen.
• Gebruik de services van je cloud platform zoveel mogelijk: logging, tracing, alerting, metering, authentication, etc. Pas je product desnoods aan om dit mogelijk te maken. Gebruik Istio om je applicatie nog verder te ontkoppelen van de Cloud vendor implementatie.

Dag 2

Serverless on Google Cloud Platform, Guillaume Laforge

Guillaume Laforge, bekend van zijn werk voor Groovy en Grails, bespreekt een aantal zaken op het gebied van compute & serverless in GCP. Het grote nieuws is Knative, wat een soort wrapper rond een Docker container is zodat het zich kan gedragen als een GCP serverless container. Knative kan als building block op Kubernetes en dus GKE worden gebruikt, om een serverless platform te bieden voor developers. Ook Pivotal Rift en IBM OpenWhisk ondersteunen het.

Guillaume demonstreert een serverless applicatie van pic-a-daily.appspot.com en laat Stackdriver zien, waarmee debug logging aan live productie code in functions kan worden toegevoegd; zelfs Java functions.

Integrating microservices by accepting the data dichotomy, Damien Gasparina

Bij het opknippen van een applicatie in microservices neem je loose coupling in overweging zodat ze onafhankelijk van elkaar kunnen wijzigen. Deze onafhankelijkheid heeft een prijs: de data die applicaties vanuit business perspectief met elkaar delen zitten vaak in een database, en databases zijn traditioneel slecht in encapsulation: Service interfaces hebben als doel interne data te verbergen, en database interfaces hebben als doel interne data te ontsluiten. De regel binnen microservices is dan ook algemeen: Microservices moeten geen shared mutable state delen, en daarom ook geen database.

Een vaak genoemde oplossing voor dit probleem is om de data te dupliceren tussen services. Maar, zoals Damien uitlegt, leidt dit al snel tot data integrity problemen en een verspreide, ambigue versie van je data (divergence).

Damien zegt daarom: Keer de database binnenstebuiten: Deel niet de data, maar de gedeelde - immutable - transaction log van de database. Dit is een manier om event driven architecture op database niveau toe te passen: een transaction log is een log van events. Doordat afnemende services zich abonneren op event broadcasts in plaats van zelf requests te sturen naar de database, faciliteer je loose coupling. Op deze manier is de event broadcast service degene die bepaalt hoe data aangeboden wordt.

Damien raadt af hiervoor een Message Queue oplossing te kiezen, omdat de data dan overgankelijk is en de afnemende services dan uiteindelijk toch weer een verspreide en mogelijk tegenstrijdige waarheid vertellen met hun data. In plaats daarvan prijst Damien Kafka Streams aan: Het is scalable, fault tolerant, concurrent, strongly ordered, en bovenal retentive. Door Kafka als centrale bron - een 'golden copy' - te hanteren van de waarheid, introduceer je niet een share mutable state, maar een immutable event log, terwijl query processing een gedecentraliseerde taak is van de afzonderlijke services die de data nodig hebben.

Microservices lessons learned, Susanne Kaiser

Het verhaal van Damien Gasparina heeft een aardige overlap met dat van Susanne Kaiser. Ze noemt 2 strategieën om een monoliet op te knippen in losse services:

1. Clean cut op basis van bounded contexts:

• Identificeer bounded contexts in de business logic .
• Bouw een service from scratch die naast de monoliet zal bestaan, en omring die service met een REST API en een database adapter.
• Vermijd het requesten van data uit de monoliet (zowel naar diens database, of via diens API). Introduceer een event bus waar de monoliet events naartoe stuurt. De nieuwe service abonneert zich hierop middels een adapter.

2. Incremental top down.

• Maak een extra web applicatie die de UI voor zijn rekening neemt in plaats van de monoliet.
• Extraheer business logic uit de monoliet naar nieuwe applicaties. Deze nieuwe applicaties praten nog steeds tegen de oude data laag.
• Splits de data laag zoals in strategie 1 via een event bus.

Let op dat deze strategie dus niet een voorbeeld van DDD bounded contexts is, zoals we de dag hiervoor leerden van Cyrille Martraire.

Bij beide strategieën zijn er zgn. crosscutting concerns waar een oplossing gevonden moet worden, zoals authenticatie. Susanne waarschuwt dat hier z.s.m. een aparte collaboration service voor moet komen die een stabiel contract voor dergelijke shared concerns implementeert, om te vermijden dat teams toch verder gaan bouwen in de monoliet, of het in iedere afzonderlijke service gaan herbouwen. Het risico van een gedistribueerde monoliet ligt op de loer: je hebt nog steeds wijzigende delen die van elkaar afhankelijk zijn, maar nu zijn ze gedistribueerd.

Voor het implementeren van de event bus heeft Susanne nog tips:

• Gebruik Kafka, door middels KStreams en KTables materialized views van data per service te maken.
• Neem de boodschap uit haar keynote in overweging: bouw de dingen waarmee je unieke waarde kunt leveren; laat dingen die iedereen met elkaar gemeen heeft elders centraal regelen. Vrij vertaald: bouw geen message broker met bijbehorende infrastructuur. Gebruik building blocks van je cloud provider.

Istio Platform vs Spring and MicroProfile frameworks, Kate Stanley

Zoals door eerdere sprekers al aangegeven, kun je met het service mesh van Istio zaken op een overkoepelend niveau afhandelen waar je dat anders met Docker en Kubernetes nog per applicatie of container zou moeten doen. Kate Stanley zet een aantal oplossingen van Istio tegenover die van Spring en MicroProfile. Weet je applicatie voldoende om een besluit te maken over iets? Zet dan een framework als Spring of MicroProfile in. Zo niet, zet dan een platform oplossing als Istio in. Je kunt het combineren, maar wees dan bewust van de overlap in functionaliteit.

Voorbeeld: Service discovery

* Een service registry houdt een lijst van geregistreerde services bij, die een client kan raadplegen om services te vinden die hij vervolgens kan aanroepen.

* Het Spring Cloud Kubernetes project toont een manier om k8s en Istio te combineren met Zipkin en Ribbon.

Voorbeeld: Fault tolerance

• Netflix Hystrix is een bekende manier om op applicatieniveau circuit breaking toe te passen zodat een trage service niet doorwerkt in je hele service landschap.
• Middels MicroProfile Fault Tolerance is dit per applicatie in te stellen.
• Bij Istio is fault tolerance ingebouwd in je infrastructuur; er is vrijwel geen code voor nodig in je applicaties, wat weer in lijn is met het offloaden van zaken die je applicatie niet onderscheiden van andere. Een bijkomend voordeel is dat je met Istio zelfs fouten kunt injecteren (design for failure).

Hystrix combineren met Istio is af te raden; applicaties en services zullen op elkaars circuitbreaking / retry policy afgaan. Je moet er dus één kiezen. En ongeacht de keuze moet je applicatie natuurlijk weten hoe het om moet gaan wanneer het circuit daadwerkelijk gebroken is.

Voorbeeld: Security: Who are you, do I trust you, has anything changed during this request?

• Op framework niveau heb je Spring Security en MicroProfile JWT authentication. De code hiervoor bouw je in je applicatie.
• Istio biedt zaken als mutual TLS en interservice encryption. Het is hierbij service-centric; het ziet alleen wat er binnen het service landschap van Istio leeft.

Frameworks helpen in deze met "wie ben je" en "is er iets veranderd", terwijl Istio helpt met "vertrouw ik je". Dit is goed te combineren. Dan nog zul je ook moeten overwegen dat autorisatie over het algemeen dicht bij de service geregeld moet zitten, terwijl authenticatie liefst zo vroeg mogelijk aan de poort gebeurt.

Voorbeeld: Tracing, logging & metrics

• Framework: Spring Actuator; MicroProfile Health Check, Metrics en Open Tracing.
• Istio: Service graph.

Gecombineerd ziet Istio welke services elkaar aanroepen en hoe een request door het hele systeem loopt, inclusief response times. Omdat Istio niet in een applicatie kan kijken, kun je vanuit je applicatie logging naar een centraal systeem sturen, zoals Prometheus & Grafana.

Find and track the hidden vulnerabilities inside dependencies, Julien Topcu , OWASP

Julien vertelde over hoe je CVE's (Common Vulnerability Exposure) kunt vinden in de National Vulnerability Database (NVD). Ze zijn daarin gescoord volgens het CVSS (Common Vulnerability Scoring System) (0-10; 10 = highest).

OWASP biedt tools om te kijken of je code/applicatie geraakt wordt door deze CVE's.

1. DependencyTrack loopt dependencies van je code na, kijkt in NVD en rapporteert gevonden bekende vulnerabilities. Het merkt ook op of je gedateerde versies van dependencies gebruikt.

2. DependencyCheck is een Jenkins plugin die je met Dependency Track kunt gebruiken, en die bevindingen naar SonarQube stuurt, al kun je met SonarQube minder dan met de Dependency Track UI. DependencyCheck leest je dependencies van je Maven pom.xml.

Micronaut, Graeme Rocher

Graeme Rocher is bekend als de man achter Grails. Maar Grails, net als JakartaEE en Spring, waren nooit gebouwd voor de wereld van microservices. Micronaut wel. Micronaut heeft ondersteuning voor de JVM talen en probeert de features van Spring, Grails en MicroProfile met de memory footprint en snelle startup tijden van Vertx en Ratpack. Het gebruikt hiertoe ahead of time compilation. Het heeft de mosterd gehaald bij Google Dagger (compile time dependency injection; geen reflection) en Android (AOT compilatie; laag geheugengebruik).

Ik verwijs graag naar de diverse JDriven blogs voor verdere toelichting op Micronaut, eventueel in combinatie met GraalVM.