News

Soundbyte 112: Are we there yet?

22 september 2013

De afgelopen weken hebben in het teken gestaan van migraties. Ruim 1.5 jaar hebben we gewerkt aan een remake van het huidige systeem van één van onze klanten en nu is het tijd om alle gebruikers van het 1.0 systeem te migreren naar het nieuwe 2.0 systeem. Het is geweldig om te zien hoe het systeem zich gedraagt in de ‘echte’ wereld; al helemaal als je hoort dat de gemigreerde gebruikers zeer tevreden zijn over het nieuwe systeem en al zijn nieuwe features.

Het nieuwe systeem is geen 1:1 remake van het huidige systeem. Naast de grote hoeveelheid nieuwe functionaliteit is er ook gekozen voor een compleet nieuwe architectuur gebaseerd op Java EE en OSGi. De applicatie heeft een groot aantal migraties met service providers, waarvan de specifieke implementatie achter een OSGi interface is geabstraheerd. De OSGi keuze heeft hierbij al zijn vruchten afgeworpen. Tijdens het ontwikkel-traject hebben we van alle service providers gebruik gemaakt van hun specifieke OT&E (test) omgevingen. Nu we gebruik gaan maken van hun productie omgevingen, blijken er toch wel veel verschillen te zitten in de specifieke functions en features tussen hun OT&E en de productieomgevingen. Dit betekent dat we af en toe aanpassingen moeten doen aan de implementaties, maar door gebruik te maken van een door een OSGi interface geabstraheerde implementatie voor die specifieke service provider, hoeven we ook alleen die specifieke OSGi bundle te deployen en hoeven we niet het gehele systeem onderuit te halen en te upgraden met de bijbehorende downtime tot gevolg.

Het afzonderlijk deployen van OSGi bundles is enkel mogelijk zolang er geen interfaces veranderen. Dit is echter niet altijd mogelijk. Soms moeten er interfaces worden aangepast of moet de (niet OSGi, maar puur Java EE gebaseerde) hoofdapplicatie worden aangepast. Daarom wordt er elke week, voorafgaand aan de migratie van een nieuwe batch gebruikers, een compleet nieuwe versie uitgerolt. Natuurlijk wordt deze eerste getest op de lokale test en acceptatie omgevingen, alvorens deze versie op de productie omgeving wordt geïnstalleerd.

En dan is het een kwestie van monitoren. Daarvoor is het van belang geweest om goede logging te genereren. Hierbij hebben we onderscheid gemaakt tussen een soort ‘eerste lijns’- en een ‘tweede lijns’-logging:

  • De ‘eerste lijns‘-logging (ELL) bestaat uit het loggen van alle communicatie tussen de applicatie, de service providers en de gebruikers van het systeem, het loggen van alle status overgangen van de business processen binnen het systeem en het loggen van alle financiële acties. De ELL is in principe bedoeld voor het, niet technische, support team, zodat zij fouten kunnen detecteren en eventueel zelf kunnen herstellen. Daarnaast dient deze logging ook als bewijs tijdens geschillen tussen de klant, de gebruikers en/of de service providers.Maar het belangrijkste doel van ELL is het ontlasten van het ontwikkelteam. Daarvoor is het van belang geweest dat de logging zodanig wordt opgeslagen, dat er verschillende kruisverbanden konden worden gelegd tijdens het analyse proces door support. De logging wordt daarom opgeslagen in een relationele database en is er een krachtige userinterface ontworpen, waarmee ook eenvoudig verbanden kunnen worden gelegd tussen de verschillende log statements. Naast het detecteren van foutieve situaties is er ook voor gezorgd, dat er voldoende middelen tot de beschikking staan voor het daadwerkelijk oplossing van eventuele foutieve situaties en het herstellen van bijvoorbeeld foutieve afboekingen.
  • De ‘tweede lijns‘-logging (TLL) bestaat uit de log files, die elke ontwikkelaar wel kent: de Log4J tekst bestanden. Hierin staat veel meer informatie dan in de ELL. TLL is van cruciaal belang voor het oplossen van fouten, die niet zomaar door het support team kunnen worden opgelost, maar waarbij ondersteuning van het ontwikkelteam is gewenst. Door de analyse uit de ELL, kan er vrij specifiek in de TLL worden gezocht. In de TLL staan bijvoorbeeld de uitgebreide stacktraces en de INFO log regels die door de ontwikkelaars in de code zijn geplaatst.Ontwikkelaars hebben ook uitgebreidere mogelijkheden tot het oplossen en herstellen van foutieve situaties. Zij kunnen namelijk overal bij: ook bij de interne interfaces en functionaliteit van het systeem, die niet zijn ontsloten via de ELL userinterface (meestal vanwege het feit dat het gebruik van deze interfaces een zeer gedegen kennis van de interne processen vereist en dus niet door een ieder mag worden gebruikt).

Over een aantal weken hopen we de laatste gebruiker te hebben gemigreerd. Tot die tijd blijven we monitoren en blijven we het systeem verbeteren, maar worden er ook steeds meer mogelijkheden toegevoegd aan de lijst van tools die support kan en mag gebruiken voor het herstellen van foutieve situaties. Uiteindelijk moet het systeem volledig onderhouden kunnen worden door het support team en kan het ontwikkel team verder gaan met de volgende major release.

Maar wat moet er nu voor stukje muziek bij dit verhaal. Ik wist het niet. Maar omdat het bovengenoemde systeem vol zit met verbindingen met externe partijen, heb ik wederom gekozen voor een liedje van de ‘Playing for Change‘ foundation, die als doel heeft het verbinden van iedereen op de wereld door middel van muziek. Ik had al in een vroegere soundbyte een liedje gekozen van de stichting gekozen (zie Soundbyte 49 ‘Open World’), maar ook deze is uniek.

Enjoy…

 

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *