Per rendere il nostro LMS disponibile online per voi, dietro le quinte viene svolto un grande lavoro. Mettere tutto insieme richiede molto lavoro di sviluppo.
Molte cose sono cambiate da quando l'azienda ha iniziato a costruire Easy LMS. Volete saperne di più? Il nostro gufo del marketing Priscila ha intervistato uno dei nostri sviluppatori per scoprire come costruiamo Easy LMS utilizzando un'architettura a microservizi, cosa significa e come questo influisce sul lavoro che svolgiamo come team e sugli utenti finali.
Priscila: Grazie per esserti unito a me per questa intervista, Thomas! La prima cosa che vorrei sapere (e credo anche la maggior parte dei lettori) è cosa sia l'architettura a microservizi. Potresti spiegarcelo?
Thomas: Nessun problema. L'architettura a microservizi è un modo di costruire il codice in più parti o repository. Possiamo dire che dividiamo il modo in cui costruiamo il codice in più istanze invece di costruire un unico grande blocco di codice.
Priscila: Interessante. Quindi significa che il team di sviluppo costruisce pezzi di codice indipendenti che si adattano al resto del software, giusto? Ma non è sempre stato così in Easy LMS. Perché il team di sviluppo ha ritenuto necessario cambiare il modo in cui costruite il codice? Cosa ha portato a questo? Si trattava di una nuova tendenza o qualcosa del genere?
Thomas: Sì, è una tendenza, ma non è stata la ragione principale. Abbiamo sempre saputo dell'architettura a microservizi. Ma all'inizio abbiamo costruito Easy LMS come grandi pezzi di codice, o come si chiama un monolite. Quando abbiamo iniziato a crescere come azienda, abbiamo avuto molto più traffico sul sito web, il che ha creato molti problemi, come pagine poco reattive e bug. Ci siamo resi conto che dovevamo cambiare il modo in cui costruivamo il codice, in modo che il sito web potesse adattarsi e scalare automaticamente.
È come avere una "grande fabbrica" che viene facilmente sommersa da un sacco di lavoro. Abbiamo capito che dovevamo costruire alcune "fabbriche più piccole" per gestire altre parti del lavoro.
Abbiamo scoperto che alcune parti del codice non erano pratiche e che potevamo migliorarle. Poi abbiamo pensato che fosse più facile eseguire i miglioramenti in piccole parti, invece di affrontarli come un progetto gigantesco. È come avere una "grande fabbrica" che viene facilmente sommersa da un sacco di lavoro. Abbiamo capito che dovevamo costruire alcune "fabbriche più piccole" per gestire altre parti del lavoro.
Priscila: Puoi fare un esempio di qualcosa che abbiamo realizzato in un'architettura a microservizi?
Tomas: Un esempio recente di microservizio che abbiamo implementato è la nuova funzione di esportazione della sessione d'esame e dei dati dei partecipanti. L'abbiamo realizzata negli ultimi due cicli. Le vecchie esportazioni venivano eseguite nella nostra vecchia "grande fabbrica" insieme a più cose e non erano ottimizzate.
Potremmo creare una "piccola fabbrica" specializzata nella creazione di queste nuove esportazioni. Con le esportazioni, abbiamo incontrato molti problemi. Ad esempio, quando i clienti avevano troppi dati da esportare, le loro richieste sovraccaricavano il sistema principale. Ora che abbiamo un servizio separato per le esportazioni, queste possono funzionare senza problemi. Abbiamo costruito un codice per le esportazioni e un altro per informare gli amministratori che le esportazioni sono pronte. Si tratta di unità autonome, non di grandi pezzi.
Priscila: Fico! Ci sono altre parti di Easy LMS che abbiamo costruito con un'architettura a microservizi?
Thomas: Sì, ci sono. Uno dei più interessanti è il nuovo design dell'Accademia. Abbiamo costruito la nuova Academy con React, che è un framework per la costruzione di interfacce. L'abbiamo costruita partendo dalla vecchia architettura (il monolite), prendendo pezzi da quel pezzo e creando una parte autonoma. Abbiamo anche creato un'API (interfaccia di programmazione delle applicazioni) per recuperare i dati da mostrare nell'interfaccia. Ora abbiamo due parti autonome: una per recuperare i dati e l'altra per visualizzarli. Sono più piccole e più facili da mantenere.
Priscila: Ok, in base a quello che mi hai detto, abbiamo ancora del vecchio codice. È un problema che ora abbiamo due tipi di codice nel sistema? È previsto un aggiornamento?
Thomas: No, non è un problema. È un processo. Abbiamo costruito le prime parti del sistema utilizzando il metodo dei 'grandi pezzi di codice'. Abbiamo in programma di sostituirli. Ma i clienti non notano la differenza. Costruiamo il nuovo codice in modo che possa funzionare senza problemi con il vecchio codice.
Priscila: Capito. Quindi, come sviluppatore, cosa preferisci? È più facile o più complicato costruire codice con l'architettura a microservizi rispetto al processo precedente?
Thomas: Sì, è molto più facile pensare a piccoli pezzi e mantenere il nuovo codice. Stiamo pensando di aggiornare l'interfaccia dei partecipanti in futuro, in modo che funzioni meglio in combinazione con l'Accademia e con se stessa. Se lo costruiamo con un'architettura a microservizi, sarà molto più facile aggiungere funzionalità perché potremo lavorare su ogni parte individualmente.
Priscila: Quindi, in che modo lavorare con i microservizi ha cambiato il tuo modo di lavorare?
Thomas: Possiamo sviluppare più velocemente e meglio. I microservizi ci aiutano a mantenere il sito web e ci permettono di rilasciare le cose più rapidamente.
Possiamo anche decidere il modo migliore per completare un lavoro, perché ogni pezzo di codice è un'unità autonoma. Ciò significa che possiamo stabilire quale linguaggio di programmazione vogliamo usare e quale tipo di servizio vogliamo eseguire.
Quando usavamo il vecchio sistema, se volevamo aggiornare una build usando una certa lingua, dovevamo continuare a costruire il codice in quella lingua. Ora possiamo scegliere tra diverse lingue in base a quella che riteniamo migliore per quella funzione. Lavoriamo in team. Se iniziamo un nuovo microservizio, esploriamo le nostre opzioni e poi decidiamo cosa funziona meglio per noi. Questo ci dà più opzioni.
Priscila: Questo influisce sul toccare parti indesiderate del sistema, come quando si cerca di risolvere un problema e si finisce per crearne un altro (come un bug)?
Thomas: Sì, anche un anno fa, quando cercavamo di risolvere cose che richiedevano molto codice, finivamo per lavorare su troppe cose inutili. Ad esempio, se volevamo risolvere X, risolvevamo Y e poi creavamo il bug Z. Lavorare con i microservizi ha ridotto questo problema.
Priscila: Ok. Capisco che l'architettura a microservizi renda il lavoro più facile da gestire per il team di sviluppo. Ma come si ripercuote sui nostri clienti e sui loro partecipanti?
Thomas: Beh, come ho detto, i clienti non notano (e non dovrebbero notare) le diverse parti di codice. Tutto dovrebbe funzionare insieme per creare un'esperienza fluida. I clienti possono trarre vantaggio perché ora possiamo rilasciare nuove funzionalità più velocemente e migliorare in base al loro feedback.
Si tratta di un cambiamento drastico rispetto al modo in cui facevamo le cose prima. Ad esempio, quando abbiamo rilasciato la nuova dashboard di amministrazione di Exam, ci sono voluti circa sei mesi di sviluppo prima di rilasciare il tutto in una volta sola. Se i clienti la amavano o la odiavano, non si poteva tornare indietro (per fortuna, l'hanno amata?). Ora abbiamo cambiato il modo di creare e rilasciare nuove funzionalità.
Il nuovo costruttore di corsi, ad esempio, è stato rilasciato inizialmente come funzione Beta. L'abbiamo costruito con React e l'abbiamo rilasciato un po' alla volta, aggiungendo nuove caratteristiche minori fino a quando non ha avuto tutte le funzionalità per sostituire il vecchio costruttore di corsi nella sua interezza. Nel frattempo, abbiamo potuto vedere cosa funzionava, come i clienti lo utilizzavano, migliorarlo, iterarlo e quindi apportare modifiche. Questo non sarebbe stato possibile con grossi pezzi di codice rilasciati in una sola volta.
Priscila: Questo ha molto senso. Da quello che ricordo, è in linea con i principi dell'Improvement Kata di Toyota che applichiamo in azienda. È meglio realizzare un prototipo, ricevere un feedback e migliorare la funzionalità invece di spendere molto tempo senza sapere come i clienti la riceveranno. Grazie per esservi uniti a me in questa intervista!
Thomas: Sì, credo che funzioni meglio. Spero di aver fatto luce su come lavora il nostro team di sviluppo in Easy LMS! Non c'è di che.
