5 años de Ualá, 5 años de Lambda
Introducción
Hace cinco años lanzamos Ualá en Argentina…
Lo que inicialmente era una pequeña billetera digital, ha crecido a ser un ecosistema bancario gigante, con operaciones en múltiples países de América Latina, más de 1500 empleados y más de 5 millones de usuarios
Ha sido una locura atravesar todo este crecimiento.
En el transcurso de esos 5 años, hemos navegado por diferentes estilos arquitectónicos y hemos hecho cambios de tecnologías drásticos, como cambiar nuestro principal lenguaje de programación de Java a Go… historia para contar en otro momento.
Pero hay algo que ha perdurado desde el inicio: la gran mayoría de nuestra fuerza computacional está desplegado en AWS Lambda.
En este artículo contaré un poco la historia de por qué tomamos la decisión de usar AWS Lambda hace 6 años (antes del lanzamiento) y contaré un poco de como, indirectamente, terminó impactando en la cultura de la empresa.
La decisión inicial
En la actualidad, Lambda, o algo similar, pero de otros proveedores cloud, es visto como algo medianamente popular. Si bien los microservicios siguen dominando, los nanoservicios como Lambda han ido conquistando cada vez más terreno.
En el 2017, no era así…
Con apenas 2 años desde su lanzamiento, Lambda era casi desconocido. Era algo completamente innovador, pero todavía había mucho espacio para mejora. Era un riesgo enorme adoptarlo como nuestro componente de arquitectura principal, pero le vimos muchísimo potencial.
Siendo Ualá tan pequeña como era en ese momento (no llegábamos a 15 empleados), era el momento ideal para tomar el riesgo y probarlo. En retrospectiva, fue de las mejores decisiones que tomamos.
Desafortunadamente, no fue todo color de rosa. El viaje inicial fue rudo, y aprendimos muchas lecciones rudas en el camino.
Como Lambda era básicamente nuevo, la documentación que conseguías online no era tan extensa como ahora. Muchas veces terminé en la página 10 de Google buscando aunque sea una pista que me ayudara a resolver algún problema.
Solo hace falta mirar cómo ha crecido el tag de “aws-lambda” en StackOverflow.
Y si ni siquiera está la información en StackOverflow, menos estará en otros sitios.
Entonces, cualquier decisión de diseño que hiciéramos, no lo podíamos basar en alguna documentación o proyecto existente, porque básicamente no existían.
Cosas como el flujo de git que usamos, cómo manejar los repositorios, que CICD usamos, configuraciones, etc. Todo se tuvo que hacer desde cero.
Sin mencionar que nadie en el equipo tenía experiencia previa con Lambda, y conseguir a alguien era básicamente imposible, éramos una empresa muy pequeña.
Entonces, sabiendo todo esto, ¿por qué tomamos la decisión de todos modos?
Aún con todas las contras que liste, no era suficiente para competir con los pros y el potencial que le veíamos.
Lambda nos da la habilidad de diseñar arquitecturas basadas en eventos realmente distribuidas. Usando un enfoque orientado a funciones de responsabilidades simples y únicas.
Esto a su vez nos dio un potencial enorme en cuanto a flexibilidad, escalabilidad y encapsulamiento, y todas las palabras adicionales que emocionan a cualquier arquitecto cloud.
Otro punto positivo adicional es que, como es un servicio gestionado por AWS, no nos tenemos que preocupar por alguna configuración de la función, del SO o de la infraestructura.
5 años después del lanzamiento hay Lambdas que están desde el día 1 que no se han tenido que modificar.
Cualquier actualización que hicimos fue más por mejores arquitecturas, cambios de código, o cambios del lenguaje de programación, pero rara vez por alguna configuración.
Y eso, considerando que pasamos de 1 usuario a 5 millones, Lambda simplemente escaló… todo automático.
O, como dirían en Argentina, “Lambda se lo banca”.
Y todavía sin entrar en detalles sobre el costo…
Lambda, en ese momento, era básicamente gratis. No fue sino cuando llegamos a una cantidad considerable de usuarios que pagamos nuestro primer dólar por usar Lambda.
Inclusive ahora, teniendo docenas de cuentas de AWS, con cientos de nanoservicios cada una, con millones de usuarios usándolas activamente, Lambda es sorpresivamente barato.
¡Hasta logramos reducir el costo en 34% migrando a Graviton2!
Entonces tenemos bajo costo operativo, bajo costo de mantenimiento, menos tiempo configurando, más tiempo codeando… Lambda se vende solo.
La visión de la compañía siempre fue ser innovadora y disruptiva, ¿por qué no aplicamos esta visión a nuestra tecnología también?
Nadie en ese momento pensaría en construir todo un ecosistema solo en Lambda, así que nosotros lo hicimos.
Cómo impactó en nuestra cultura de trabajo
Tomando aprendizajes de @Matthew Skelton y Manuel Pais en el libro Team Topologies y en la Ley de Conway que dice:
“Organizations which design systems.. are constrained to produce designs which are copies of the communication structures of these organizations”.
O como parafrasea Ruth Malan
“If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.”
La organización debe ser estructurada de acorde a la arquitectura que queremos tener, no al revés.
Nosotros organizamos nuestros equipos a través de streams de negocio, donde son involucrados múltiples squads según diferentes partes de la arquitectura. Esto incluye capas de plataforma, de core (subsistemas complicados) y squads DevExp (habilitadores)
Internamente, cada equipo es restringido a un dominio, feature de negocio, o sección de la arquitectura.
Esto significa que cada equipo es responsable de una serie de Lambdas (y muchas cosas adicionales como SQS, Api Gateway, tablas de Dynamo, etc) que resuelven un problema o capa arquitectónica.
Siendo los Lambdas tan nano como son, los equipos pueden separarse en workflows específicos sin chocarse entre sí, ayudando a los equipos a ser tan granular como es posible.
Tomando eso en cuenta, claro que Lambda, y todo lo que viene con ellas, ha tenido un impacto en la cultura de nuestros equipos.
Los equipos tuvieron que ser formados y empoderados para tomar completo ownership de:
- La arquitectura que se desplegará en la nube
- El código de las funciones lambda
- La infraestructura que soporta todo
- Su pipeline de CICD
Básicamente Lambda, con ayuda de Infrastructure-as-Code (Terraform) y GitOps, ha permitido que nuestros equipos sean lo más autónomo y granular posible.
Los equipos son dueños completos de su solución, desde arquitectura, pasando por el código, por la infra, el CICD, hasta desplegar todo en producción.
Se puede debatir de que lo mismo aplica para microservicios, y si, en realidad comparten mucho en común, y no estoy discutiendo si uno es mejor que otro.
Pero, con nanoservicios, restringir los dominios de los equipos y orquestar la colaboración entre ellos parece ser más fácil y con mayor claridad que antes.
Para poner un ejemplo, las Lambdas pueden ser agrupadas por servicios (SOA), al igual que microservicios. Pero los servicios suelen cambiar con el tiempo, y cambiar una función Lambda de un agrupamiento a otro para ajustar las responsabilidades de los equipos o lifecycle del software no es gran problema.
De todos modos, esto trae en sí un desafío completamente diferente. Spotify lo describe como buscar una autonomía guiada basada en un Golden Path de prácticas recomendadas. Hay un esfuerzo adicional en transferir conocimientos, establecer buenas prácticas y en realizar capacitaciones.
También, si no se tiene especial cuidado, puedes terminar con un “distributed spaghetti” de servicios.
Pero a pesar de esto, ha hecho el camino para que nuestros equipos sean dueños completos de las features que desarrollan, desplegando muy rápida y seguidamente, rompiendo la menor cantidad de cosas posible y permitiendo que la empresa pueda escalar sin preocupaciones.
Conclusiones
Entonces, después de 5 años desde el lanzamiento de Ualá me gustaría darle las gracias a Lambda.
Pero también le doy las gracias a todo nuestro equipo de ingeniería que ha dado forma a esta cultura y ha ayudado a poner los cimientos para llegar a donde estamos hoy.
Si miro hacia atrás para comparar cómo hemos avanzado en nuestras prácticas de ingeniería, el trayecto es realmente increíble.
Esto no hubiera sido posible sin tantas personas increíbles que han ido y venido durante estos años.
Ha sido una locura, pero no cambiaría nada.
En un artículo futuro entraré más en detalle sobre algunas lecciones que estuvimos aprehendiendo en el camino de implementar Lambda.
