7 pasos para construir una infraestructura fiable desde cero con Pomelo, una empresa fintech

El equipo de Pomelo lleva años ofreciendo servicios fintech, siempre con el compromiso de crear una infraestructura de back-end en la que los clientes puedan confiar. Cuando comenzamos, y gracias a la experiencia que muchos de nosotros ya teníamos en startups de gran éxito, queríamos aprender de todos y cada uno de los errores que habíamos visto en roles anteriores. Desde un principio, a todos nos unía la misma visión: revolucionar la industria fintech y ayudar a las empresas en América Latina a lanzar sus propios servicios financieros rápida y fácilmente gracias a nuestra tecnología. Y no solo eso. La idea también era ayudar a nuestros clientes a hacer crecer sus negocios en solo semanas, y no años.

A continuación presentamos los siete pasos que seguimos para establecer una infraestructura de fintech robusta y fiable desde cero. 

1. Crear una plataforma interna para desarrolladores (IDP)

Primero, creamos una plataforma interna para desarrolladores (IDP) llamada Rocket. Utilizamos Backstage, un proyecto de código abierto de Spotify en combinación con la función Service Catalog de Amazon Web Services (AWS). Esto nos permite compartir el inventario completo de nuestros servicios con nuestros desarrolladores. En solo tres meses, logramos tener listo el primer producto viable mínimo para Rocket. Ahora utilizamos las API de New Relic para introducir algunas métricas de observabilidad en Rocket y para que nuestros desarrolladores puedan ver las tablas de puntuación de control de calidad. El equipo de la unidad del sitio para desarrolladores, por ejemplo, tiene oportunidad de acceder a métricas clave en relación a la calidad del servicio, la cobertura, las alertas y el tiempo que necesita la aplicación para recuperarse.

2. Estandarizar todos los activos en la IDP

En Rocket, contamos con procesos estandarizados que especifican cómo desplegar las aplicaciones, cómo estructurar su andamiaje, cómo desplegar una base de datos y qué herramientas utilizar para la observabilidad y la telemetría. También tomamos decisiones sobre qué lenguajes utilizaríamos para trabajar, y elegimos Java, Go, Node.js y React para el front-end. Estos son los únicos cuatro lenguajes que usamos en la empresa. Cuando agregamos las API a la plataforma interna para desarrolladores (IDP), las creamos con documentación Swagger, que es parte de la estandarización del andamiaje de aplicaciones.  

3. Usar una sola herramienta de monitoreo

En algunos de mis roles anteriores, uno de los peores errores con los que tuve que lidiar fue que teníamos una aplicación para monitorear la infraestructura, otra para monitorear los logs y otra para el monitoreo del rendimiento de aplicaciones (APM). Investigar un incidente y detectar el origen de la anomalía en varias herramientas era molesto y nos hacía perder tiempo. Cuando fundamos Pomelo, decidimos tener una herramienta única porque queríamos que todos nuestros equipos de desarrolladores aprendieran a dominar justo esa y no otra. Por eso elegimos New Relic, que no solo nos ayuda a mantenernos informados de todo, sino también a mantener nuestras prácticas de estandarización, ya que cada aplicación que desarrollamos cuenta con un conjunto de alertas comunes y métricas clave.

4. Mapear la ruta crítica para cada modelo empresarial, no cada aplicación

Las métricas que se pueden utilizar en todas las aplicaciones tienen sus límites. Llegados a este punto, lo que necesitábamos era definir la ruta crítica para cada modelo empresarial, no para cada aplicación. Este enfoque nos permite crear métricas en New Relic que se ajustan a los niveles de servicio de cada modelo empresarial. Por ejemplo, algunas de nuestras rutas críticas son para los procesos de transacción y autorización. Se trata de flujos de rutas críticas que se pueden usar en distintas aplicaciones. Cada equipo tiene la capacidad de crear su propio dashboard, pero también usamos cuatro dashboards generales que miden el tiempo de actividad, el rendimiento, la tasa de errores y la latencia para cada ruta crítica. En cada uno de ellos, tenemos la capacidad de ir a cada aplicación y ver qué resultado está dando la ruta crítica dentro de esa aplicación.

5. Descentralizar los equipos y darles soporte

En Pomelo, los equipos están descentralizados: cada unidad empresarial trabaja con sus propias aplicaciones. Como somos un equipo de plataforma, creamos Rocket para poder descentralizar nuestros conocimientos y conseguir que cada equipo pueda encargarse de su propio trabajo. Contamos con un equipo de fiabilidad centralizado que da soporte a los distintos equipos para optimizar el uso de nuestra IDP, comprender qué métricas se pueden crear en New Relic, compartir buenas prácticas en torno a ellas y decidir qué es lo que tienen que observar.

6. Introducir un caos controlado

El equipo de fiabilidad introduce ingeniería del caos en todos los equipos, uno por uno. Una vez a la semana, hacemos ensayos de comprobación y falla de la aplicación alternando entre los equipos descentralizados. También efectuamos una vigilancia de fiabilidad: examinamos su arquitectura, evaluamos los cuellos de botella y tomamos conciencia de lo que debe medirse. Nuestro equipo de fiabilidad es pequeño, pero sus integrantes son como superhéroes en nuestra organización.

Practicamos ingeniería del caos por distintas razones. Por ejemplo, para interrumpir el flujo y ver qué pasa cuando se altera el flujo de las transacciones; para simular picos de tráfico; para interrumpir o aumentar la memoria o para insertar inyecciones de fallas en los datos. Y todo eso se hace en entornos de prueba. Usamos Kubernetes y contenedores para tener la certeza de que los ensayos realizados en nuestro entorno de prueba reflejan las experiencias del entorno de producción, evitando introducir caos en la producción propiamente dicha. Y lo mejor es que, para medir muchos de estos usos potenciales, podemos usar métricas y funciones de New Relic que están listas para usar. Contamos, por tanto, con todo el monitoreo que necesitamos dentro de la plataforma.  

7. Saber cuándo priorizar la velocidad frente a la calidad

Nuestro objetivo primordial es crear soluciones de calidad para nuestros clientes. Para ello, empleamos muchos procesos internos y aplicaciones en desarrollo para uso propio. Cuando utilizamos productos que no son accesibles a los clientes, hay ocasiones en que sacrificamos la calidad (por ejemplo, cuando estamos comenzando a probar ideas o funciones para un nuevo producto). Pero nunca sacrificamos la calidad en lo que respecta a la ruta crítica de aplicaciones que sí usan los clientes.

Estos procesos hacen posible que nuestra infraestructura pueda ampliarse para admitir millones de transacciones por hora sin la más mínima dificultad. Las siete tácticas clave que acabamos de describir nos han ayudado a convertirnos en un líder de infraestructura fintech en América Latina. Nuestros clientes saben que en esa infraestructura pueden utilizar sus aplicaciones con plena confianza; y esa confianza en nosotros les permite, además, dar a sus propios clientes el respaldo que necesitan para administrar sus finanzas.