Form3 cuenta cómo corre su plataforma de pagos en tres nubes a la vez
La ingeniería de la firma británica cambió ECS y SQS por Kubernetes en AWS, Azure y GCP, con NATS JetStream y CockroachDB como piezas agnósticas.
Form3 procesa pagos cuenta a cuenta entre bancos y entidades financieras de Reino Unido, Europa y Estados Unidos, y ha explicado en una charla cómo pasó de estar clavada en AWS a operar la misma plataforma sobre tres nubes simultáneas. Lo contaron Ross McFarlane y Kevin Holditch, vicepresidente de ingeniería, en una sesión recogida por InfoQ.
El detonante no fue técnico. En 2021 el regulador bancario británico publicó un documento advirtiendo de que, con un puñado de proveedores cloud y medio sector financiero encima de ellos, una caída de uno solo se llevaría por delante a buena parte de los servicios financieros del país. El mensaje de fondo: un banco tiene que poder salir de su nube. Uno de sus clientes, uno de los bancos grandes del país, lo tradujo en un requisito y Form3 se puso a construir una plataforma que pudiera vivir en varias a la vez.
De ECS a tres clústeres de Kubernetes
La primera versión, montada hace unos nueve o diez años con un equipo de entre cuatro y diez ingenieros, era deliberadamente dependiente de AWS. Microservicios en Java sobre contenedores Docker en ECS, bus de mensajes SQS para los flujos asíncronos y Postgres en RDS. La idea era soltar lastre: que el proveedor se ocupara de backups y de réplicas entre zonas de disponibilidad. Funcionó para salir al mercado rápido, pero ataba el producto a un solo sitio.
La v2 invierte esa lógica. Tres clústeres de Kubernetes, uno en Google Cloud, otro en Azure y otro en AWS, con un balanceador que expone el endpoint de la API y permite al cliente hacer balanceo por su cuenta: si no recibe respuesta de GCP, reintenta contra Azure. Los microservicios pasaron de Java a Go, por huella de despliegue más pequeña y, según Holditch, porque el código es más fácil de leer de punta a punta cuando saltas de repositorio en repositorio.
El objetivo declarado es activo-activo-activo, tratando una nube como si fuera una zona de disponibilidad más. Eso obligó a descartar servicios propietarios y a asumir ellos mismos lo que antes delegaban.
Las dos piezas que sostienen el invento
El almacenamiento y la mensajería recaen en dos productos de terceros. NATS JetStream, un bróker escrito en Go, corre como un único clúster lógico repartido entre los tres Kubernetes: un mensaje publicado en GCP puede consumirse en Azure. Para los datos eligieron CockroachDB, que habla un dialecto compatible con Postgres. La transcripción disponible se corta justo ahí, antes de que Holditch termine de explicar esa parte.
Lo interesante para quien opera sistemas es el coste oculto del planteamiento. Correr en tres nubes no es solo pagar tres facturas: hay que mantener el mismo software desplegable en las tres, renunciar a los servicios gestionados que ahorran tiempo y asumir en casa la operación de la base de datos y del bus. Form3 lo hizo porque un regulador se lo pidió a sus clientes, no porque la arquitectura sea gratis. Queda por ver cuánto de ese modelo acaba copiando el resto del sector financiero europeo, que juega con las mismas reglas.
