Het updaten van of migreren naar een ander framework, waarom en hoe?

Home / Blog / Applicatiebeheer / Het updaten van of migreren naar een ander framework, waarom en hoe?

Tot het begin van 2020 was het Model-View-ViewModel (MVVM) PHP Framework; “Zend Framework” een project dat werd onderhouden door een stuurgroep bestaande uit Zend Technologies en Rogue Wave Software. Vanaf 2020 wordt Zend Framework 3 dan ook niet meer geüpdatet. Nieuwe ontwikkelingen aan het framework worden nu geleid door een onafhankelijke bestuurscommissie en het project is hernoemd naar Laminas. Dit hoeft niet meteen een ramp voor legacy software te zijn, echter ontbreken hierdoor al snel nieuwe security updates aan je software. Er wordt dan toch vaak voor gekozen om zo snel mogelijk te updaten, of zelfs over te stappen naar een ander framework. 

Senet heeft in de afgelopen maanden een legacy applicatie geüpdatet van Zend Framework 2 naar een containerised Laminas applicatie. Maar waarom is het wenselijk om het framework van een applicatie te updaten? Zitten daar ook haken en ogen aan? En hoe hebben wij deze migratie gerealiseerd?

De voordelen

Het grootste voordeel bij het updaten van een framework is natuurlijk dat je up-to date blijft met huidige ontwikkelingen en technieken. Openstaande issues worden opgelost en gewenste features kunnen worden toegevoegd, terwijl de oudere versie niet meer onderhouden wordt. Daarnaast biedt een up-to-date framework ook de mogelijkheid om nieuwere versies van de programmeertaal te ondersteunen. Deze nieuwere versies van de taal kunnen net als updates aan een framework zowel kritieke beveiligingslekken oplossen, als nieuwe mogelijkheden bieden voor technische implementaties. 

Tevens zorg je ervoor dat de applicatie compatibel blijft met nieuwere versies van de verschillende libraries (andere open source software elementen) waar de applicatie gebruik van maakt. Echter, niet alleen libraries kunnen ondersteuning voor oude frameworks laten vallen na bepaalde tijd. Ook operating systems, programmeertalen en database systemen kunnen in een dergelijke migratie worden geüpdatet naar nieuwere, snellere en vaak veiligere versies. 

Het implementeren van een nieuw framework (of nieuwere versie van een framework) kan de mogelijkheid bieden kennis te maken  met nieuwe technieken en design patterns die de onderhoudbaarheid van de code verbeteren. 

Verder biedt het ook een kans om de bestaande code van een legacy applicatie nog eens kritisch te bekijken. Anti-patterns in de oude software kunnen worden opgelost, en dode (ongebruikte) code kan worden opgeschoond. Zo bevatte de oude versie van onze applicatie een anti-pattern waarin de Servicemanager direct geïnjecteerd werd in een klasse, om vervolgens alle dependencies daar op te halen. Na de migratie is het zo dat de benodigde services worden gekoppeld middels een Factory en de servicemanager niet meer nodig is op dezelfde plek waar de business logic staat. 

Hoe ouder het framework van een applicatie is, hoe meer werk het wordt voor softwareontwikkelaars om de software te onderhouden of te updaten. Op de lange termijn kan het veel tijd en geld besparen om het framework van een applicatie up to date te houden.

De nadelen

Helaas zullen niet alle libraries die voorheen gebruikt werden ondersteuning bieden binnen de nieuwere versies van het framework. In dergelijke gevallen moet een moeilijke keuze worden gemaakt: 

• Wachten met updaten in de hoop dat de library binnenkort compatibel gemaakt wordt.
• De library zelf updaten indien deze open source is. Je kunt bijvoorbeeld de update zelf uitvoeren en een pull request maken voor de library. Of je kunt de library forken en in eigen onderhoud nemen.
• Een vervangende library zoeken en de applicatie updaten om met deze vervangende library te werken. 

Een dergelijk probleem zijn wij tegengekomen in de assetmanager. In eerste instantie besloten wij te wachten met updaten. Maar omdat het project een paar maanden later nog niet geüpdatet was hebben we een alternatief moeten vinden; een extern onderhouden fork op de library. Uiteindelijk is de oorspronkelijke library wel geüpdatet dus konden we weer terug naar het gebruik daarvan.

Bovendien is het updaten van een framework een werk-intensieve actie en bestaat altijd het risico dat features omvallen en dus ook wijzigingen aan de code nodig zijn voordat de applicatie volledig kan functioneren in het geüpdate framework. Het vereist dus niet alleen veel tijd om de migratie uit te voeren, maar ook veel tijd om te testen en vervolgens eventuele gebreken op te lossen. 

Hoe te updaten?

In het geval van een update van Zend naar Laminas wordt een hoop werk uit handen genomen. Laminas voorziet namelijk in een laminas-migration handleiding en library waarmee elk onderdeel van het framework wordt geüpdatet en elke instantie van het oude onderdeel wordt ververst. 

Vervolgens moeten alle resterende libraries geüpdatet worden naar een compatibele versie. Dit is een werk-intensief proces aangezien er conflicten kunnen ontstaan waar meerdere libraries verschillende versies willen hebben van eenzelfde dependency. In dit geval moet worden onderzocht wat het conflict veroorzaakt en moeten beide libraries worden geüpdatet naar een versie waar zij dezelfde versie van die dependency vereisen. Indien er geen versie is waarbij dezelfde versies ondersteunt worden moet nagedacht worden of deze zelf als update pull request ingeschoten wordt bij het open source pakket.

Tot slot moet alle code in de applicatie doorgelopen worden om te controleren of niet ergens nog verwijderde onderdelen van de oude PHP en MySQL versies werden gebruikt. 

Maar wat als we naar een ander framework willen?

Het kan natuurlijk voorkomen dat ondersteuning voor een framework compleet stopt, of dat het om andere redenen wenselijk is om over te stappen naar een ander framework. Het is bijvoorbeeld makkelijker om ontwikkelaars te vinden voor een wijd gebruikt framework dan voor een niche framework. Een overstap is vaak moeilijker dan het updaten naar een nieuwe versie van eenzelfde framework. En hoe het aangepakt moet worden is afhankelijk van de applicatie zelf. Je moet je bijvoorbeeld afvragen:

• Lijken de frameworks enigszins op elkaar waardoor de transitie makkelijker wordt? 
• Is er al kennis in huis voor het nieuwe framework of moeten mensen worden omgeschoold?
• Hoe groot is de codebase?
• Hoe dicht is de business logica tegen het framework aan geprogrammeerd? (tight coupling)
• Voorziet de applicatie nog voldoende toekomst om zo’n grote wijziging te ondernemen?

Mocht het toch wenselijk zijn om een dergelijke migratie te maken, dan is de consensus dat dit het beste stapsgewijs kan gebeuren, feature voor feature. Echter bij kleinere applicaties, zoals de aanmeldapplicatie welke wij recent geüpdatet hebben is het ook mogelijk om dit in een big bang aan te pakken. Het is een transitie die makkelijk meerdere maanden of zelfs jaren kan kosten voordat zij compleet is. Daarom  is dit vaak niet aan te raden, al helemaal niet voor grotere applicaties.

Kortom, het updaten van een framework, of het migreren naar een ander, is een werk-intensieve operatie met behoorlijk wat haken en ogen. Echter, biedt het zeker ook voordelen en ontkom je er soms niet aan vanwege security overwegingen. Heeft u vragen of denkt u eraan om uw applicatie te updaten dan wel te migreren naar een ander framework? Wilt u een beter idee krijgen van de kosten én baten van zo’n project?  Senet heeft jarenlange expertise met maatwerk software en een verscheidenheid aan frameworks. Wij kunnen u van een gedegen advies voorzien en een vrijblijvende afspraak is altijd mogelijk!