Bij Blis Digital houden we wel van een uitdaging. Maar recent namen we een project over van een andere softwarepartij waar we toch even van moesten slikken. Wat begon als een standaardopdracht veranderde in een complexe migratie en dreigde een serieus hoofdpijnproject te worden. Open communicatie, een resultaatgerichte houding en een klant die ons zijn volle vertrouwen gaf maakten van dit project alsnog een succesverhaal.
Een klant kwam bij ons met de vraag om 3 mission-critical applicaties door te ontwikkelen. Voor ons is dat min of meer de standaardopdracht, dus we gingen enthousiast aan het werk. Maar al gauw bleek dat er meer aan de hand was…
De uitdaging wordt duidelijk
De applicaties waar het om ging kwamen van een andere partij en waren opgebouwd met verouderde technologie, zonder enige documentatie.
De software draaide weliswaar in de (Google) cloud, maar was daar niet op een moderne stack gebouwd. De stack was daarnaast, zeker voor apps met een redelijk overzichtelijke functionaliteit, erg complex en combineerde .NET, React, Blazor en 3 databases in PostGres en MySQL. We konden alleen toegang krijgen via een SSH-verbinding (voor de niet-ingewijden: dat betekende dat we alle handelingen typend moesten doen in een tekstinterface zoals je die ziet in films uit de jaren 90).
Logs waren er nauwelijks, alerts voor downtime al helemaal niet. Als er een app uit lag (en dat gebeurde nogal eens), hoorden we dat dus pas als de klant ons belde. Het uitrollen van een hotfix of een nieuwe feature kostte, door de tergend langzame OTAP-straat, tussen de 2 en 3 uur.
In theorie hadden we deze apps dus verder kunnen ontwikkelen. We hadden onze tijd kunnen investeren in uitzoeken hoe het technisch allemaal in elkaar zat. We hadden ons kunnen gaan zitten opvreten achter onze SSH-terminals, wachtend op witte rook over onze deployment. Maar daar hadden we dus geen zin in. Want zelfs met die tijdsinvestering zou dit nooit een onderhoudbare, future-proof app worden. En uiteindelijk zouden we, na jaren van frustratie, de klant toch hebben aangeraden om de zaak naar een beter platform te migreren.
Het was dus beter om meteen door de zure appel heen te bijten.
Het besluit: we gaan naar Azure
Stel, je schakelt een technologiepartner in om je applicaties door te ontwikkelen. Je hebt een van de beste gekozen, dus je denkt: “Dat komt goed.” En dan komen ze na een paar weken bij je om te melden dat ze er niet aan gaan beginnen. Of tenminste, dat ze je software eerst gedeeltelijk willen vernieuwen en naar Azure willen verplaatsen. Dan ben je even niet zo blij. De gedachte “waarom zou ik een applicatie ombouwen die het gewoon doet?” zou zomaar bij je op kunnen komen. En dat zouden we je niet kwalijk nemen.
Dit is precies hoe het in dit geval ging. Maar ons advies om de applicaties eerst te moderniseren en over te zetten naar Azure was gebaseerd op een grondige analyse. Daardoor wisten we de klant te overtuigen deze stap toch te zetten.
Hoe we te werk gingen
Binnen Blis Digital hebben we veel ervaring met dit soort trajecten (lees dit blog van Christian om er meer over te leren). We wisten dus goed hoe we het aan moesten pakken. Tegelijkertijd weet je nooit precies wat je gaat tegenkomen. Reden te meer om het systematisch aan te pakken:
- Updaten. Een cruciaal inzicht dat we al in het begin hadden opgedaan, was dat heel veel gebruikte packages een update nodig hadden. Meestal moest ook de code die de packages aanriep aangepast worden.
- Azure subscriptions en resources aanmaken. We bouwden de nodige infrastructuur op Azure op en zorgden dat alles goed geconfigureerd was voor de migratie. Een groot voordeel dat we hadden, was dat de originele applicaties al Active Directory gebruikten voor het inloggen. Die hele configuratie konden we dus hergebruiken.
- Databases samenvoegen en deployen. Nu konden we de applicaties gaan overzetten, maar de data zaten in verschillende databases. We migreerden die allemaal naar één SQL Server-database, waarbij we scripts gebruikten om de data op te schonen en te checken of alle data correct en compleet waren. Tijdens deze stap ontdekten we dat in de originele databases veel corrupte data stond. Het was veel werk om dat allemaal op te sporen en recht te zetten, maar de datakwaliteit nam hierdoor sterk toe. Dat zou later de gebruikerservaring enorm verbeteren.
- Testen, testen, testen, testen… Nu waren we klaar om de applicaties op Azure op te starten, maar toen we dat deden vonden we veel bugs. Gedeeltelijk werden die veroorzaakt door (nog meer) corrupte data, maar er waren ook veel aanpassingen in de code nodig. Opvallend, want de code zag er op het eerste gezicht goed uit. Pas toen we de hele applicatie in samenhang testten, kwamen de fouten boven. Dit was dus veruit de meest tijdrovende fase van het project.
- Dry run op productie. Terwijl we de uiteindelijke productie-omgeving testten, lieten we de gebruikers doorwerken op de originele apps. Zo konden we de tijd nemen om te zorgen dat alles perfect was, zonder processen te verstoren.
- Succes! De uiteindelijke overstap naar de nieuwe productieomgeving verliep soepel. Dankzij de gedetailleerde voorbereiding en tests konden we de overstap maken zonder dat de gebruikers er veel van merkten. Een bijzonder moment, als je – toch wel met wat spanning in je lijf – de ‘knop’ omzet en wacht op de telefoontjes van de gebruikers… En die kwamen niet. Iedereen werkte op de nieuwe omgeving en constateerde: “Het werkt sneller en stabieler. En de data kloppen eindelijk.”
Een succes om trots op te zijn. Maar de eerlijkheid gebiedt te zeggen: de livegang was eigenlijk de enige stap van het project die meeviel. In bijna alle andere stappen kwamen we onverwachte problemen en vertraging tegen.
Het is een groot compliment aan de klant waard, dat hij ons steeds het vertrouwen heeft gegeven om verder te gaan met het project. Als beloning heeft de klant nu een modern, schaalbaar en snel softwareplatform dat klaar is voor nieuwe functionaliteiten en toekomstige ontwikkelingen.
Hadden we het anders moeten aanpakken?
Een vraag die mij al die tijd heeft beziggehouden – en die me nog steeds bezighoudt – is: hadden we dit niet eerder kunnen zien aankomen? Hadden we niet, helemaal aan het begin, een Technical Due Diligence moeten doen om alle risico’s vooraf in kaart te hebben?
Het antwoord op deze vraag is ‘ja en nee’. Natuurlijk, het zou geweldig zijn om voortaan altijd te weten wat je gaat tegenkomen bij een development-klus. Dat zou de planning, de offerte en het gesprek met de klant veel makkelijker maken. Aan de andere kant kost zo’n analyse ook veel geld en tijd, wat betekent dat je altijd later en met minder budget aan het echte oplossen van de problemen begint.
En problemen oplossen, daar gaat het ons als developers om. Dat we vooraf niet precies weten hoe, dat maakt gek genoeg weinig uit. We zijn gewend om creatieve oplossingen te bedenken en we werken altijd in open, eerlijke communicatie met onze klant. En onze klanten snappen ook dat er grenzen zitten aan de voorspelbaarheid van softwareprojecten.
Ook moest ik denken aan wat Christian op dit blog eerder schreef: Software is net als een levende tuin. Het is een complex systeem dat niet alleen uit code en infrastructuur bestaat, maar ook uit mensen. Door diep in deze software te duiken hebben we een diep begrip gekregen van hoe hij werkt en hoe we hem in de toekomst moeten onderhouden en verbeteren.
Resulteerde dat erin dat we meer uren maakten op het project dan gepland? Ja. Leidde intern en extern af en toe tot pittige discussies? Zeker. Maar nu hebben we een vertrouwensband en een samenwerking opgebouwd met de klant die, samen met de nieuwe technische basis, zorgen dat we samen de toekomst in kunnen.
