Se hace mucho trabajo entre bastidores para que nuestro LMS esté disponible online para ti. Poner todo junto requiere mucho trabajo de desarrollo.
Muchas cosas han cambiado desde que la empresa empezó a construir Easy LMS. ¿Le gustaría saber más? Nuestra búho de marketing Priscila entrevistó a uno de nuestros desarrolladores para saber cómo construimos Easy LMS utilizando una arquitectura de microservicios, qué significa y cómo afecta al trabajo que hacemos como equipo y a los usuarios finales..
Priscila: ¡Gracias por acompañarme en esta entrevista, Tomás! Lo primero que quiero saber (y creo que la mayoría de los lectores) es qué es la arquitectura de microservicios. ¿Podrías explicarlo?
Thomas: No hay problema. La arquitectura de microservicios es una forma de construir código en múltiples partes o repositorios. Podemos decir que dividimos la forma de construir código en múltiples instancias en lugar de construir un gran bloque de código.
Priscila: Interesante. Entonces significa que el equipo de desarrollo construye piezas de código independientes que encajan con el resto del software, ¿no? Pero no siempre fue así en Easy LMS. ¿Por qué el equipo de desarrollo vio la necesidad de cambiar la forma de construir el código? ¿Qué les llevó a ello? ¿Era una nueva tendencia o algo así?
Thomas: Sí, es una tendencia, pero esa no fue la razón principal. Siempre supimos de la arquitectura de microservicios. Pero al principio, construimos Easy LMS como grandes trozos de código, o lo que se llama un monolito. Cuando empezamos a crecer como empresa, tuvimos mucho más tráfico en el sitio web, lo que creó muchos problemas, como páginas que no respondían y errores. Nos dimos cuenta de que necesitábamos cambiar la forma en que construimos el código para que el sitio web pudiera ajustarse y escalar automáticamente.
Es como tener una "gran fábrica" que se abruma fácilmente con mucho trabajo. Nos dimos cuenta de que teníamos que construir algunas "fábricas más pequeñas" para manejar otras partes del trabajo.
Descubrimos que algunas partes del código no eran prácticas y que podíamos mejorarlas. Entonces pensamos que era más fácil ejecutar las mejoras como trozos más pequeños en lugar de asumirlas como un proyecto gigante. Es como tener una "gran fábrica" que se abruma fácilmente con mucho trabajo. Nos dimos cuenta de que teníamos que construir algunas "fábricas más pequeñas" para gestionar otras partes del trabajo.
Priscila:¿Puedes poner un ejemplo de algo que hayamos construido en una arquitectura de microservicios?.
Thomas: Un ejemplo reciente de microservicio que hemos implementado es la nueva función de exportación para la exportación de sesiones de examen y la exportación de datos de los participantes. Lo hicimos en los dos últimos ciclos. Las antiguas exportaciones se ejecutaban en nuestra antigua "gran fábrica" junto con múltiples cosas y no estaban optimizadas.
Podríamos crear una "pequeña fábrica" especializada en crear estas nuevas exportaciones. Con las exportaciones, nos encontramos con muchos problemas. Por ejemplo, cuando los clientes tenían demasiados datos que exportar, sus peticiones desbordaban el sistema principal. Ahora que tenemos un servicio independiente para las exportaciones, éstas pueden funcionar sin problemas. De hecho, hemos creado un código para las exportaciones y otro para informar a los administradores de que sus exportaciones están listas. Son unidades autónomas, no grandes trozos.
Priscila: ¡Genial! Hay alguna otra parte de Easy LMS que hayamos construido con arquitectura de microservicios?
Thomas: Sí, las hay. Una de las más interesantes es el nuevo diseño de la Academia. Construimos la nueva Academia con React, que es un framework para construir interfaces. Lo construimos a partir de la arquitectura antigua (el monolito), cogimos piezas de ese trozo y creamos una parte autocontenida. También creamos una API (interfaz de programación de aplicaciones) para obtener datos que mostrar en la interfaz. Ahora tenemos dos partes autónomas: una para obtener datos y otra para mostrarlos. Son más pequeñas y más fáciles de mantener.
Priscila: Vale, en base a lo que me has dicho, todavía tenemos código antiguo. ¿Es un problema que ahora tengamos dos tipos de código en el sistema?? ¿Hay planes para actualizarlo?
Thomas: No, no es un problema. Es un proceso. Construimos las primeras partes del sistema utilizando el método de "grandes trozos de código". Hay planes para sustituirlos. Pero los clientes no notan la diferencia. Construimos el nuevo código de forma que pueda funcionar sin problemas con el antiguo.
Priscila: Entendido. Entonces, como desarrollador, ¿qué prefieres? Es más fácil o más complicado construir código con arquitectura de microservicios comparado con el proceso anterior?
Thomas: Sí, es mucho más fácil pensar en pequeños trozos y mantener el nuevo código. Estamos considerando actualizar la interfaz del participante en el futuro, para que funcione mejor en combinación con la Academia y consigo misma. Si lo construimos con arquitectura de microservicios, será mucho más fácil añadir características porque podremos trabajar en cada parte individualmente.
Priscila: Entonces, ¿cómo ha cambiado tu forma de trabajar con los microservicios?
Thomas: Podemos desarrollar más rápido y mejor. Los microservicios nos ayudan a mantener el sitio web y nos permiten lanzar cosas más rápidamente.
También podemos decidir la mejor manera de completar un trabajo porque cada pieza de código es una unidad autónoma. Eso significa que podemos determinar qué lenguaje de programación queremos utilizar y qué tipo de servicio queremos ejecutar. .
Cuando usábamos el sistema antiguo, si queríamos actualizar una compilación usando un determinado lenguaje, teníamos que seguir construyendo el código en ese lenguaje. Ahora podemos elegir entre diferentes idiomas en función de lo que pensamos que es mejor para esa característica. Trabajamos en equipo. Si empezamos un nuevo microservicio, exploramos nuestras opciones y luego decidimos qué nos conviene más. Nos da más opciones.
Priscila: ¿Afecta eso a tocar partes no deseadas del sistema, como, por ejemplo, cuando intentas resolver un problema y acabas creando otro (como un bug) .
Thomas: Sí, incluso hace un año, cuando intentábamos resolver cosas que implicaban mucho código, acabábamos trabajando en demasiadas cosas innecesarias. Por ejemplo, si íbamos a resolver X, resolvíamos Y y luego creábamos el error Z. Trabajar con microservicios ha reducido este problema.
Priscila: Ok. Veo que la arquitectura de microservicios facilita el trabajo al equipo de desarrollo. Pero, ¿cómo afecta a nuestros clientes y a sus participantes?.
Thomas: Bueno, como ya he dicho, los clientes no notan (ni deberían notar) las diferentes partes del código. Todo debería funcionar conjuntamente para crear una experiencia fluida. Los clientes pueden beneficiarse porque ahora podemos lanzar nuevas funciones más rápido y mejorar basándonos en sus comentarios.
Es un cambio drástico respecto a cómo hacíamos las cosas antes. Por ejemplo, cuando lanzamos el nuevo panel de administración de Exam, nos llevó unos seis meses de desarrollo hasta que lo lanzamos todo de una vez. Si a los clientes les gustaba o no, no había vuelta atrás (por suerte, les encantó...). Ahora hemos cambiado la forma de crear y lanzar nuevas funciones.
El nuevo constructor de cursos, por ejemplo, se lanzó por primera vez como una función Beta. Lo construimos con React y lo liberamos poco a poco, añadiendo nuevas características menores hasta que tuvo todas las funcionalidades para reemplazar al antiguo constructor de cursos en su totalidad. Mientras tanto, pudimos ver qué funcionaba, cómo lo usaban los clientes, mejorarlo, iterarlo y luego hacer cambios. Eso no habría sido posible con grandes trozos de código lanzados a la vez.
Priscila: Eso tiene mucho sentido. Por lo que recuerdo, se alinea con los principios de la Kata de Mejora de Toyota que aplicamos en la empresa. Es mejor hacer un prototipo, obtener feedback, y mejorar la característica en lugar de gastar mucho tiempo sin saber cómo lo recibirán los clientes. Gracias por acompañarme en esta entrevista.
Thomas: Sí, creo que eso funciona mejor. ¡Espero haber podido arrojar algo de luz sobre cómo trabaja nuestro equipo de desarrollo en Easy LMS! De nada.
