Growing Pains: Focalizando nuestro esfuerzo Web

Como vimos en el post anterior, para poder ser más ágiles tuvimos que repensar toda nuestra arquitectura Web, pero hay algo que no contamos: teníamos dos arquitecturas Web, una para Mobile y otra para Desktop.

En 2019 comenzamos la construcción de una nueva aplicación Web Mobile, arrancando desde cero, para que los usuarios puedan hacer sus pedidos de manera más ágil y segura.

Este proyecto no tenía dentro de su alcance inicial incluir su versión Desktop y así poder apagar la anterior, ya que queríamos generar impacto en un corto plazo con el lanzamiento de features pequeñas. Decidimos entonces seguir usando el proyecto anterior que habiamos heredado (de ahora en más legacy) para este tipo de layout mientras iterábamos sobre la nueva aplicación Web Mobile, hasta ser capaces de soportar todos los layouts y apagar por completo el proyecto anterior, algo que (como podrás haber notado si sos usuario de la web tradicional) finalmente sucedió.

El proceso de esta migración fue enriquecedora y comprometió a varias partes de la compañía: el equipo de desarrolladores, los equipos de UI y UX, el equipo de cloud, marketing, entre otros. A medida que íbamos avanzando en esto tuvimos cada vez más participación para alcanzar el objetivo final: una sóla Web con su arquitectura y código unificados.

Hablemos de la necesidad

¿Por qué necesitábamos discontinuar el proyecto anterior, si estaba funcional hace unos siete años? Las razones para esto fueron varias y nacieron desde distintas partes de la compañía.

Por un lado, desde lo técnico la mantenibilidad de un proyecto legacy construido en tecnología ahora obsoleta nos afectaba en puntos clave como seguridad, escalabilidad y estabilidad. Este proyecto estaba construido sobre grails, y nos daba una gran curva de entrada al tener problemas con maven viejos, dependencias obsoletas e implementaciones huérfanas. A su vez este proyecto legacy no se adaptaba a los planes de crecimiento que teníamos, apuntando a una arquitectura de micro frontends. (explicado en este post).

Por otro lado, desde el punto de vista de producto, querer implementar una feature o hacer un cambio en la web significaba hacerlo en dos ecosistemas totalmente diferentes, algo que no solo afectaba a los desarrolladores al tener que implementar algo en dos lugares completamente distintos, sino que también atenta contra los valores de la compañía, ya que significaba retrasos en los entregables.

El desafío

El mayor desafío era tomar un proyecto pensado como una aplicación Mobile con casi dos años de antigüedad, robustez y en constante crecimiento, para transformarlo en una aplicación que soporte también el layout Desktop con todo el cambio que eso implica.

Las bases de este desafío que teníamos que tener en cuenta antes de siquiera pensar en la solución eran:

1. No podíamos parar los releases hasta tener un MVP a probar.
2. No podíamos involucrar a todos los equipos para repensar cada parte de la aplicación web desktop por el objetivo a ‘mediano’ plazo que teníamos (final del Q3 del 2020). Tenía que ser algo casi ‘gratis’ para el resto de los equipos, para no interferir en sus propios objetivos.
3. No podíamos ir detrás de cada parte de la aplicación y migrarla una a una porque la agilidad de la empresa haría que el resto de los equipos agreguen cambios y features más rápido de lo que nosotros pudiésemos migrar (y sin pensar en los conflictos).
4. Tenía que convivir en paralelo con la migración a la nueva arquitectura de micrositios.

Cómo lo hicimos

Sabiendo todo esto antes mencionado, empezamos a definir cómo llevar a cabo este proyecto. Partimos el scope en tres grandes aristas:

1. Definiciones
2. UX & UI
3. Releases silenciosos

Para la parte de definiciones, después de indagar en bibliografía y ver distintos caminos que se recomendaban tomar, nos dimos cuenta que necesitábamos una estrategia bastante propia por lo que mencionamos antes: la web mobile fue pensada para ser mobile, y la lógica del negocio promovía que muchas cosas fueran exclusivas para un layout u otro (no era solo cuestión de ajustar estilos). Tengamos en cuenta que la aplicación de PedidosYa también es 100% móvil.

También comenzamos a reunirnos e iterar con el equipo de UX & UI para indagar y probar distintos alcances del nuevo layout. Definimos dos conceptos importantes que nos permitieron avanzar rápido en las iteraciones: un nuevo layout para la versión desktop, reubicando los componentes y reutilizando todo lo hecho en móvil. Y por otra parte definimos una nueva manera de manejar la navegación entre páginas manteniendo también todo lo mobile. Con estas dos definiciones podíamos ajustar la navegación sin desaprovechar el nuevo espacio disponible hasta que cada equipo sea capaz de ajustar sus flujos. Sabíamos qué y cómo queríamos que se comporte la web en distintos layouts.

Tipo de layout a mostrar según el dispositivo utilizado

En paralelo y antes de comenzar la etapa de desarrollo definimos el way of work. En este punto decidimos que la evolución de este proyecto tenía que darse en forma paralela, gradual y armonizada al constante crecimiento que caracteriza a PedidosYa, y así evitar un gran punto de merge donde todo el desarrollo sería volcado al final del camino (con todos los conflictos que nos daría por lo mencionado anteriormente).

Por eso, el nuevo layout iría tomando forma en los ambientes de testing, y todo el código relacionado estaría también en producción pero invisible al usuario final, haciendo silent releases de forma gradual y en constante retroalimentación con distintos equipos a medida que se avanzaba y validaba.

Esto se tradujo al final del recorrido en muchos y pequeños pull requests en distintos repositorios de PedidosYa, en un lapso de seis meses hasta tener un producto listo para encender en producción, con todo el código ya productivo y validado por las diferentes partes. Solo nos restaba encender el proyecto para que vea la luz, algo que nos daba la seguridad de que no estábamos afectando la estabilidad de la aplicación ya que todo el proceso fue gradual y no un gran merge.

Cómo lo lanzamos

La oportunidad para lanzar este nuevo proyecto surgió cuando nos expandimos a nuevos mercados a principios de 2021. Decidimos que no íbamos a salir en países nuevos con la web legacy dado que consideramos que teníamos la suficiente madurez para probar la web como único proyecto para ambos layouts.

Entonces, después de 6 meses de trabajo, en febrero de 2021 salimos con la versión Desktop en un mercado con mucho tráfico como Perú. Después de una semana, alrededor del 25% de las transacciones por la aplicación web se hacían a través de la nueva desktop, sin ningún issue que nos obligue a hacer rollback y con tráfico suficiente para detectar ajustes necesarios para seguir iterando el proyecto.

A partir de ese entonces, fuimos incrementando el rollout del proyecto en nuevos mercados que sumamos y en países donde ya estábamos con el proyecto legacy (como Argentina), hicimos un rollout gradual comparando la performance y CVR entre ambas, hasta que finalmente logramos discontinuar el anterior.

Cómo nos fue

Pasados casi 4 meses desde el rollout definitivo de la nueva versión de la web desktop, fuimos y seguimos retroalimentando el proyecto en base al uso de los usuarios en producción.

Desde el punto de vista de infraestructura en la nube, la ejecución de la vieja arquitectura significaba tener instancias que consumían 4 GB de memoria desde el momento de su encendido, con una inicialización lenta que nos impedía escalar rápidamente ante subas repentinas de tráfico.

Por otro lado, pudimos sacar de nuestro stack una tecnología deprecada cuya comunidad está prácticamente extinta algo que reduce potenciales problemas de seguridad. (Se podrán imaginar lo problemático que sería si estuviésemos corriendo la Web con una vulnerabilidad como la de Log4J)

En cuestiones de desarrollo, aumentamos la velocidad de entrega para los equipos, ya que cualquier feature o a/b test que queremos hacer lo podemos hacer en un único lugar con el mismo stack de tecnología. A su vez, a nivel producto abrimos un abanico de posibilidades al tener disponible este nuevo layout sin trabas técnicas que nos impidan desarrollar nuevas y mejores features para los usuarios.

Sabemos que debemos mejorar y continuamos iterando, pero este paso era necesario para poder eliminar una gran deuda técnica que nos impedía avanzar.

Nos encantaría conocer tu opinión, los leemos!