Cuando nos propusimos crear la escuela del futuro hace dos años, sabíamos que debíamos reimaginar la experiencia de aprendizaje y enseñanza.
Para lograr esto tendríamos que ser una organización nativamente digital, y esto a su vez implicaba que toda nuestra tecnología debía ser altamente disponible, escalable, mantenible y medible. Dicho de otra manera, nuestra tecnología debía ser 100% cloud-based.
Sin embargo, el modelo Hybridge requeriría mucho más que solamente servidores, almacenamiento y bases de datos. La tecnología de Hybridge habría de estar en un ciclo constante de experimentación, retroalimentación y mejora. Esto significa que necesitábamos herramientas altamente amigables para nuestros equipos de desarrollo de tecnología, y es por esta última razón que decidimos alojar nuestra infraestructura completa y operaciones de desarrollo en la nube de AWS.
Después de presentarle nuestra infraestructura y plan de transformación digital al equipo de AWS México, fuimos invitados a su programa EdStart y entrevistados como equipo tecnológico de avanzada.
Apalancados de distintos servicios de AWS logramos implementar 3 objetivos que guían y siguen guiando a nuestros equipos de desarrollo:
#1. Pensar serverlesss
Más tiempo desarrollando, y menos tiempo preocupados por infraestructura.
AWS nos permitió dar este importante paso. Hemos utilizado AWS Lambda Functions para escribir nuestros casos de uso, y creamos los puntos de entrada a estos casos de uso en AWS API Gateway. Esto ha permitido que los equipos de desarrollo backend desplieguen nuevos casos de uso en cuestión de minutos en lugar de semanas.
Además de Lambda+API Gateway tenemos clusters de contenedores Docker en AWS ECS que hacen la orquestación de los contenedores en AWS Fargate (computación serverless para contenedores). Esto nos permite lograr una capa de abstracción adicional bastante deseable (y envidiable por lo que hemos escuchado).
Incluso nuestros equipos de DevOps han logrado implementar los pipelines de CI/CD (integración continua y entrega/despliegue continuo) siguiendo nuestro mindset serverless con AWS CodePipeline, AWS CodeBuild y AWS CodeDeploy. Más acerca de esto en el punto 3.
Finalmente, usamos AWS Amplify con distribuciones AWS CloudFront para entregar nuestras nuestras aplicaciones web estáticas escritas en React u otros frameworks de Javascript.
#2. Maximizar reutilización de componentes
Esto suena trivial porque la reutilización de código y componentes es deseable en todos los proyectos y ecosistemas de software. Sin embargo, una arquitectura serverless tiene ciertos retos para la reutilización de código, y por eso nos pusimos la tarea de hacerlo prioridad en la nuestra.
Layers de AWS Lambda nos permitió solucionar justo esto. No sólo logramos simplificar la gestión de dependencias entre nuestras funciones, sino que logramos crear una arquitectura serverless tremendamente poderosa y robusta. Un ejemplo de esto es que implementamos el ORM ActiveRecord de Ruby para gestionar la persistencia en nuestros casos de uso. Esto era impensable hace no mucho tiempo en arquitecturas serverless.
#3. Simplificar procesos y mecanismos de retroalimentación para eficientar el lanzamiento de nuevas versiones
Estamos interesados en dos tipos de retroalimentación: aquella que sucede por parte de nuestros usuarios finales, y la que ocurre internamente en nuestras operaciones de desarrollo. Ésta última podía ser una retroalimentación objetiva y automatizada a través de diversas fases en un pipeline de CI/CD. Sin embargo, la retroalimentación por parte de los usuarios finales requiere de un esquema más sofisticado.
Necesitábamos una manera de poder compilar y desplegar una versión completa y funcional de nuestros proyectos cada vez que una desarrolladora hiciera un Pull Request a algún repositorio. Pudimos resolver esta necesidad combinando CodePipeline, CodeBuild y CodeDeploy (también sin tener que administrar infraestructura). De esta manera, además de los checks que ya nos da nuestro pipeline de CI/CD, podíamos tener checks de personas externas al equipo de desarrollo. Algo así como focus groups en tiempo real para cada nueva versión de nuestras tecnologías.
Por: Martín y Gerardo Mathus
