Legacy solution klaarmaken voor een microservice aanpak

Soms krijg je in je opdracht te maken met grote solutions en een slechte scheiding van verantwoordelijkheden. Grote solutions met veel legacy code zorgen vaak voor lange buildtijden en door de slechte scheiding van verantwoordelijkheden kan een wijziging onvoorspelbaar gedrag veroorzaken. Beide leiden veelal tot inefficiëntie in het ontwikkelproces.

Hier liep ik ook tegenaan in mijn recent afgesloten opdracht bij een grote overheidsinstelling. Om onze productiviteit te verhogen en de software betrouwbaarder en onderhoudbaarder te maken, hebben we gekozen voor een aanpak gebruikmakend van NuGet, een package manager voor .NET.

Inzet van NuGet

We zijn gestart vanuit de buitenkant door het identificeren van de projecten die veel gebruikt worden en die geen gebruik mogen maken van code in andere projecten. Denk hierbij aan bijvoorbeeld een Common assembly, entities en data access.
Wijzigingen in deze projecten kosten vaak veel buildtijd omdat de hele solution opnieuw gebuild moet worden. Hierbij kun je erachter komen dat de scheiding van verantwoordelijkheden niet klopt, wat eerst opgelost moet worden om succesvol een package te kunnen maken.

Nadelen NuGet

Naarmate het aantal NuGet packages groeit komen er ook enkele nadelen bovendrijven. Zodra de NuGet packages onderlinge afhankelijkheden krijgen is het nodig om een boomstructuur van packages te updaten. Hierbij moet je goed opletten in welke volgorde je update en moet je veel handmatige administratie verrichten om de packages op elkaar aan te sluiten.

Om deze problemen te verlichten hebben we twee stappen genomen:

1. Samenvoegen van packages.
Sommige assemblies zijn dusdanig met elkaar verwant, dat het geen zin heeft om deze in een eigen package te plaatsen. Door meerdere assemblies in een enkele package te plaatsen maak je de boomstructuur kleiner.

2. Gebruik PowerShell om de package update uit te voeren.
Met PowerShell kun je de versie-informatie uitlezen en updaten. Dit kun je als een buildstap opnemen in je pipeline om versie-inconsistentie te voorkomen.

Voor nieuwe projecten zijn we gebruik gaan maken van microservices. Het plan is om de bestaande software op dezelfde manier van services te voorzien.

Inzet microservices

De eerste stap is het identificeren van functioneel gescheiden gebieden. Hierbij loop je vaak tegen de scheiding van verantwoordelijkheden aan. Verplaats de klassen en entities die enkel binnen de verantwoordelijkheid van deze service passen en scherm deze af.
Maak de benodigde functies beschikbaar via een interface en implementeer deze interface waar voorheen aanroepen gedaan werden naar de klassen. Mocht het nodig zijn om dataopslag te doen binnen je microservice, zorg er dan voor dat er een rollback beschikbaar is om transactionele integriteit te garanderen.

Klik hier voor meer informatie over de .NET-dienstverlening van inSystems.