01/05/2020
Innovatieve aanpak helpt bedrijven met legacy software naar de cloud
Cyso en Ambrero Software lanceren renovatieplan om verouderde applicaties naar de de cloud te brengen.
Blog
Heeft u onze white paper over het gebruik van container technologie en microservices gelezen of is uw interesse in deze ontwikkelingen gewekt door een andere bron? Bent u enthousiast over de mogelijkheden en wilt u diensten ombouwen om ook gebruik te maken van deze technologie? Maar hoe start u met microservices en containers? Als er één ding duidelijk mag zijn, is dat de juiste keuzes maken niet zo eenvoudig is.
Cyso kan u adviseren en helpen bij het op de juiste wijze de transitie aanvliegen naar een container-gebaseerde oplossing. In dit artikel beschrijven wij een aanpak om tot een juiste implementatie voor uw applicatie te komen.
Wij onderscheiden bij onze aanpak een aantal stappen die wij doorlopen:
Voordat er goed en wel begonnen kan worden, kijken we eerst naar de huidige situatie en de bestaande problemen. Dit is cruciaal om ervoor te zorgen dat om de juiste redenen aan het nieuwe traject wordt gestart. Als bij het definiëren van de problematiek namelijk blijkt dat de oplossing niet gevonden kan worden door een migratie naar containers en microservices, zal er in een andere richting moeten worden gekeken.
Als er voldoende aanleiding is om wel te kijken naar containers en microservices, gaan we vervolgens aan de slag met het goed in kaart brengen van wensen en eisen rondom de nieuwe situatie. Er wordt eveneens geïnventariseerd en gedefinieerd hoeveel tijd en middelen er beschikbaar zijn van de verschillende betrokken partijen (uitbater, ontwikkelaar en hostingpartij).
Als bovenstaande gegevens bekend zijn, volgt een gedetailleerde analyse van de bestaande omgeving en betrokken processen in de organisatie. Er worden verschillende onderdelen zorgvuldig onder de loep genomen:
We kijken in hoeverre het mogelijk en haalbaar is om de applicatie zelf op te splitsen in aparte, functionele onderdelen. Als een applicatie al uit losse componenten bestaat en/of via API’s intern communiceert, is het eenvoudiger om een migratie te realiseren. Als de applicatie niet of nauwelijks op een dergelijke wijze is opgebouwd, kan het weleens bijzonder lastig zijn om het traject daadwerkelijk te gaan uitvoeren.
Net als de applicatie, zal er in het onderliggende platform zelf een functionele scheiding gemaakt moeten kunnen worden. Hierbij kan bijvoorbeeld gedacht worden aan de scheiding tussen applicatie(s) en database, het inrichten van centrale file storage of het gebruik van object storage.
Doordat er een scheiding van componenten zal worden aangebracht, veranderen er onvermijdelijk ook zaken rondom het netwerk. De bestaande connectiviteit, zowel extern als intern, zal veranderen omdat de wijze waarop onderdelen met elkaar gaan communiceren zullen veranderen. Een container-gebaseerd platform kent een eigen netwerklaag die dient te worden meegenomen bij het vervangen van bestaande verbindingen.
Voor de vernieuwde situatie zal er in veel gevallen gebruik gemaakt moeten worden van nieuwe tools. Dit betreft over het algemeen technologie zoals templating, configuratiebeheer en automatische deployment. Er wordt gekeken welke tools er voorhanden zijn en voor welke implementatie er gekozen wordt.
Het analyseren van de bestaande omgeving resulteert in een rapport. Hierin doen we aanbevelingen over de mogelijke wijze om tot implementatie over te gaan, geven we een indicatie af van de haalbaarheid bij het maken van specifieke keuzes en presenteren we een migratieplan en ontwerp voor het toekomstige platform. Op basis van dit rapport zal in overleg besloten worden tot een Go of een No-Go.
Indien alle partijen besluiten verder te gaan tot implementatie, wordt een gedetailleerd plan opgesteld over hoe tot implementatie en migratie wordt overgegaan. Dit bestaat uit een technisch ontwerp, iteraties en tijdslijnen, afspraken over samenwerking en commitment en procedures voor testen en acceptatie. De tooling voor toekomstige deployment en integratie worden eveneens benoemd. Met alle betrokken personen in het project wordt afgesproken wat hun rollen en verantwoordelijkheden zijn.
Een belangrijk deel van deze fase is het bepalen welke onderdelen gemigreerd worden naar de nieuwe structuur. In veel gevallen is het namelijk niet realistisch om direct alles te gaan migreren naar de nieuwe structuur. Het project wordt daarmee te groot en te complex; veel beter is vaak om in eerste instantie alleen specifieke onderdelen onder handen te nemen en daarmee ervaring op te doen met de nieuwe technologie. In een later stadium kan verdere opsplitsing dan alsnog worden gerealiseerd.
Na al deze voorbereidingswerkzaamheden, is het nu eindelijk tijd om daadwerkelijk aan de slag te gaan. In deze fase wordt permanent nauw samengewerkt door de ontwikkelaars en DevOps engineers. De vereiste aanpassingen in de applicatie worden geprogrammeerd, configuraties in het platform worden getest en doorgevoerd en de voortgang wordt doorlopend bewaakt door te testen en in korte cycli of sprints bij te sturen.
Development gebeurt op bijvoorbeeld de volgende onderdelen:
Als alle aanpassingen aan de applicatie, architectuur en platform naar tevredenheid zijn doorgevoerd en getest, kan de daadwerkelijke migratie worden gedaan en de nieuwe omgeving in productie worden genomen. De complexiteit en hoeveelheid werk is zeer afhankelijk van de doorgevoerde wijzigingen in zowel de applicatie, database als architectuur.
Als de migratie succesvol is uitgevoerd, begint het dagelijks beheer over het nieuwe platform. Alle nieuwe processen die toegevoegd of aangepast zijn om te profiteren van de nieuwe technologie zullen nu hun nut gaan bewijzen. Het verder ontwikkelen en verbeteren van de applicatie kan nu via continuous delivery of integration gaan plaatsvinden waardoor dit veel sneller zal gaan dan voorheen. Bij een gedeeltelijke implementatie van containers en microservices zullen zowel oude als nieuwe onderdelen naast elkaar blijven bestaan.
Het aanvliegen van een containers en microservices traject is een complex vraagstuk dat wij zorgvuldig behandelen. Het is belangrijk om de doelstellingen en haalbaarheid goed op het netvlies te hebben staan voordat er daadwerkelijk technisch aan de slag gegaan wordt. Wij betrekken hier daarom vanaf het begin niet alleen de eigenaar van de applicatie en het platform bij, maar ook de ontwikkelaar. Alle partijen hebben een belangrijke rol te vervullen voor het welslagen van het project.
Als u twijfelt of microservices en containers voor u een goede stap zouden zijn, of niet weet hoe u moet starten met een dergelijk traject, kunnen wij u helpen om de juiste keuze te maken en van start te gaan. Neem voor een verkennend gesprek om uw situatie en de mogelijkheden te bespreken contact op met een van onze solutions architecten.