Oude wetten in nieuwe omgevingen

vrijdag 17 april 2015

Ik beloofde het in mijn eerste blog al: soms schrijf ik over de klus zelf en soms over de technologie die we daarbij inzetten. Want trends in die techniek zijn zowel nuttig leesvoer als ook voorbeelden van het nut dat je als Bruneller een klant kan bezorgen, toch?

Inzicht

Ik ben inmiddels een nieuw project gestart, maar werk in een vergelijkbare technische beheeromgeving als twee maanden terug. Dit keer echter binnen de financiële dienstverlening. Ik help daar een UDDI ‘service registry’ platform verder uit te bouwen dat zelf weer bovenop een J2EE server draait. Een collega die vroeger veel geprogrammeerd heeft en nu net als ik veel als architect werkt (en om bij te blijven een intensieve Java-cursus gevolgd heeft) zuchtte onlangs bij de koffie: “Het is allemaal veel krachtiger dan de klassieke programmeerstacks, maar het woord ‘gestructureerd’ uit onze opleiding mis ik toch wel erg”.

Containers en complexiteit

En daarmee sloeg hij een mooie spijker op de kop. Twee voorbeelden uit de praktijk waar ik zowel hele mooie vergezichten zie, als een nogal bochtige weg om die horizon te bereiken. Ten eerste Docker, een nieuwe speler in het Linux-wereldje. Het biedt ‘containers’ (oftewel een virtualisatielaag) die veel dunner en flexibeler is dan VM’s zoals VMware. In de RISC Unix-wereld kennen we het concept al een jaar of 20 met onder andere de AIX WPAR’s en Solaris Containers. Het biedt fraaie mogelijkheden zoals het binnen enkele seconden booten van een nieuwe container en het in één keer voor alle containers activeren van een Linux-patch, maar tegelijkertijd ook een zeer complexe set afhankelijkheden. Je kunt bijvoorbeeld zo een JEE-applicatie als VM met eigen Linux distribueren naar drie aparte hypervisoren, maar diezelfde JEE-applicatie in een Docker-container is toch echt hard gelinkt aan de onderliggende Linux-distributie en al diens settings. Tools zoals Red Hat Atomic claimen dat op te lossen maar opnieuw binnen strakke grenzen. Zowel bij mijn vorige project als bij mijn huidige wordt er geëxperimenteerd met Docker. Maar het is een beestje dat erg strakke architectuur en gedisciplineerde keuzen eist; net als ‘layered’ virtualisatie op andere omgevingen zoals voor Windows het destijds revolutionaire Symantec Workspace Virtualisation.

JEE spagaat

Het tweede voorbeeld is gewoon de applicatieserverstack, zoals WebSphere en JBoss. Alleen al de documentatie, waar ik onlangs veel in snuffelde vanwege hardnekkige serverproblemen, barst letterlijk van de tegenstrijdigheden. Bijvoorbeeld zaken die volgens methodes X, Y en Z kunnen worden opgelost maar in een plugin-manual wordt dan weer niet uitgelegd dat deze plugin uitsluitend voor optie Y-1 goed werkt. En een hele strijd tussen de stam die de applicatieserver zélf het webverkeer inclusief SSL-terminatie laat afhandelen en de stam die er altijd een Apache http-server voor plaatst. Maar de installatietools zijn minstens even erg: er leiden minstens 4 wegen naar een bepaald doel en de configuratiesettings op elke plaats kunnen elkaar tegenspreken terwijl je niet à priori weet welke leidend zal zijn. Daarbovenop dan een standaardpakket met zijn interne regels. Je kunt soms niet anders dan verstrikt raken tussen de werkstijlen en dictaten van de JEE-bouwer en de pakketbouwer.

Terug naar de basis

De oplossing voor beide werkvelden is die aloude mantra: structuur. Ook in deze complexe stacks bepaal je als team wat je samen wilt bereiken en maak je heldere keuzen om één tool en één bepaalde werkwijze voor één deel van die weg in te zetten. Liflafjes, extraatjes, mooie trucs mogen allemaal in eigen tijd maar niet in de stack van de baas! Vaak moeten er ontwikkel- of beheerframeworks gekozen worden en wederom is het devies om die keuze daarna te volgen en alle verleidingen van zijwegen te weerstaan. Als je dít soort principes herkent en je deze kunt uitdragen naar je klant, dan kunnen klanten dat zeker waarderen en open je als Bruneller vele deuren...