Er wordt achter de schermen veel werk verricht om ons LMS online voor jou beschikbaar te maken. Om alles samen te stellen is veel ontwikkelingswerk nodig.
Er is veel veranderd sinds het bedrijf Easy LMS begon te bouwen. Wil je meer weten? Onze Marketing Uil Priscila interviewde een van onze ontwikkelaars om te leren hoe we Easy LMS bouwen met behulp van een microservice architectuur, wat dat betekent en hoe dat het werk dat we als team doen en de eindgebruikers beïnvloedt.
Priscila: Bedankt dat je met me meedoet aan dit interview, Thomas! Het eerste wat ik wil weten (en ik denk de meeste lezers) is wat een microservice-architectuur is. Kun je dat uitleggen?
Thomas: Geen probleem. Microservice-architectuur is een manier om code op te bouwen in meerdere delen of repositories. We kunnen zeggen dat we de manier waarop we code bouwen opsplitsen in meerdere instanties in plaats van één groot codeblok te bouwen.
Priscila: Interessant. Dus het betekent dat het ontwikkelingsteam stukken onafhankelijke code bouwt die bij de rest van de software passen, toch? Maar het was niet altijd zo in Easy LMS. Waarom zag het ontwikkelteam de noodzaak om de manier waarop de code wordt gebouwd te veranderen? Wat was de aanleiding? Was dat een nieuwe trend of zo?
Thomas: Ja, het is een trend, maar dat was niet de belangrijkste reden. We wisten altijd al van microservice-architectuur. Maar in het begin bouwden we Easy LMS als grote stukken code, of wat een monoliet wordt genoemd. Toen we als bedrijf begonnen te groeien, kregen we veel meer verkeer op de website, wat voor veel problemen zorgde, zoals niet-reagerende pagina's en bugs. We realiseerden ons dat we de manier waarop we de code bouwden moesten veranderen, zodat de website zich automatisch kon aanpassen en schalen.
Het is alsof je een "grote fabriek" hebt die snel overweldigd wordt door veel werk. We realiseerden ons dat we een aantal "kleinere fabrieken" moesten bouwen om andere delen van het werk aan te kunnen
We ontdekten dat sommige delen van de code niet praktisch waren en dat we ze konden verbeteren. Toen dachten we dat het gemakkelijker was om de verbeteringen in kleinere stukjes uit te voeren in plaats van ze als een gigantisch project aan te nemen. Het is alsof je een "grote fabriek" hebt die snel overweldigd wordt door veel werk. We realiseerden ons dat we een aantal "kleinere fabrieken" moesten bouwen om andere delen van het werk aan te kunnen.
Priscila: Kun je een voorbeeld geven van iets dat we hebben gebouwd in een microservicearchitectuur?
Thomas: Een recent voorbeeld van een microservice die we hebben geïmplementeerd is de nieuwe exportfunctie voor de Examensessie-export en de deelnemergegevens-export. We hebben deze in de laatste twee cycli gemaakt. De oude exports draaiden in onze oude "grote fabriek" samen met meerdere dingen en waren niet geoptimaliseerd.
We zouden een "kleine fabriek" kunnen oprichten die gespecialiseerd is in het maken van deze nieuwe exportproducten. Met de export kwamen we veel problemen tegen. Wanneer klanten bijvoorbeeld te veel gegevens hadden om te exporteren, overweldigden hun verzoeken het hoofdsysteem. Nu we een aparte service hebben voor de export, kan deze soepel verlopen. We hebben een code gemaakt voor de export en een andere code om de beheerders te informeren dat hun export klaar is. Het zijn op zichzelf staande eenheden, geen grote brokken.
Priscila: Cool! Zijn er nog andere onderdelen van Easy LMS die we hebben gebouwd met microservice-architectuur?
Thomas: Ja, die zijn er. Een van de meest interessante is het nieuwe ontwerp van de Academy. We hebben de nieuwe Academy gebouwd met React, een framework voor het bouwen van interfaces. We bouwden het vanuit de oude architectuur (de monoliet), namen stukken uit die brok en creëerden een op zichzelf staand deel. We bouwden ook een API (application programming interface) voor het ophalen van gegevens om in de interface te tonen. We hebben nu twee op zichzelf staande onderdelen: het ophalen van gegevens en de andere voor het weergeven van die gegevens. Ze zijn kleiner en gemakkelijker te onderhouden.
Priscila: Oké, gebaseerd op wat je me hebt verteld, hebben we nog wat oude code. Is het een probleem dat we nu twee soorten code in het systeem hebben? Zijn er plannen om het bij te werken?
Thomas: Nee, het is geen probleem. Het is een proces. We hebben de eerste delen van het systeem gebouwd met de 'grote stukken code'-methode. Er zijn plannen om deze te vervangen. Maar de klanten merken het verschil niet. We bouwen de nieuwe code zo dat het naadloos kan samenwerken met de oude code.
Priscila: Begrepen. Waar geef je als ontwikkelaar de voorkeur aan? Is het gemakkelijker of ingewikkelder om code te bouwen met een microservicearchitectuur in vergelijking met het vorige proces?
Thomas: Ja, het is veel gemakkelijker om in kleine stukjes te denken en de nieuwe code te onderhouden. We overwegen om de deelnemersinterface in de toekomst te updaten, zodat deze beter werkt in combinatie met de Academy en zichzelf. Als we het bouwen met een microservicearchitectuur, is het veel gemakkelijker om functies toe te voegen omdat we aan elk onderdeel afzonderlijk kunnen werken.
Priscila: Hoe heeft het werken met microservices je manier van werken veranderd?
Thomas:We kunnen sneller en beter ontwikkelen. Microservices helpen ons om de website te onderhouden en stellen ons in staat om dingen sneller uit te brengen.
We kunnen ook beslissen wat de beste manier is om een taak te voltooien omdat elk stuk code een op zichzelf staande eenheid is. Dat betekent dat we kunnen bepalen welke programmeertaal we willen gebruiken en wat voor soort service we willen draaien.
Toen we het oude systeem gebruikten, als we een build wilden updaten met een bepaalde taal, moesten we doorgaan met het bouwen van de code in die taal. Nu kunnen we kiezen tussen verschillende talen op basis van wat we denken dat het beste is voor die functie. We werken in teams. Als we een nieuwe microservice starten, verkennen we onze opties en dan beslissen we wat het beste voor ons werkt. Het geeft ons meer opties.
Priscila: Is dat ook van invloed op het aanraken van ongewenste delen van het systeem, zoals wanneer je een probleem probeert op te lossen en uiteindelijk een ander probleem creëert (zoals een bug)?
Thomas: Ja, zelfs een jaar geleden, toen we dingen probeerden op te lossen waarvoor veel code nodig was, werkten we uiteindelijk aan te veel onnodige dingen. Als we bijvoorbeeld X wilden oplossen, losten we Y op en creëerden we vervolgens bug Z. Het werken met microservices heeft dit probleem verminderd.
Priscila: Ok. Ik zie dat microservice-architectuur het werk gemakkelijker maakt voor het ontwikkelingsteam. Maar wat is het effect op onze klanten en hun deelnemers?
Thomas: Nou, zoals ik al zei, de klanten merken verschillende delen van code niet op (en zouden dat ook niet moeten doen). Alles moet samenwerken voor een soepele ervaring. Klanten kunnen hiervan profiteren omdat we nu sneller nieuwe functies kunnen uitbrengen en verbeteringen kunnen aanbrengen op basis van hun feedback.
Het is een drastische verandering ten opzichte van de manier waarop we dingen voorheen deden. Toen we bijvoorbeeld het nieuwe Exam admin dashboard uitbrachten, duurde het ongeveer zes maanden voordat we alles in één keer uitbrachten. Als klanten het geweldig vonden of niet, was er geen weg terug (gelukkig vonden ze het geweldig?). Nu hebben we de manier waarop we nieuwe functies maken en uitbrengen veranderd.
De nieuwe Course builder, bijvoorbeeld, werd eerst uitgebracht als een Beta-functie. We bouwden het met React en brachten het beetje bij beetje uit, waarbij we kleine nieuwe functies toevoegden totdat het alle functionaliteiten had om de oude course builder in zijn geheel te vervangen. In de tussentijd konden we zien wat werkte, hoe klanten het gebruikten, het verbeteren, het herhalen en vervolgens wijzigingen aanbrengen. Dat zou niet mogelijk zijn geweest met grote stukken code die in één keer waren vrijgegeven.
Priscila: Dat klinkt heel logisch. Van wat ik me herinner, komt het overeen met de principes van Toyota's Improvement Kata die we in het bedrijf toepassen. Het is beter om een prototype te maken, feedback te krijgen en de functie te verbeteren in plaats van veel tijd te spenderen zonder te weten hoe de klanten het zullen ontvangen. Bedankt voor je bezoek aan dit interview!
Thomas: Ja, ik denk dat dat beter werkt. Ik hoop dat ik wat licht kon werpen op hoe ons ontwikkelingsteam bij Easy LMS werkt! Graag gedaan.
