Det görs mycket arbete bakom kulisserna för att göra vårt LMS tillgängligt online för dig. Att sätta ihop allt kräver mycket utvecklingsarbete. .
Många saker har förändrats sedan företaget först började bygga Easy LMS. Skulle du vilja veta mer? Vår marknadsföringsuggla Priscila intervjuade en av våra utvecklare för att lära sig hur vi bygger Easy LMS med hjälp av en mikroservicearkitektur, vad det innebär och hur det påverkar det arbete vi gör som ett team och slutanvändarna.
Priscila: Tack för att du kom till mig för den här intervjun, Thomas! Det första jag vill veta (och jag tror att de flesta av läsarna) är vad mikroservicearkitektur är. Kan du förklara?
Thomas: Inga problem. Microservice-arkitektur är ett sätt att bygga kod i flera delar eller repositorier. Vi kan säga att vi delar upp vårt sätt att bygga kod i flera instanser istället för att bygga ett stort kodblock.
Priscila: Intressant. Så det betyder att utvecklingsteamet bygger bitar av oberoende kod som passar ihop med resten av programvaran, eller hur? Men det har inte alltid varit så här i Easy LMS. Varför såg utvecklingsteamet behovet av att ändra sättet ni bygger koden på? Vad ledde till det? Var det en ny trend eller något?
Thomas: Ja, det är en trend, men det var inte huvudskälet. Vi har alltid känt till mikrotjänstarkitektur. Men i början byggde vi Easy LMS som stora bitar av kod, eller vad som kallas en monolit. När vi började växa som företag hade vi mycket mer trafik på webbplatsen, vilket skapade många problem, till exempel sidor som inte svarade och buggar. Vi insåg att vi behövde förändra sättet vi bygger koden på så att webbplatsen kunde justeras och skalas automatiskt.
Det är som att ha en "stor fabrik" som lätt blir överväldigad av en massa arbete. Vi insåg att vi var tvungna att bygga några "mindre fabriker" för att hantera andra delar av arbetet
Vi upptäckte att vissa delar av koden inte var praktiska och att vi kunde förbättra dem. Då tyckte vi att det var lättare att genomföra förbättringarna i mindre delar istället för att ta på oss dem som ett jätteprojekt. Det är som att ha en "stor fabrik" som lätt blir överväldigad av mycket arbete. Vi insåg att vi var tvungna att bygga några "mindre fabriker" för att hantera andra delar av arbetet.
Priscila: Kan du ge ett exempel på något som vi byggt i en mikroservicearkitektur?
Thomas: Ett färskt exempel på en mikrotjänst som vi implementerade är den nya exportfunktionen för export av examenssessioner och deltagardata. Vi gjorde det under de senaste två cyklerna. De gamla exportfunktionerna kördes i vår gamla "stora fabrik" tillsammans med flera andra saker och var inte optimerade.
Vi kunde skapa en "liten fabrik" som specialiserade sig på att skapa dessa nya exportvaror. Med exporten stötte vi på en hel del problem. När kunderna till exempel hade för mycket data att exportera överbelastade deras förfrågningar huvudsystemet. Nu när vi har en separat tjänst för exporten kan den fungera smidigt. Vi har faktiskt byggt en kod för exporten och en annan för att informera administratörerna om att deras export är klar. De är fristående enheter, inte stora bitar.
Priscila: Cool! Finns det några andra delar av Easy LMS som vi byggt med microservice-arkitektur?
Thomas: Ja, det finns det. En av de mest intressanta är akademins nya design. Vi byggde den nya akademin med React, som är ett ramverk för att bygga gränssnitt. Vi byggde den från den gamla arkitekturen (monoliten), tog bitar från den delen och skapade en fristående del. Vi byggde också ett API (applikationsprogrammeringsgränssnitt) för att hämta data som ska visas i gränssnittet. Vi har nu två fristående delar: en för att hämta data och en för att visa data. De är mindre och lättare att underhålla.
Priscila: Ok, baserat på vad du berättade för mig så har vi fortfarande en del gammal kod. Är det ett problem att vi nu har två typer av kod i systemet?? Finns det planer på att uppdatera den?
Thomas: Nej, det är inte ett problem. Det är en process. Vi byggde de första delarna av systemet med hjälp av metoden "stora bitar av kod". Det finns planer på att ersätta dem. Men kunderna kan inte märka skillnaden. Vi bygger den nya koden på ett sätt så att den sömlöst kan fungera med den gamla koden.
Priscila: Förstått. Så som utvecklare, vad föredrar du? Är det enklare eller mer komplicerat att bygga kod med en mikroservicearkitektur jämfört med den tidigare processen?
Thomas: Ja, det är mycket enklare att tänka i små bitar och underhålla den nya koden. Vi funderar på att uppdatera deltagargränssnittet i framtiden, så att det fungerar bättre i kombination med Academy och sig självt. Om vi bygger det med microservice-arkitektur blir det mycket enklare att lägga till funktioner eftersom vi kan arbeta med varje del för sig.
Priscila: Så, hur förändrade arbetet med mikrotjänster ditt sätt att arbeta?
Thomas: Vi kan utveckla snabbare och bättre. Mikrotjänster hjälper oss att underhålla webbplatsen och gör det möjligt för oss att släppa saker snabbare.
Vi kan också bestämma det bästa sättet att slutföra ett jobb eftersom varje kodbit är en fristående enhet. Det innebär att vi kan bestämma vilket programmeringsspråk vi vill använda och vilken typ av tjänst vi vill köra.
När vi använde det gamla systemet var vi tvungna att fortsätta bygga koden på det språket om vi ville uppdatera en version som använde ett visst språk. Nu kan vi välja mellan olika språk baserat på vad vi tycker är bäst för den funktionen. Vi arbetar i team. Om vi startar en ny mikrotjänst utforskar vi våra alternativ och sedan bestämmer vi vad som fungerar bäst för oss. Det ger oss fler alternativ.
Priscila: Påverkar det att röra oönskade delar av systemet, som när du försöker lösa ett problem och slutar med att skapa ett annat (till exempel en bugg)?
Thomas: Ja, även för ett år sedan, när vi försökte lösa saker som involverade mycket kod, slutade det med att vi jobbade med för många onödiga saker. Om vi till exempel skulle lösa X, så löste vi Y och skapade sedan bugg Z. Att arbeta med mikrotjänster har minskat detta problem.
Priscila: Ok. Jag ser att mikrotjänstarkitekturen gör arbetet enklare att hantera för utvecklingsteamet. Men hur påverkar det våra kunder och deras deltagare?
Thomas: Ja, som jag sa, klienterna märker inte (och borde inte märka) olika delar av koden. Allt ska fungera tillsammans för att skapa en smidig upplevelse. Kunderna kan dra nytta av det eftersom vi nu kan släppa nya funktioner snabbare och förbättra oss baserat på deras feedback.
Det är en drastisk förändring från hur vi gjorde saker tidigare. När vi till exempel släppte den nya Exam admin dashboard tog det oss cirka sex månader av utveckling tills vi släppte hela grejen på en gång. Om kunderna älskade eller hatade det fanns det ingen återvändo (lyckligtvis älskade de det?). Nu har vi förändrat vårt sätt att skapa och släppa nya funktioner.
Den nya kursbyggaren, till exempel, släpptes först som en beta-funktion. Vi byggde den med React och släppte den bit för bit och lade till mindre nya funktioner tills den hade alla funktioner för att ersätta den gamla kursbyggaren i sin helhet. Under tiden kunde vi se vad som fungerade, hur kunderna använde det, förbättra det, iterera det och sedan göra ändringar. Det skulle inte ha varit möjligt med stora bitar kod som släpptes på en gång.
Priscila: Det låter väldigt vettigt. Såvitt jag minns stämmer det överens med principerna i Toyotas Improvement Kata som vi tillämpar i företaget. Det är bättre att göra en prototyp, få feedback och förbättra funktionen istället för att spendera mycket tid utan att veta hur kunderna kommer att ta emot den. Tack för den här intervjun!
Thomas: Ja, jag tycker att det fungerar bättre. Jag hoppas att jag kunde sprida lite ljus över hur vårt utvecklingsteam arbetar på Easy LMS! Du är välkommen.
