Caso práctico de AWS: Cabify

Cabify ha trasladado toda su infraestructura tecnológica a AWS con el fin de mejorar la disponibilidad, fiabilidad y respuesta de sus operaciones. El servicio de soporte y el alineamiento cultural entre las dos empresas también son claves para el futuro despliegue de la tecnología del unicornio español.

Cabify es uno de los tres unicornios (empresas con valoración de más de mil millones de dólares EEUU) que hay en España. Nacida en 2011, cuenta con cerca de mil empleados entre España y América Latina, conectando a usuarios particulares y empresas con las formas de transporte que mejor se adaptan a sus necesidades.

Cabify es una empresa que tiene toda su infraestructura tecnológica en la nube, por lo que todas sus aplicaciones críticas, procesos digitales y de transferencia de datos dependen de su proveedor de computación en la nube. «Nuestro negocio depende de la disponibilidad de la aplicación. Si se cae, es una venta que se pierde y que nunca se recupera», expone Carlos Herrera, CTO de Cabify.

Con el fin de mejorar la fiabilidad, rendimiento y estabilidad de sus procesos tecnológicos, la empresa decidió trasladar toda su infraestructura de negocio a AWS. Herrera asegura que a nivel interno habían realizado ya mucho trabajo para mejorar las ratios y considera que «para llegar al siguiente paso tenía sentido que revisáramos qué proveedor cloud teníamos».

La infraestructura tecnológica de Cabify está compuesta por más de 700 microservicios, de los que una docena son cruciales, y cerca de 84 bases de datos relativas a ellos. Este es el aspecto más importante de la migración porque, si no funcionan estos servicios, Cabify no es capaz de ofrecer viajes y, por tanto, hacer su negocio.

Además, la empresa dispone de una gran base de datos legacy para la que sí ha sido necesario cambiar algo del código de aplicación a la hora de hacer la migración del anterior proveedor de servicios en la nube a AWS. La principal razón es que dicha base de datos está basada en una tecnología que no tiene nada que ver con la infraestructura que Cabify está desplegando en AWS. La firma espera completar la transición de los microservicios que dependen de esta base de datos legacy a la nueva arquitectura AWS en octubre de este año. A partir de ese momento, la compañía también espera avanzar y desarrollar su infraestructura, apostando por la adopción de Kubernetes como orquestador principal para la ejecución de sus microservicios.

Estos microservicios y su velocidad de respuesta son claves en el negocio de Cabify. Pablo Carranza, vicepresidente de ingeniería de Cabify, apunta que los servicios en tiempo real «tienen que responder en menos de un segundo por especificación. El 99% de las peticiones hay que resolverlas en ese tiempo y llegamos a tener 100 000 mensajes por segundo», lo que da una idea de la magnitud del real-time y disponibilidad que debe tener Cabify para ser diferencial en su negocio.

Un ejemplo de la mejora producida por el cambio es que la base de datos RDS contestaba anteriormente al 99% de las consultas en menos de dos segundos y ahora lo hace en 45 milisegundos. «Hemos quitado dos ceros al problema», resume Herrera, «lo que nos ha permitido apagar capas de caché». Además, esta mayor rapidez ha permitido eliminar piezas de código y arquitectura que se habían añadido a la base de datos para proteger a Cabify de esas «peticiones lentas».

Cabify despliega producción cada día unas 150 veces. Cuenta con 160 ingenieros encargados de desarrollar e introducir código, a los que se unen diseñadores y gerentes de producto para conformar un equipo técnico de 300 personas.

El reto de cambiar de proveedor en la nube suponía trasladar todo el negocio sin dejar de estar operativo en ningún momento. El equipo de infraestructura, formado por diez personas, tuvo que abstraer al personal técnico, especialmente los equipos de desarrollo, para que pudieran seguir realizando su trabajo sin interrupciones durante el transcurso de la migración. «Han sido los encargados de desplegar los raíles para mover los contenedores», explica Herrera, quien también alude a un pequeño desarrollo que tuvieron que hacer dos ingenieros para no perder calidad del servicio en un momento en el que Cabify tuvo las dos nubes operativas.

Durante la migración en sí, todos los equipos tuvieron que observar que no se produjera ningún incidente. «No hemos tenido que actuar en ningún momento, pero todos los días había algún ingeniero cuya única labor era comprobar que todo funcionaba».

La migración se completó sin incidentes y de manera totalmente transparente para el usuario. Tanto es así que un pasajero inició su viaje con el anterior proveedor cloud de Cabify y lo completó con AWS.

Herrera asegura que el proyecto realizado es como «cambiar el motor de un avión en pleno vuelo y que no se caiga. Nadie espera de Cabify que le diga que esta noche no estamos operativos por actualización del sistema».

Más allá de la fiabilidad, Pablo Carranza considera que en la apuesta de Cabify de elegir a AWS como socio tecnológico y de negocio tiene un papel muy importante el alineamiento cultural. «Como empresas, tenemos una particularidad común: una pata en el mundo físico y una orientación al cliente muy fuerte. Ambas preguntamos constantemente a nuestros clientes cómo podemos mejorar», explica. «Cuando tienes culturas similares y eres un partner estratégico, la conversación fluye mejor porque los ingenieros de Cabify saben cómo va a responder AWS y se anticipan también a ello».

Cabe señalar que Cabify cuenta con Enterprise Support en AWS, lo que permite la presencia de personal de AWS en los canales Slack de Cabify para responder en caso de incidencias. «En otros proveedores, tienes que abrir un ticket de soporte y esperar que alguien, al que seguramente no conoces, te responda», comentan, y califican este nivel de soporte como un «aspecto diferencial».

Cabify está trabajando, además, en trasladar toda su arquitectura basada en microservicios a Kubernetes, con el fin de ampliar su versatilidad, control operacional y abanico de funcionalidades. Los equipos de producto son capaces de desplegar entornos de prueba y simulación bajo demanda, replicando el entorno productivo con el fin de proceder a realizar los test pertinentes en un entorno seguro y totalmente funcional