Der foregår meget arbejde bag kulisserne for at gøre vores LMS tilgængeligt online for dig. Det kræver masser af udviklingsarbejde at sætte det hele sammen. .
Mange ting har ændret sig, siden virksomheden først begyndte at bygge Easy LMS. Vil du gerne vide mere? Vores marketingugle Priscila har interviewet en af vores udviklere for at lære, hvordan vi bygger Easy LMS ved hjælp af en mikroservicearkitektur, hvad det betyder, og hvordan det påvirker det arbejde, vi udfører som team, og slutbrugerne.
Priscila: Tak, fordi du vil være med til dette interview, Thomas! Det første, jeg gerne vil vide (og jeg tror, de fleste af læserne), er, hvad mikroservicearkitektur er. Kan du forklare det?
Thomas: Intet problem. Mikroservicearkitektur er en måde at opbygge kode på i flere dele eller arkiver. Vi kan sige, at vi opdeler den måde, vi bygger kode på, i flere instanser i stedet for at bygge én stor kodeblok.
Priscila: Interessant. Så det betyder, at udviklingsteamet bygger stykker af uafhængig kode, der passer sammen med resten af softwaren, ikke? Men sådan har det ikke altid været i Easy LMS. Hvorfor så udviklingsteamet et behov for at ændre den måde, I bygger koden på? Hvad førte til det? Var det en ny trend eller noget?
Thomas: Ja, det er en trend, men det var ikke hovedårsagen. Vi har altid kendt til mikroservice-arkitektur. Men i begyndelsen byggede vi Easy LMS som store stykker kode, eller det, der kaldes en monolit. Da vi begyndte at vokse som virksomhed, fik vi meget mere trafik på hjemmesiden, og det skabte en masse problemer, f.eks. sider, der ikke reagerede, og fejl. Vi indså, at vi var nødt til at ændre den måde, vi byggede koden på, så hjemmesiden kunne justeres og skaleres automatisk.
Det er som at have en "stor fabrik", der let bliver overvældet af en masse arbejde. Vi indså, at vi var nødt til at bygge nogle "mindre fabrikker" til at håndtere andre dele af arbejdet.
Vi fandt ud af, at nogle dele af koden ikke var praktisk anvendelige, og at vi kunne forbedre dem. Så tænkte vi, at det var nemmere at udføre forbedringerne i mindre bidder i stedet for at påtage os dem som et kæmpe projekt. Det er som at have en "stor fabrik", der let bliver overvældet af en masse arbejde. Vi indså, at vi var nødt til at bygge nogle "mindre fabrikker" til at håndtere andre dele af arbejdet.
Priscila: Kan du give et eksempel på noget, vi har bygget i en mikroservice-arkitektur? .
Thomas: Et nyligt eksempel på en mikroservice, vi har implementeret, er den nye eksportfunktion til eksport af eksamenssessioner og deltagerdata. Vi lavede den i de sidste to cyklusser. Den gamle eksport kørte i vores gamle "store fabrik" sammen med flere ting og var ikke optimeret.
Vi kunne skabe en "lillebitte fabrik", der specialiserede sig i at skabe disse nye eksportvarer. Med eksporten løb vi ind i mange problemer. For eksempel, når kunderne havde for mange data at eksportere, overvældede deres anmodninger hovedsystemet. Nu, hvor vi har en separat tjeneste til eksporten, kan den køre problemfrit. Vi har faktisk bygget en kode til eksporten og en anden til at informere administratorerne om, at deres eksport er klar. De er selvstændige enheder, ikke store bidder.
Priscila: Cool! Er der andre dele af Easy LMS, som vi har bygget med mikroservicearkitektur?
Thomas: Ja, det er der. En af de mest interessante er akademiets nye design. Vi byggede det nye akademi med React, som er et framework til at bygge grænseflader. Vi byggede det ud fra den gamle arkitektur (monolitten), tog dele fra den og skabte en selvstændig del. Vi byggede også en API (Application Programming Interface) til at hente data, som kan vises i grænsefladen. Vi har nu to selvstændige dele: en til at hente data og en til at vise dem. De er mindre og lettere at vedligeholde.
Priscila: Ok, baseret på det, du fortalte mig, har vi stadig noget gammel kode. Er det et problem, at vi nu har to typer kode i systemet?? Er der planer om at opdatere det?
Thomas: Nej, det er ikke et problem. Det er en proces. Vi byggede de første dele af systemet ved hjælp af "store stykker kode"-metoden. Der er planer om at udskifte dem. Men kunderne kan ikke mærke forskel. Vi bygger den nye kode på en måde, så den problemfrit kan arbejde sammen med den gamle kode.
Priscila: Forstået. Så hvad foretrækker du som udvikler? Er det lettere eller mere kompliceret at bygge kode med mikroservice-arkitektur sammenlignet med den tidligere proces?
Thomas: Ja, det er meget nemmere at tænke i små bidder og vedligeholde den nye kode. Vi overvejer at opdatere deltagergrænsefladen i fremtiden, så den fungerer bedre i kombination med akademiet og sig selv. Hvis vi bygger det med mikroservicearkitektur, bliver det meget nemmere at tilføje funktioner, fordi vi kan arbejde på hver del for sig.
Priscila: Så hvordan har arbejdet med mikrotjenester ændret den måde, du arbejder på? .
Thomas: Vi kan udvikle hurtigere og bedre. Microservices hjælper os med at vedligeholde hjemmesiden og gør os i stand til at frigive ting hurtigere..
Vi kan også beslutte den bedste måde at udføre et job på, fordi hvert stykke kode er en selvstændig enhed. Det betyder, at vi kan bestemme, hvilket programmeringssprog vi vil bruge, og hvilken slags tjeneste vi vil køre.
Da vi brugte det gamle system, skulle vi fortsætte med at bygge koden på det pågældende sprog, hvis vi ville opdatere et build med et bestemt sprog. Nu kan vi vælge mellem forskellige sprog ud fra, hvad vi synes er bedst for den pågældende funktion. Vi arbejder i teams. Hvis vi starter en ny mikrotjeneste, udforsker vi vores muligheder, og så beslutter vi, hvad der fungerer bedst for os. Det giver os flere muligheder.
Priscila: Kan det påvirke berøring af uønskede dele af systemet, f.eks. når du prøver at løse et problem og ender med at skabe et andet (f.eks. en fejl)?
Thomas: Ja, selv for et år siden, da vi forsøgte at løse ting, der involverede en masse kode, endte vi med at arbejde på for mange unødvendige ting. Hvis vi for eksempel skulle løse X, løste vi Y og skabte derefter fejl Z. Arbejdet med mikrotjenester har reduceret dette problem. .
Priscila: Ok. Jeg kan se, at mikroservicearkitekturen gør arbejdet lettere at håndtere for udviklingsteamet. Men hvordan påvirker det vores kunder og deres deltagere? .
Thomas: Som jeg sagde, lægger kunderne ikke mærke til (og bør ikke lægge mærke til) forskellige dele af koden. Alt skal arbejde sammen for at skabe en god oplevelse. Kunderne kan drage fordel af det, fordi vi nu kan frigive nye funktioner hurtigere og forbedre dem på baggrund af deres feedback.
Det er en drastisk ændring i forhold til den måde, vi gjorde tingene på før. Da vi for eksempel udgav det nye Exam admin-dashboard, tog det os omkring seks måneders udvikling, før vi udgav det hele på én gang. Hvis kunderne elskede det eller hadede det, var der ingen vej tilbage (heldigvis elskede de det?). Nu har vi ændret den måde, vi skaber og frigiver nye funktioner på.
Den nye kursusbygger blev f.eks. først udgivet som en beta-funktion. Vi byggede den med React og frigav den lidt efter lidt og tilføjede mindre nye funktioner, indtil den havde alle de funktioner, der skulle til for at erstatte den gamle kursusbygger i sin helhed. I mellemtiden kunne vi se, hvad der fungerede, hvordan kunderne brugte det, forbedre det, gentage det og derefter foretage ændringer. Det ville ikke have været muligt med store stykker kode, der blev frigivet på én gang.
Priscila: Det giver rigtig god mening. Så vidt jeg husker, stemmer det overens med principperne i Toyotas Improvement Kata, som vi anvender i virksomheden. Det er bedre at lave en prototype, få feedback og forbedre funktionen i stedet for at bruge en masse tid uden at vide, hvordan kunderne vil modtage den. Tak, fordi du ville deltage i dette interview!
Thomas: Ja, jeg tror, det fungerer bedre. Jeg håber, at jeg kunne kaste lidt lys over, hvordan vores udviklingsteam arbejder hos Easy LMS! Det var så lidt .
