¿Cómo mantiene Monzo 1.600 microservicios girando? Con Go, código limpio y un equipo fuerte

Los principios de desarrollo de software bien conocidos son más importantes que las opciones tecnológicas.

Los ingenieros de QCon London Software del banco digital Monzo les dijeron a los desarrolladores en el evento QCon en Londres cómo y por qué ejecuta sus sistemas bancarios en 1.600 microservicios.

La sesión de Monzo en QCon estuvo en marcado contraste con la presentación del lunes en la que Sam Newman advirtió que una arquitectura de microservicios es un “último recurso”. Los ingenieros senior Matt Heath y Suhail Patel describieron cómo los microservicios funcionan bien para el banco, fundado en 2015 y ahora con más de 4 millones de clientes.

Como un nuevo negocio que esperaba crecer sustancialmente, Monzo requería una plataforma tecnológica que fuera extensible, escalable, resistente y segura. La idea era comenzar con algunos servicios bancarios básicos y luego poder agregar más a medida que el tiempo y los recursos lo permitieran.

Al principio, Monzo se convenció del valor de un sistema distribuido.

El banco no quería un solo sistema grande y resistente con una conmutación por error compleja que espere que nunca tenga que ejecutarse.

“Si no ejercita esos modos de conmutación por error, ¿cómo puede saber que funcionan de manera confiable?” dijo Heath. Comenzaron con Mesos para la gestión de clústeres, pero en 2016 se cambiaron a Kubernetes (K8) como el “líder del mercado emergente”.

Uno de los objetivos era abstraer la complejidad de la infraestructura. “Creemos que todas las complejidades sobre el escalamiento de la infraestructura, asegurándose de que los servicios estén aprovisionados y las bases de datos estén disponibles, deben ser tratados por un equipo específico, para que los ingenieros puedan enfocarse en el producto”, dijo Patel. 

Los sistemas se ejecutan en Amazon Web Services (AWS).

K8s no ha sido completamente libre de dolor. En 2017, Monzo “tuvo una interrupción bastante grande, debido a un problema con los K8 y cómo interactuó con etcd y linkerd, debido a una combinación de diferentes errores que eran bastante difíciles de probar”, dijo Heath.

Monzo eligió a Cassandra como la base de datos porque se escala horizontalmente (lo que significa que simplemente puede agregar más hardware para escalar, en lugar de tener que migrar a un sistema más grande).

En el lado de la codificación: “Usamos Go como nuestro lenguaje de programación principal”, dijo Heath. “Es bastante simple, está estáticamente tipado y nos facilita la incorporación de personas”. Go tiene una garantía de compatibilidad con versiones anteriores, lo que significa que cuando aparece una nueva versión, simplemente puede volver a compilar el código existente, obteniendo los beneficios de las actualizaciones de funciones como el recolector de basura. Go también es adecuado para políticas estrictas sobre el manejo de errores.

“Tenemos un análisis estático para asegurarnos de que no esté ocultando errores”, dijo Patel.

Los sistemas bancarios se adaptan bien a un enfoque modular. Existe el requisito de vincular a muchos sistemas diferentes como BACS, CHAPS, Visa, Mastercard, Apple Pay y Google Pay. “Agregar esas cosas como sistemas separados nos permite mantenerlas más simples”, dijo Heath. Monzo construye integraciones tanto como sea posible internamente, en lugar de usar implementaciones de terceros, para obtener más control sobre la resistencia y el rendimiento (y probablemente también ahorrar dinero a largo plazo). Incluso construyeron su propio sistema de chat, utilizado internamente y como soporte.

Monzo también ha creado sus propias herramientas para interactuar con AWS y K8, como una llamada Shipper, que puede implementar o deshacer un servicio individual. El remitente se puede implementar directamente desde una solicitud de extracción, que representa una actualización del código mantenido en un repositorio de Git.

Cada microservicio Monzo se ejecuta en un contenedor Docker. “Una de nuestras decisiones más importantes fue nuestro enfoque para escribir microservicios”, dijo Patel. Hay una biblioteca central compartida, que está disponible en todos los servicios; esto se copia esencialmente en cada contenedor, aunque el proceso de construcción eliminará el código no utilizado. Esto significa que “los ingenieros no están reescribiendo abstracciones centrales como la organización de datos”. También habilita métricas para cada servicio, de modo que, después de la implementación, aparece inmediatamente en un panel con análisis del uso de la CPU, llamadas de red, etc. Las alertas automáticas identificarán servicios degradados.

Se piensa mucho en la interfaz o API que expone cada servicio.

El equipo prefiere escribir muchos servicios pequeños, cada uno dedicado a un único propósito, en lugar de menos servicios más complejos. “¿Por qué tenemos tanta granularidad? Queremos minimizar el riesgo de cambio”, dijo Patel. “Por ejemplo, si queremos cambiar la forma en que funcionan los pagos sin contacto, no estamos afectando el sistema de chip y PIN”.

¿Cómo trabajan los desarrolladores en su código, dado que ejecutar 1.600 microservicios no funcionará en una computadora portátil? “Estás ejecutando un subconjunto”, dijo Heath. “Tenemos un filtro RPC que puede detectar que está tratando de enviar una solicitud a un servidor que actualmente no se está ejecutando, puede compilarlo, iniciarlo y luego enviar la solicitud a eso.”

¿Por qué los microservicios funcionan para Monzo, mientras que en algunos casos agregan complejidad sin brindar muchos beneficios? 

Aunque las tendencias de desarrollo de software han cambiado de año en año, algunas cosas se han mantenido consistentes. Una es que la forma en que los desarrolladores interactúan entre sí en un equipo (y con la administración) cuenta más que cualquier metodología de desarrollo que adopten. Otra es que un enfoque incremental gana a grandes cambios ocasionales. “Un proceso iterativo es generalmente lo que tomamos en serio en Monzo”, dijo Heath, “tanto desde la perspectiva de la infraestructura como desde la perspectiva del producto. Al hacer pequeños cambios con frecuencia, nos aseguramos de ir en la dirección correcta”.

Otro tema recurrente de QCon es la ventaja de la simplicidad sobre la complejidad. En conjunto, lo que hace el sistema de Monzo es muy complejo, pero ha diseñado sus sistemas de tal manera que dividen esa complejidad en piezas más pequeñas y simples, y la abstraen de los desarrolladores que trabajan en el código. “No necesita saber cómo funcionan 1.600 servicios”, dijo Heath. La difícil tarea de administrar K8 se delega a especialistas.

Monzo también ha estandarizado “un pequeño conjunto de opciones tecnológicas”, dijo Heath:

Para que “como grupo, podamos mejorar colectivamente esas herramientas”. Esto podría ser frustrante para los desarrolladores que tienen diferentes preferencias tecnológicas, pero deben ayudar sustancialmente con la colaboración, ya que todos aprenden el mismo conjunto de herramientas. “El código debe ser legible para otros humanos”, dijo Patel. “Optimizamos el código para facilitar la lectura. Uno de nuestros principios de ingeniería es no optimizar [el rendimiento] a menos que sea un cuello de botella”.

Lo que Monzo presentó en QCon parecía ser una plantilla sólida para el desarrollo y la implementación de software en el caso de que tenga un sistema complejo con muchos componentes y necesite poder responder rápidamente cuando cambien los requisitos o se agreguen características.

Heath y Patel defendieron el valor de los microservicios. Sin embargo, tenga en cuenta que Monzo utiliza muchas herramientas y bibliotecas personalizadas que no son fáciles de replicar. Además, muchos de los principios que presentaron, como escribir código limpio, legible y disciplinado, centrarse en algunas piezas de tecnología cuidadosamente elegidas y adoptar un enfoque gradual, son ganadores en cualquier arquitectura de software.