Si un ingeniero de Google, Amazon, Netflix o incluso Spotify entrara en Thought Machine, se sentiría como en casa de inmediato. Usamos las mismas herramientas. Nuestros principios de arquitectura de software son comunes en todas estas empresas.
Uno de los aspectos más vitales que compartimos es nuestra devoción por los microservicios. Son la clave para crear aplicaciones resilientes, potentes y escalables que resultan fáciles de actualizar. Francamente, Google no podría gestionar Gmail, ni Netflix podría funcionar, sin los microservicios. Son fundamentales.
Los bancos están menos familiarizados con los microservicios. Y siendo amables. Los bancos llevan décadas de retraso respecto a la vanguardia del software. Los microservicios son algo que los banqueros deben aprender, y rápido.
Así que aquí tiene una clase magistral rápida sobre qué son los microservicios y por qué son revolucionarios en la banca.
Tradicionalmente, las aplicaciones bancarias se construyen como una entidad única: un monolito. Todo el código está agrupado en bases de código vastas y extensas, tan intimidantes que los ingenieros se pierden en su laberinto.
Los microservicios son la alternativa. En lugar de un monolito, las aplicaciones se dividen en pequeños fragmentos autónomos llamados microservicios. Cada microservicio funciona de forma independiente y puede ser gestionado por un equipo dedicado. Los microservicios se comunican entre sí a través de API.
Lo que se obtiene es una red de pequeñas unidades autosuficientes que trabajan juntas para crear una única aplicación.
La belleza reside en el tamaño. Cada microservicio se mantiene compacto y bien definido. En Silicon Valley existe la idea de que el equipo que trabaja en un microservicio debe ser lo suficientemente pequeño como para ser alimentado con dos pizzas. La famosa regla de las dos pizzas. Eso supone de siete a diez personas, dependiendo de lo hambrientas que estén. Sea cierto o no, refleja la creencia de que un microservicio debe tener un alcance lo suficientemente limitado como para que un equipo pequeño pueda gestionarlo.
Por ejemplo, en Vault Core el núcleo está compuesto por alrededor de 20 microservicios. Cada uno cuenta con un pequeño equipo que lo conoce a la perfección.
Y hay más
Pero es más que una cuestión de tamaño. En términos técnicos, existe una larga lista de razones fantásticas para utilizar microservicios.
1) Los microservicios son robustos. Si un solo microservicio falla, es la única víctima. Los demás microservicios no se ven afectados. Si comparamos esto con un monolito, donde un fallo puede tumbar todo el sistema, esta capacidad de aislar y limitar los daños supone una ventaja profunda.
2) Los microservicios son más ordenados. Desde una perspectiva de planificación, es más fácil diseñar una aplicación cuando se trabaja con partes diferenciadas.
3) El problema del escalado se resuelve con los microservicios. Un banco debe estar preparado para gestionar picos de demanda. Quizás sea el momento en que se procesan las nóminas el último viernes del mes, o el Black Friday, cuando los clientes compran compulsivamente. Esto significa que los mainframes se dimensionan para una demanda máxima que quizás solo se utilice durante un minuto al mes. El resto del tiempo, los servidores permanecen inactivos. Además, el banco necesita sistemas de recuperación ante desastres de la misma envergadura. Es catastróficamente costoso.
Los microservicios escalan de forma individual. Se alojan en la nube y se expanden o contraen según la demanda. Esto elimina el desperdicio de infraestructura y permite gestionar los picos masivos de demanda sin errores.
4) Actualizar los microservicios es más sencillo. De todas las ventajas, esta es la que hay que destacar. En comparación con las arquitecturas monolíticas, la diferencia es abismal.
He aquí el motivo: un microservicio puede actualizarse siempre que su equipo esté listo. No hay que esperar a coordinarse con otros microservicios. Cada equipo puede trabajar a su propio ritmo (a menos que haya un cambio en su API que afecte a otros microservicios, pero incluso entonces, el impacto se limita a la breve lista de microservicios relevantes).
Este enfoque es mucho mejor. Los equipos ahora pueden actualizar sus microservicios mediante pasos pequeños e incrementales. La corrección de errores es más rápida: se pueden identificar con agilidad, el equipo sabrá qué cambio los provocó y los parámetros de búsqueda se limitan al microservicio en cuestión. La innovación se acelera y los equipos están más satisfechos al controlar su propio destino.
Los monolitos son una pesadilla de actualizar. Los cambios se implementan en una única actualización masiva cada seis meses. Localizar errores es un suplicio: los ingenieros deben navegar entre cientos o miles de cambios de código simultáneos para encontrar el fallo. Como resultado, los ingenieros que trabajan con monolitos se vuelven reacios a las actualizaciones. El tiempo pasa y el monolito queda cada vez más obsoleto. La siguiente actualización masiva debe incorporar una acumulación de mejoras cada vez mayor, lo que hace que el salto sea aún más peligroso. Es un círculo vicioso, demasiado familiar para los ingenieros bancarios.
Pasarse a los microservicios pone fin a este ciclo. Es posible actualizar la aplicación de forma continua, fluida y asimétrica, permitiendo que cada microservicio avance a su propio ritmo.
5) Los microservicios pueden actualizarse sin tiempo de inactividad. Una implementación "Green/Blue" significa que la versión actualizada se lanza en paralelo a la antigua y el tráfico se redirige. El servicio al cliente no se interrumpe. Si el cambio no resulta exitoso por alguna razón, se puede reactivar la versión anterior y redirigir el tráfico de vuelta, revirtiendo los cambios. Sin tiempo de inactividad.
Por el contrario, los monolitos deben desconectarse, de ahí la temida notificación de los bancos: “Nuestro servicio estará fuera de línea por mantenimiento”.
Los microservicios en Thought Machine
Ahora, una pregunta que nos hacen a menudo.
“Si los microservicios son tan buenos, ¿por qué no son más comunes en la banca?”
Hay dos respuestas para eso. La primera es la naturaleza arcaica del software bancario. Muchos bancos están atrapados en sistemas de hace décadas, construidos sobre principios obsoletos. Actualizar estos sistemas antiguos es casi imposible. No es solo que falten microservicios, es que falta la última década de tecnología.
La segunda es que ejecutar microservicios en la banca es difícil. Las condiciones de carrera significan que solo funcionarán soluciones diseñadas con precisión. Imagine una cuenta con dos titulares, donde cada uno realiza un retiro al mismo tiempo. Un monolito maneja esto bastante bien: la arquitectura única alojada en un centro de datos local permite alcanzar tiempos de respuesta de 1 milisegundo. Por tanto, los conflictos son más raros y fáciles de resolver. Los microservicios, por desgracia, son más propensos a conflictos de condiciones de carrera. Están ubicados en centros de datos en la nube: si se tiene en cuenta la velocidad de la luz como limitación natural, además de la resistencia en la fibra óptica y otros problemas, los tiempos de respuesta pueden oscilar entre 200 milisegundos y un segundo.
Es por esto que los microservicios son raros en la banca central. Los proveedores tradicionales no pudieron resolver el problema.
Hoy en día, las condiciones de carrera tienen solución. Pero la tecnología actualmente solo es dominada por unas pocas organizaciones. Thought Machine es el líder mundial en banca central gracias a nuestro compromiso con la ingeniería. Nuestro motor de banca central, Vault Core, elimina los conflictos de condiciones de carrera de una manera superior a cualquier otro sistema bancario basado en microservicios.
Es la razón por la que Lloyds Bank, SEB, Atom bank y Standard Chartered, entre otros, apuestan por Vault Core.
La regulación es otro aspecto que merece la pena mencionar. En Thought Machine, actualizamos nuestros microservicios con una periodicidad mensual. Es cierto que, en teoría, nuestros equipos podrían actualizar cada microservicio cuando quisieran, como ocurre en Amazon o Spotify. Sin embargo, nuestra estrecha colaboración con bancos y organismos reguladores nos ha llevado a adoptar un calendario predecible para garantizar el cumplimiento total de todas las normativas y exigencias.
Una vez más, nuestro profundo conocimiento tanto de la tecnología como del sector bancario nos permite trabajar de formas que nuestros competidores simplemente no pueden.
Las ventajas para un banco
En realidad, la elegante arquitectura de microservicios de Vault Core opera fuera de la vista de nuestros clientes. Vault Core se compone de microservicios, pero los bancos se conectan a través de una API pública, y esa es la única puerta que ven.
Hablamos de "consistencia integral". Los bancos reciben una API coherente. Los cambios internos no afectan a la interfaz que utilizan los bancos. Por tanto, podría decirse que los banqueros pueden olvidarse de los microservicios.
Sin embargo, los bancos necesitan entender los microservicios. Tanto para diseñar sus propios sistemas internos como para comprender los puntos fuertes de Vault Core.
Adoptar Vault Core significa disfrutar de una escalabilidad ilimitada. La demanda puede tener picos y valles, y Vault Core se adapta sin problemas, sorteando las olas.
Con Vault Core, los bancos construyen sobre los cimientos más sólidos que se puedan imaginar. La robustez de nuestra arquitectura de microservicios nos permite actualizar con confianza, eliminar errores e implementar mejoras sin tiempo de inactividad, reduciendo el riesgo en órdenes de magnitud y todo ello a un coste drásticamente menor.
Estas son ventajas fenomenales.
Google, Apple, Netflix y Spotify se basan en microservicios. Ahora, gracias a Thought Machine, le toca el turno a la banca de beneficiarse de ello.
