junio 13, 2023

Cómo Applivery ha migrado a GCP Madrid para mejorar la escalabilidad y la seguridad

/
/
/
Cómo Applivery ha migrado a GCP Madrid para mejorar la escalabilidad y la seguridad

Nuestros orígenes

Como muchas startups, Applivery nació como un “side-project”. Se trataba de un servicio sencillo pero ambicioso, centrado en la distribución de aplicaciones móviles de forma eficaz y simplificada.

Dados sus humildes orígenes, los costes del servicio debían estar muy controlados, por lo que decidimos empezar desplegando las primeras versiones en el proveedor Cloud más asequible y sencillo del momento, DigitalOcean, y utilizar también un sistema de almacenamiento sencillo basado en AWS S3.

El servicio se concibió originalmente como un único monolito cuyos procesos, bases de datos y servicios se ejecutaban en un único droplet.

digitalocean and aws

Sin embargo, aquel proyecto sencillo pero ambicioso se convirtió poco a poco en una plataforma que debía dar soporte a decenas de clientes y miles de usuarios activos diarios. Además, la ambición del proyecto empezó a incorporar numerosas ideas de desarrollo, lo que dio lugar a una extensa hoja de ruta que se extendería durante los 2 años siguientes. Desarrollar un producto de esas dimensiones en un único droplet empezaba a no parecer tan buena idea. Por eso decidimos ampliar el equipo y reconstruir el proyecto desde cero.

En ese momento, decidimos pasar a una arquitectura orientada a microservicios, separando el Frontend de las APIs. Todos los servicios se desplegarían en contenedores Docker a través de un sofisticado pipeline de integración continua apoyado sobre CircleCI. En un ejercicio de simplificación del proceso de transición entre la versión antigua y la nueva, decidimos mantener DigitalOcean como proveedor de computación y DNS, pero aprovechamos la ocasión para externalizar la base datos (MongoDB Atlas), el sistema de colas (CloudAMQP), y el registro de imágenes de Docker (AWS ECR).

Este nuevo sistema de microservicios se puso en funcionamiento a finales de 2019 y hacía uso de Dokku para la orquestación de los contenedores.

digitalocean and aws

Sin embargo, aunque habíamos realizado un gran esfuerzo de reconstrucción y rearquitectura, seguíamos sirviendo todo el tráfico desde una única máquina virtual que hacía de cuello de botella. Por esa razón, poco tiempo después, decidimos dar el salto a Kubernetes.

DigitalOcean seguía siendo el proveedor Cloud más asequible para un servicio administrado de Kubernetes, así que no lo dudamos y migramos el orquestador de contenedores, añadiendo numerosas mejoras técnicas, arquitectónicas y de seguridad por el camino, entre las que cabría destacar:

Así mismo, para proporcionar el servicio de dominios personalizados en las Enterprise App Stores hacíamos uso de otra máquina virtual con una IP elástica, debido a que DigitalOcean no proveía de un NAT gateway para controlar la IP de salida de los workers.

En ese momento, la arquitectura tenía el siguiente aspecto:

Por fin habíamos logrado alcanzar una plataforma confiable, autoescalable y fácilmente mantenible, con la que poder enfocar nuestros esfuerzos en la evolución de nuestro producto.

Creciendo más rápido de lo previsto

Todo este sistema construído principalmente sobre DigitalOcean y apoyado por AWS funcionó decentemente y con unos costes muy controlados durante muchos meses. Sin embargo, a medida que el volumen de clientes crecía y en consecuencia, el tráfico, comenzamos a sufrir eventuales problemas que no podíamos controlar ni prever:

En ese momento (principios de 2021) estábamos implementando lo que sería la mayor evolución de Applivery: Applivery Device Management. Estos evolutivos nos hicieron pasar también por una arquitectura completa de nuestro dashboard de gestión y del branding de la compañía para orientarla a una mejor experiencia de usuario.

Sin embargo, a pesar de todos los esfuerzos, la infraestructura había resultado ser compleja y por momentos, inestable. Nuestros ambiciosos planes de expansión y la evolución del producto se veían gravemente penalizados por la inversión de tiempo en resolución de problemas e incidencias.

Necesitábamos tener mayor control sobre el servicio administrado de Kubernetes y era imprescindible mejorar la estabilidad de la red. Además, dada la expansión del servicio y del roadmap de producto queríamos aprovechar para continuar mejorando nuestra plataforma en los siguientes aspectos críticos para el negocio:

El salto a Google Cloud Platform

Llegados a este punto, habíamos decidido que queríamos abandonar DigitalOcean y movernos a un hyperscaler más adecuado para nuestra realidad.

Tras varias semanas de ejecución de pruebas de concepto en Amazon Web Services (AWS), Google Cloud Platform (GCP) y Azure y, a pesar de que la experiencia del equipo técnico en los ámbitos de Cloud se centraba principalmente en AWS, nos inclinamos por GCP. Los motivos fueron varios:

Mayor control sobre el servicio administrado de Kubernetes

La calidad y facilidad de uso de Google Kubernetes Engine (GKE) nos sorprendió desde el primer momento que lo probamos. La cantidad de opciones y observabilidad que ofrece por defecto sobre el cluster era la mejor que habíamos probado hasta el momento.

Mejorar la estabilidad de la red

Google nos ofrece la opción de usar su propia red con conectividad global, que proporciona mucho mejor rendimiento y latencia que la red estándar, lo que se traduce en una mejor experiencia para todos los usuarios en cualquier parte del mundo.

Reducir el número de servicios externos

Tanto AWS como GCP nos ofrecían una gran cantidad de opciones que nos permitirían internalizar algunos de los servicios externos pero debido a nuestra fuerte dependencia con el ecosistema Android, ya estábamos integrados con algunos servicios de GCP (como Pub/Sub o la Android Management API). A todo esto había que sumarle que GCP nos ofrecía otros servicios únicos como BigQuery, Analytics, Workspace o Maps que planeamos usar en el futuro cercano.

Securizar todas las conexiones

Debido a las limitaciones que experimentábamos en DigitalOcean, teníamos un amplio margen de mejora en los aspectos relativos a seguridad. Identificamos que GCP nos ayudaría en dos aspectos principales: en primer lugar, la funcionalidad de VPC peering con importación y exportación automática de rutas simplificaría en gran medida nuestra integración con MongoDB Atlas. En segundo lugar, nos ofrecía la capacidad de autenticación sin intercambio de claves desde GitHub Actions mediante Workload Identities, evitando la exposición de cualquier tipo de claves de acceso.

Incrementar la observabilidad

Anteriormente teníamos integrado Grafana y Prometheus para gestionar la monitorización y observabilidad, servicios que funcionaban dentro del cluster y que teníamos que mantener. Con GKE esto ya no era necesario, debido a que la propia consola ya ofrecía todo lo que necesitábamos, como acceso a logs, visibilidad de nodos y pods, dashboards de gráficas o alertas.

Cambiar a un región más idónea para nuestro servicio

Finalmente, GCP lanzaba su región aquí en Madrid, España (europe-southwest1), así que sigiendo nuestra marca de identidad, y tras algunas pruebas, nos decantamos por ella.. Tras las pruebas concluímos que mejoramos sustancialmente la latencia en toda América sin afectar a Europa central o el resto del mundo comparándolo con nuestra región anterior situada en Frankfurt.

¿Cómo fué?

Empezamos rehaciendo nuestras recetas de Pulumi para levantar un nuevo entorno pre-productivo completo, haciendo migraciones a múltiples servicios de GCP, entre ellos:

Así mismo, gracias a las opciones que brinda GCP, realizamos también cambios en nuestros servicios auxiliares:

Una vez tuneado y verificado todo el stack, procedimos a levantar el entorno productivo en cuestión de minutos gracias a la receta de Pulumi. Empezamos también un proceso de live migration de MongoDB Atlas a la nueva región.

Una vez listo, paramos los deployments del cluster antiguo, finalizamos el live migration en MongoDB Atlas y cambiamos los DNS en Cloudflare. Todo el tráfico ya llegaba al nuevo entorno. En total conseguimos menos de un minuto de pérdida de servicio.

¿Qué beneficios nos trajo esta arquitectura?

Tras toda la migración hemos conseguido mejorar en todos los aspectos medibles, como tiempos de respuesta, velocidad de transferencia o capacidad de procesamiento.

Seguridad

Mejora de la seguridad de la red y la intercomunicación de servicios, evitando las comunicaciones externas.

Contingencia

Mejoras en seguridad y contingencia contra ataques gracias al Firewall de CloudFlare. Alta disponibilidad (HA) multiregional gracias a GKE multi-cluster Ingress.

Rendimiento

Mejora de performance y el rendimeinto en el procesamiento de builds de hasta 2x y capacidad de paralelizar el procesamiento.

Experiencia del usuario

Mejora de la experiencia del usuario reduciendo significativamente los tiempos de respuesta de nuestros servicios. La media ha pasado de 120ms a 30ms, llegando incluso a alcanzar tiempos inferiores a 5ms en Madrid.

Tiempos de respuesta

Reducción de los tiempos de consulta y respuesta de base de datos, al encontrarse en la misma región y comunicarse a través de red privada en 2x.

Procesos CI/CD

Aceleración de los procesos de CI/CD y, en consecuencia, de nuestras capacidades de entrega continua a través de una experiencia de desarrollo más centralizada a través de GitHub.

Conclusiones

Applivery ha experimentado una evolución constante desde su nacimiento, nuevas necesidades y funcionalidades siguen desarrollándose continuamente. Siempre hemos mantenido un compromiso con la innovación, adaptándonos a los requisitos de negocio para seguir manteniéndonos a la vanguardia de la tecnología y ofrecer un servicio confiable y escalable a todos nuestros clientes.

Esta reciente iteración con GCP es la última muestra de ello, haciendo un gran esfuerzo a todos los niveles para consolidar las bases de nuestra plataforma, asegurando su solidez a largo plazo y permitiéndonos continuar innovando de forma ágil y sostenible en el tiempo.

¿Y ahora qué? ¡Chupito para el que diga IA generativa! 😀

Compartir esta publicación

Prueba Applivery gratis durante 14 días, no se requiere tarjeta de crédito

Únete a 8.000 empresas que ya disfrutan las ventajas de nuestra plataforma.

Manténte conectado

Explora todas las publicaciones

— Habla con un experto —

Programa una demo