Muito trabalho é feito nos bastidores para tornar o nosso LMS disponível online para si. Colocar tudo junto requer muito trabalho de desenvolvimento.
Muitas coisas mudaram desde que a empresa começou a construir o Easy LMS. Gostaria de saber mais? Nossa coruja de marketing Priscila entrevistou um de nossos desenvolvedores para saber como construímos o Easy LMS usando uma arquitetura de microserviços, o que isso significa e como isso afeta o trabalho que fazemos como equipe e os usuários finais.
Priscila:Obrigada por se juntar a mim para esta entrevista, Thomas! A primeira coisa que eu quero saber (e acredito que a maioria dos leitores) é o que é arquitetura de microserviços. Poderia explicar?
Thomas:Não há problema. A arquitetura de microsserviços é uma forma de construir código em múltiplas partes ou repositórios. Podemos dizer que dividimos a forma como construímos o código em múltiplas instâncias ao invés de construir um grande bloco de código.
Priscila:Interessante. Então isso significa que a equipa de desenvolvimento constrói peças de código independentes que se encaixam no resto do software, certo? Mas nem sempre foi assim no Easy LMS. Porque é que a equipa de desenvolvimento viu a necessidade de mudar a forma como constrói o código? O que é que levou a isso? Era uma nova tendência ou algo do género?
Thomas:Sim, é uma tendência, mas essa não foi a principal razão. Nós sempre soubemos sobre a arquitetura de microservice. Mas no início, construímos o Easy LMS como grandes pedaços de código, ou o que é chamado de monólito. Quando começámos a crescer como empresa, tivemos muito mais tráfego no sítio Web, o que criou muitos problemas, como páginas que não respondiam e bugs. Percebemos que precisávamos de mudar a forma como construímos o código para que o sítio Web se pudesse ajustar e escalar automaticamente.
É como ter uma "grande fábrica" que fica facilmente sobrecarregada com muito trabalho. Percebemos que tínhamos de construir algumas "fábricas mais pequenas" para tratar de outras partes do trabalho
Descobrimos que algumas partes do código não eram práticas e que podíamos melhorá-las. Depois pensámos que era mais fácil executar as melhorias em pequenas partes em vez de as assumir como um projeto gigante. É como ter uma "grande fábrica" que fica facilmente sobrecarregada com muito trabalho. Percebemos que tínhamos de construir algumas "fábricas mais pequenas" para tratar de outras partes do trabalho.
Priscila:Pode dar um exemplo de algo que construímos numa arquitetura de microsserviços?
Thomas: Um exemplo recente de um microsserviço que implementámos é a nova função de exportação da sessão de exame e dos dados dos participantes. Fizemo-lo nos últimos dois ciclos. As exportações antigas eram executadas na nossa antiga "grande fábrica" juntamente com várias coisas e não eram optimizadas.
Poderíamos criar uma "pequena fábrica" especializada na criação destas novas exportações. Com as exportações, deparámo-nos com muitos problemas. Por exemplo, quando os clientes tinham demasiados dados para exportar, os seus pedidos sobrecarregavam o sistema principal. Agora que temos um serviço separado para as exportações, estas podem funcionar sem problemas. Na verdade, criámos um código para as exportações e outro para informar os administradores de que as suas exportações estão prontas. São unidades autónomas, não são grandes pedaços.
Priscila: Fixe! Existem outras partes do Easy LMS que construímos com arquitetura de microsserviço?
Thomas:Sim, existem. Um dos mais interessantes é o novo design da Academia. Construímos a nova Academia com React, que é uma estrutura para a construção de interfaces. Construímo-la a partir da arquitetura antiga (o monólito), pegámos em partes desse pedaço e criámos uma parte autónoma. Também criámos uma API (interface de programação de aplicações) para obter dados a apresentar na interface. Agora temos duas partes autónomas: a que vai buscar os dados e a que mostra esses dados. Elas são menores e mais fáceis de manter.
Priscila:Ok, com base no que você me disse, ainda temos algum código antigo. É um problema o facto de termos agora dois tipos de código no sistema?? Há planos para actualizá-lo?
Thomas:Não, não é um problema. É um processo. Nós construímos as primeiras partes do sistema usando o método de "grandes pedaços de código". Há planos para os substituir. Mas os clientes não notam a diferença. Construímos o novo código de forma a que possa funcionar sem problemas com o código antigo.
Priscila:Entendido. Então, como desenvolvedor, o que você prefere? É mais fácil ou mais complicado construir código com arquitetura de microserviços em comparação com o processo anterior?
Thomas:Sim, é muito mais fácil pensar em pequenas partes e manter o novo código. Estamos a considerar atualizar a interface do participante no futuro, para que funcione melhor em combinação com a Academia e com ela própria. Se a construirmos com uma arquitetura de microsserviços, será muito mais fácil acrescentar funcionalidades porque podemos trabalhar em cada parte individualmente.
Priscila:Então, como é que trabalhar com microsserviços mudou a sua forma de trabalhar?
Thomas:Podemos desenvolver mais rápido e melhor. Os microsserviços nos ajudam a manter o site e nos permitem lançar coisas mais rapidamente.
Também podemos decidir a melhor maneira de concluir um trabalho porque cada parte do código é uma unidade independente. Isso significa que podemos determinar a linguagem de programação que queremos usar e o tipo de serviço que queremos executar.
Quando utilizávamos o sistema antigo, se quiséssemos atualizar uma compilação utilizando uma determinada linguagem, tínhamos de continuar a construir o código nessa linguagem. Agora podemos escolher entre diferentes linguagens com base no que achamos melhor para essa funcionalidade. Trabalhamos em equipas. Se começarmos um novo microserviço, exploramos as nossas opções e depois decidimos o que funciona melhor para nós. Isso dá-nos mais opções.
Priscila: Isso afeta tocar em partes indesejadas do sistema, como, por exemplo, quando você tenta resolver um problema e acaba criando outro (como um bug)?
Thomas:Sim, mesmo há um ano atrás, quando tentávamos resolver coisas que envolviam muito código, acabávamos por trabalhar em demasiadas coisas desnecessárias. Por exemplo, se íamos resolver X, resolvíamos Y e depois criávamos o bug Z. Trabalhar com microserviços reduziu esse problema.
Priscila:Ok. Vejo que a arquitetura de microserviços facilita o trabalho da equipe de desenvolvimento. Mas como isso afeta nossos clientes e seus participantes?
Thomas: Bem, como eu disse, os clientes não percebem (e não deveriam perceber) diferentes partes do código. Tudo deve trabalhar junto para criar uma experiência suave. Os clientes podem se beneficiar porque agora podemos lançar novas funcionalidades mais rapidamente e melhorar com base no feedback deles.
Trata-se de uma mudança drástica em relação à forma como fazíamos as coisas anteriormente. Por exemplo, quando lançámos o novo painel de administração da Exam, demorámos cerca de seis meses de desenvolvimento até lançarmos tudo de uma só vez. Se os clientes gostassem ou odiassem, não havia volta a dar (felizmente, eles adoraram?). Agora, mudámos a forma como criamos e lançamos novas funcionalidades.
O novo Criador de cursos, por exemplo, foi lançado pela primeira vez como um recurso Beta. Construímo-lo com React e lançámo-lo pouco a pouco, acrescentando novas funcionalidades menores até ter todas as funcionalidades para substituir o antigo criador de cursos na sua totalidade. Entretanto, pudemos ver o que funcionava, como os clientes o utilizavam, melhorá-lo, iterá-lo e depois fazer alterações. Isso não teria sido possível com grandes blocos de código lançados de uma só vez.
Priscila: Isso faz muito sentido. Pelo que me lembro, isso se alinha com os princípios do Kata de Melhoria da Toyota que aplicamos na empresa. É melhor fazer um protótipo, obter feedback e melhorar a funcionalidade em vez de gastar muito tempo sem saber como os clientes o vão receber. Obrigado por me acompanhar nesta entrevista!
Thomas:Sim, acho que isso funciona melhor. Espero ter conseguido esclarecer como funciona a nossa equipa de desenvolvimento no Easy LMS! De nada.
