Elegir serverless: la historia de migración de Babbel

Por Equipo editorial da AWS

¿Quién es Babbel?

Babbel es todo un ecosistema de ofertas de aprendizaje de idiomas, incluida la aplicación de aprendizaje de idiomas más vendida del mundo. Con más de 10 millones de suscripciones vendidas y más de 60.000 cursos para 14 idiomas, creamos el destino número uno para estudiantes de idiomas en todo el mundo. Llevamos ejecutando nuestra plataforma en Amazon Web Services (AWS) desde el primer día con el lanzamiento de nuestro producto en 2007 y, con frecuencia, somos los primeros en adoptar las nuevas ofertas de servicios de AWS. Dado que nuestro ecosistema de aprendizaje Babbel es puramente digital, depende en gran medida de la tecnología subyacente, que se espera que no solo sea confiable y estable, sino también escalable en cualquier momento. Esto conlleva desafíos y oportunidades a lo largo del camino, especialmente a medida que la oferta de productos crece y el panorama de servicios cambia.

Babbel ha estado ampliando nuestra base de alumnos de forma constante y nuestro tráfico ha aumentado posteriormente desde el año 2007-2020. Durante 2020, la base de estudiantes de Babbel creció sustancialmente con un aumento de dos a tres veces en el tráfico de EE. UU. y nuestros principales mercados europeos. Con las diferentes regulaciones mundiales a las que se enfrenta la pandemia, muchas personas optaron por aprender un nuevo idioma o mejorar sus habilidades lingüísticas. Esto creó picos adicionales en el tráfico entrante que no se habían producido antes a esta escala. Durante todo esto, no nos preguntamos si nuestra infraestructura alguna vez se vería desafiada por las demandas cambiantes de los usuarios.

Sin embargo, antes de 2020, la plataforma que creamos en Babbel que alojaba los servicios de Babbel no aprovechaba todos los servicios sin servidor de AWS. Se basaba en una pila antigua que se ejecutaba en AWS OpsWorks, que ya no encajaba bien para lo que se necesitaba. En este artículo, describimos qué llevó a Babbel a pensar en el cambio, las opciones que tuvimos en cuenta y cómo finalmente migramos nuestras cargas de trabajo de producción a Amazon ECS en AWS Fargate y AWS Lambda.

¿Por qué cambiar nuestra arquitectura?

Al estar en un entorno dinámico y en constante crecimiento, estamos motivados para cambiar y mejorar las cosas. Lo que buscamos son oportunidades en las que las mejoras proporcionen una experiencia de aprendizaje mejorada para nuestros alumnos. Como puede imaginar, priorizar los temas técnicos no siempre se traduce fácilmente en una mejor experiencia del estudiante, pero hay algunos pilares que tomamos como indicadores:

Aceleración de la velocidad de desarrollo y
Reducir el trabajo de mantenimiento
Tener y mantener un entorno actualizado
Mejorar los tiempos de entrega de funciones

Antes de comenzar el proyecto, ejecutábamos una versión antigua de OpsWorks, que requería que usáramos una versión desactualizada de Chef para administrar la configuración de las instancias EC2 de OpsWorks. Estas instancias se basaban en un tipo de instancia anterior y utilizaban una versión de Ubuntu que se acercaba al final de su ciclo de lanzamiento, por lo que era necesario tomar medidas. La actualización de los libros de cocina de Chef a una nueva versión de Chef, la actualización de la versión de Ubuntu y la actualización de las antiguas instancias de OpsWorks EC2 habrían llevado una cantidad considerable de tiempo. Además, nuestros tiempos de implementación, reversión y actualización estaban consumiendo muchas horas de trabajo de mantenimiento de los desarrolladores, que queríamos reducir. En el caso de picos de tráfico rápidos, tuvimos tiempos de escalado más largos de lo que nos hubiera gustado y el escalado automático no era confiable. En algunos casos, se tardó hasta 25 minutos en agregar instancias de EC2 adicionales al clúster de OpsWorks. Para el equilibrio de carga, nos limitamos a usar ELB clásico, que no tenía todas las funciones que nos hubiera gustado usar, como Autenticación a través de Cognito y Enrutamiento. Estas funciones estaban disponibles en los balanceadores de carga de aplicaciones (ALB), pero OpsWorks no admitía las ALB en ese momento. Dadas estas circunstancias, llegamos a la conclusión de que la solución ideal debía abordar estos temas, lo que significaba que teníamos que alejarnos de nuestra configuración de OpsWorks EC2.

Considerar las opciones de migración

Antes de analizar las posibles soluciones técnicas, analizamos cuál era la solución ideal para nosotros desde la perspectiva de las funciones. Acordamos que, idealmente, la solución debería

Se integra bien con nuestra arquitectura de AWS existente y con nuestra inversión y estructura de Terraform
Estar activamente desarrollado y actualizado con un equipo de servicio y soporte dedicado
Liberar tiempo operativo y de mantenimiento para permitirnos trabajar en las cosas que aportan más valor a los alumnos o a los equipos de ingeniería de Babbel

Para nosotros estaba claro que la solución era ir sin servidor. Se procedió a analizar las soluciones disponibles para abandonar OpsWorks y reemplazar toda la capa informática y de alojamiento. Las opciones que consideramos fueron:

AWS Lambda
Amazon Elastic Container Service (Amazon ECS)
Servicio Amazon Elastic Kubernetes (Amazon EKS)

Llegamos a las siguientes conclusiones sobre estas opciones:

AWS Lambda

Idealmente, ejecutaríamos casi todo en Lambda. El escalado está automatizado de forma predeterminada, sin necesidad de configuración, no hay instancias que mantener, no hay actualizaciones de SO y seguridad que tenemos que hacer nosotros mismos en la capa del sistema operativo, y las implementaciones y la reversión son instantáneas. Para algunos de los servicios, esto fue posible y tomamos la decisión de usar Lambda para ellos. Sin embargo, decidimos que Lambda no sería la solución adecuada para todos nuestros servicios. Teníamos algunos servicios multipropósito que requerían Docker y, en el momento de nuestra evaluación a principios de 2020, la compatibilidad de Lambda con el formato de imagen de contenedor aún no era una característica.

Amazon ECS

Como Lambda no era una opción para este tipo de servicios, tuvimos que tomar una decisión sobre qué plataforma ejecutar nuestros contenedores (Docker). Evaluamos Amazon EKS y Amazon ECS y pudimos elegir entre las cuatro opciones siguientes:

ECS en EC2
ECS en Fargate
EKS en EC2
EKS en Fargate

Como el uso de ECS en Fargate y ECS en EC2 son muy similares, eran una solución alternativa para todo el ecosistema en comparación con Kubernetes y EKS (en EC2 o Fargate), por lo que sopesamos los pros y los contras del uso de cualquiera de los dos conjuntos tecnológicos. En 2019, se lanzó la ejecución de ECS en Fargate e inicialmente se perdieron algunas funciones que necesitábamos en ese entonces (por ejemplo, etiquetas de asignación de costos para contenedores). Nuestros gerentes de cuentas de AWS nos ayudaron con nuestras solicitudes de funciones y estas funcionalidades se implementaron posteriormente. Una vez que se lanzaron las funciones, no hubo impedimentos para que trasladáramos todos nuestros servicios recién acoplados a ECS en Fargate. Entre EC2 y Fargate, Fargate era una mejor opción para nuestra arquitectura, ya que eliminaba el esfuerzo de mantenimiento de las máquinas EC2 subyacentes. Esta pila tecnológica también era fácil de integrar con los demás servicios de AWS y con nuestra base de código de Terraform, que ya teníamos experiencia en la gestión.

Amazon EKS

Al sopesar los pros y los contras de ejecutar EKS, decidimos que no era necesario para nuestro caso de uso y la configuración de la infraestructura. Nuestro objetivo principal era tener una plataforma que escalara nuestros contenedores Docker con el menor esfuerzo posible y con el menor número de cambios en el resto de nuestro entorno y nuestra integración de servicios de AWS. Además, queríamos asegurarnos de que la cantidad de trabajo operativo fuera mínima, ya que no aporta ningún valor a nuestros alumnos. Con Kubernetes, pensamos que tendríamos una curva de aprendizaje más pronunciada, que tendríamos que hacer más cambios en nuestro entorno actual y tener más trabajo operativo y de mantenimiento. Pensamos que podríamos tener una mejor separación entre el desarrollo y la infraestructura con una infraestructura más centrada en AWS como código, que gestionamos a través de Terraform (un ejemplo de esto sería usar AWS IAM). En resumen, queríamos cambiar nuestro panorama informático y de hospedaje sin tener que hacer una adaptación mayor de nuestros sistemas y servicios y la configuración de cómo ejecutamos las implementaciones, administramos nuestras redes, grupos de seguridad, etc.

En 2019/principios de 2020, EKS seguía siendo un servicio más nuevo. En ese momento, nuestra decisión de no adoptar EKS (o Kubernetes) era una preocupación por la compatibilidad con las funciones de Kubernetes que se ejecutan en AWS. Si bien EKS usa el código original de Kubernetes (sin modificaciones), nuestra preocupación era la diferencia entre las últimas versiones de Kubernetes y las versiones disponibles con EKS. En ese momento, no estábamos seguros de si tendríamos acceso inmediato a todas las funciones más recientes de Kubernetes. En este caso, no tuvimos problemas con respecto a una característica en particular y decidimos que queríamos optar por un servicio que diera prioridad a AWS, en lugar de un servicio de código abierto administrado por AWS. Sin duda, el uso de Kubernetes tiene muchas ventajas, como poder ejecutar un entorno de nube híbrida con un control más detallado, pero eso no era importante para nosotros. En resumen, por las razones mencionadas anteriormente, decidimos usar ECS en lugar de EKS (por lo que no comparamos si deberíamos ejecutar EKS en EC2 o Fargate).

Migración de las cargas de trabajo

Como teníamos experiencia previa en la ejecución de AWS Lambda, la migración inicial de los servicios de AWS OpsWorks a AWS Lambda se realizó rápidamente y sin ningún problema imprevisto. Como no teníamos ninguna experiencia con AWS Fargate, tuvimos que dockerizar todos los servicios restantes antes de empezar con la migración a AWS Fargate. Además de los desafíos técnicos que tuvimos que superar debido a la falta de experiencia en este tipo de migración, se requirió mucha coordinación entre equipos, ya que la migración afectó a más de 10 servicios, tanto de cara al cliente como de servicios internos. Naturalmente, los primeros servicios fueron los que llevaron más tiempo, ya que tuvimos que averiguar cuál era la mejor manera de realizar las implementaciones, ajustar nuestro escalado automático y asegurarnos de que la migración de los servicios a Docker funcionara según lo previsto. Primero comenzamos a migrar los servicios internos que no tenían impacto en el producto, continuamos con los servicios internos que sí tenían impacto en los clientes y terminamos con los servicios orientados al cliente al final. La configuración final ahora varía, porque nuestros servicios tienen diferentes integraciones y entornos (es decir, a veces usamos AWS Cognito con las ALB o tenemos CDN delante de las ALB, etc.). Aquí hay una comparación simplificada de antes/después que se ilustra a continuación:

Conclusión

Una vez completados los cambios técnicos de nuestro proyecto, llegó el momento de evaluar si habíamos alcanzado nuestros objetivos. En resumen, los puntos problemáticos iniciales fueron:

Alto esfuerzo de mantenimiento de OpsWorks/Chef/EC2, dedicando un tiempo de desarrollo significativo al mantenimiento en lugar de mejorar la aplicación para los clientes
Escalado poco fiable con un tiempo de calentamiento prolongado de más de 20 minutos debido a la pila subyacente de OpsWorks y Chef
Una configuración con OpsWorks que no podía usar balanceadores de carga de aplicaciones, que tenía características que queríamos usar

Con el cambio a Amazon ECS en AWS Fargate y AWS Lambda, obtuvimos los siguientes beneficios:

Lanzamientos y tiempos de reversión más rápidos con tiempos de mantenimiento reducidos, lo que nos permite centrarnos en crear nuevas funciones para nuestros alumnos. Pasamos de tiempos de implementación de 25 a 30 minutos por clúster de OpsWorks a implementaciones y reversiones casi instantáneas con AWS Lambda y Amazon ECS en AWS Fargate.
Escalabilidad automatizada rápida en comparación con nuestra configuración anterior. Esto resultó útil cuando el rápido e inesperado aumento del tráfico en marzo de 2020 produjo picos de demanda durante todo el día y en todo el mundo.
Usar un servicio de AWS que hemos integrado junto con otros servicios de AWS para diferentes fines, como integrar escaneos de seguridad como parte de nuestro proceso de lanzamiento mediante el escaneo de imágenes de Amazon ECR o la autenticación directa a través de ALB
Reducción de costos como efecto secundario de utilizar nuestras cargas de trabajo informáticas de una manera más eficiente. Lo hemos descrito en detalle en https://www.babbel.com/en/magazine/how-to-do-more-with-fewer-servers

Acerca de Babbel

Babbel se guía por una misión: Todos. Aprendizaje. Idiomas. Esto significa crear productos que ayuden a las personas a conectarse y comunicarse entre culturas. Babbel, Babbel Live y Babbel for Business utilizan idiomas en situaciones reales, con personas reales. Y funciona: estudios con la Universidad de Yale, la Universidad de la Ciudad de Nueva York y la Universidad Estatal de Michigan demuestran su eficacia. La clave es una mezcla de humanidad y tecnología. Más de 60 000 lecciones en 14 idiomas están elaboradas a mano por más de 150 lingüistas, y los comportamientos de los usuarios se analizan continuamente para dar forma y ajustar la experiencia del estudiante. Desde las sedes de Berlín y Nueva York, 750 personas de más de 60 nacionalidades representan todas las diferencias que hacen que los seres humanos sean únicos. Babbel es la aplicación de aprendizaje de idiomas más rentable del mundo, con más de 10 millones de suscripciones vendidas. Para obtener más información, visite www.babbel.com o descargue las aplicaciones en App Store o Play Store.

Este artículo fue traducido del Blog de AWS em Inglés.

Acerca del autor

Gyorgi Stoykov MSc. es gerente sénior que trabaja en el equipo de Infraestructura de Babbel, actualmente con sede en Berlín. Tiene una amplia experiencia en computación e infraestructura en la nube en una variedad de entornos que van desde empresas Fortune 500, empresas emergentes y el mundo académico. Le apasionan mucho DevOps, AWS y ayudar a las organizaciones a crear productos nativos de la nube mediante la aplicación de las prácticas recomendadas de Agile y DevOps.

Blog de Amazon Web Services (AWS)