Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo los bancos se están volviendo uberizados


Probablemente haya escuchado el sentimiento de que “los bancos se están convirtiendo en empresas de tecnología”. Es una idea que ha existido durante años y captura lo que parece una evolución en la forma en que consumimos y usamos todo, desde la comida hasta el dinero. Como consumidores, queremos opciones al alcance de la mano, y quizás sea esto lo que obligue a los bancos de todo el mundo a abrir sus servicios con API y microservicios y, en última instancia, convertirlos en empresas de tecnología.

Eyal Sivan es director senior de arquitectura empresarial en el Canadian Imperial Bank of Commerce ( CIBC ). En nuestra Cumbre de API de Austin 2018, contó la historia de cómo y por qué uno de los Cinco Grandes de Canadá adoptó una arquitectura de API y microservicio.

Vea a Eyal Sivan presente en Austin API Summit:

Las API no son nada nuevo

Otra afirmación que seguramente habrá escuchado es que las API no son "nada nuevo", lo cual es cierto. Eyal reconoce esto: las API han existido desde los años 70, pero en ese entonces la arquitectura empresarial podía describirse con una sola y temida palabra ... monolítica.

Los monolitos eran grandes y molestos. Como dice Eyal, "a veces estaban en mainframes que llenaban edificios enteros, y se hablaba de estas cosas como se podía hablar con ellas". Más un artefacto de la digitalización temprana que cualquier otra cosa, los monolitos tenían demasiadas interfaces y sistemas que seguían fallando. Se volvió demasiado costoso de mantener.

Ingrese al ERP, o soluciones de planificación de recursos empresariales. Estos eran bloques de construcción patentados que podía usar para cortar, empaquetar y limpiar sus "espaguetis" (como él los recuerda con tanto cariño). No hace falta decir que agrupar código arbitrariamente no aportó mucho a la arquitectura del sistema; irónicamente, terminó costando más.

Luego vino el EAI, o integración de aplicaciones empresariales. Si bien esto fue una mejora con respecto a los ERP gracias a un marco un poco más estandarizado, aún se quedó corto en el tiempo: no solucionó ninguno de los problemas, pero fue igualmente costoso e igualmente propietario.

Finalmente, aparece la arquitectura orientada a servicios (SOA). La industria ahora tiene un estándar para los contratos de API, y con la introducción de un bus de servicio empresarial, cada pieza del rompecabezas se puede conectar, aunque sea de forma indirecta. Sin embargo, a medida que el autobús de servicio inevitablemente comenzó a adquirir más lógica, se volvió grande y desordenado de la misma manera que lo haría un EAI.

Dado que parte del problema era que todos interactuaban con el bus de servicio empresarial a su manera, el siguiente paso fue federar las diferentes escuelas de pensamiento y darle a cada parte su propio bus de servicio de dominio, que podría contener cualquier lógica y seguir cualquier regla, mientras todavía conectando al bus de servicio principal.

Finalmente, hubo un sistema que funcionó bien para todos ...

Lea también: Creación de un marco de microservicios en CIBC: un estudio de caso

Teléfonos inteligentes: encender un cambio

… Eso es hasta que se inventaron los teléfonos inteligentes, que cambiaron por completo la forma en que interactuamos con los servicios de TI. Los consumidores ahora tenían un dispositivo que podía hacer todo desde cualquier lugar, y eso es exactamente lo que querían.

"Todo cambió. De repente, la gente podía pedir un taxi, una habitación de hotel, una pizza, con un par de toques en su teléfono. Y los consumidores esperaban exactamente el mismo tipo de interacción de todas las personas con las que hacen negocios, probablemente la mayoría de los bancos ".

Esto cambió el panorama del desarrollo de software. El costo ya no era el factor decisivo, sino la velocidad. Los desarrolladores ahora querían crear software que fuera flexible: fácil de mantener y fácil de actualizar.

La solución obvia era dividir las cosas en partes, reemplazando cada monolito con un conjunto completo de API y microservicios en los que se podía trabajar individualmente.

Tiempo para API Up

Una vez que quedó claro que una API y una arquitectura de microservicio era la que se debía seguir, el banco sacó su billetera y salió al mercado. Como explica Eyal, la compra-sobre-construcción era la postura natural en un banco con mucho dinero.

Los analistas pronto descubrieron que no había soluciones líderes en el campo, incluso después de explorar los proyectos de código abierto, que generalmente están a la vanguardia de las nuevas tecnologías. Así que CIBC tomó la audaz decisión de construir.

Comenzaron con un núcleo de código abierto, el marco Light, antes de emplear al propietario de ese proyecto en torno a quien construir un equipo completo. Con esto, crearon la Fundación API, que se compartió con los mismos analistas para su revisión.

Si bien acordaron unánimemente que la documentación “apestaba”, la plataforma era algo nuevo y resistió las pruebas extremadamente bien. Eyal justifica la decisión de construir su propia solución por tres razones:

  1. Se protege contra un mercado increíblemente volátil.
  2. Le permite dirigir la dirección de su plataforma (en este caso, era la única solución de CIBC para soportar GraphQL )
  3. Cultiva habilidades de desarrollo críticas (OAS, Swagger, ahora OpenAPI, DevOps, lanzamientos diarios, pruebas / implementación automatizadas, etc., etc.).
Lea también: Seguridad API de alto grado para bancos

Construir con propósito

Se había tomado la decisión. CIBC iba a construir su propia arquitectura de microservicios y API , y ahora era el momento de empezar a trabajar. Pero antes de poder hacerlo, tendrían que establecer sus principios rectores, entre otras cosas, explica Eyal.

Los principios rectores son lo primero

Cada organización tiene sus propias prioridades, por lo que no existe un enfoque único para la construcción de cualquier tipo de arquitectura de red, y aunque Eyal no lo menciona, esta es otra ventaja de desarrollar su propia solución.

Con eso en mente, debe establecer sus principios rectores antes de comenzar. La dicotomía en la que se centra Eyal es la proliferación versus la estandarización y la gobernanza. Es decir, ¿valora una solución sobre la que sea fácil construir (con, por ejemplo, agregar nuevas funciones todos los días) o una solución bien cuidada y fácil de mantener?

Para que conste, el principio correcto probablemente se encuentre en algún punto intermedio.

El producto objetivo

A continuación, es importante apreciar la naturaleza del producto objetivo. Eyal enfatiza que no construyeron una “caja mágica” que se encarga de todo, que sería un reempaquetado moderno de SOA en el sentido de que eventualmente choca contra una pared.

En su lugar, adoptaron un enfoque de puerta de enlace distribuida para adoptar los microservicios , la "salsa secreta". Tengamos en cuenta aquí que, si bien es posible que pueda empaquetar la misma funcionalidad en un mainframe monolítico y exponer eso con API (que sería significativamente más simple), entonces se quedaría sin espacio para crecer.

CIBC luego tomó los microservicios y le dio a cada uno una puerta de enlace integrada . De esa manera, los microservicios pueden actuar y administrarse de forma independiente entre sí en todos los aspectos, desde la seguridad hasta la analítica. No existe una prohibición total de las puertas de enlace centralizadas, pero se utilizan para operaciones que están  verdaderamente centralizadas.

Como señala Eyal, el aumento de la popularidad de estas arquitecturas, o mallas de servicios , en realidad está empeorando la volatilidad, otra razón más para cultivar habilidades de gestión y desarrollo internamente.

Service Mesh Plus de CIBC

Además de las puertas de enlace integradas, CIBC ha creado muchas más funciones en su arquitectura de servicio para que las cosas sean lo más fluidas posible, de ahí la etiqueta de Service Mesh Plus .

Por un lado, han optado por alejarse de la malla homogénea típica (donde cada usuario comparte la misma malla), incluida una serie de proxies ligeros y enrutadores para mejorar la compatibilidad.

Además, buscan implementar la autorización federada , una red de confianza entre los servidores OAuth .

Lea también: ¿Debería comenzar con un monolito o microservicios?

Actuar como una empresa tecnológica

Si bien algunas de estas cosas pueden parecerle ajenas, Eyal señala que hacer API y microservicios de la manera correcta lo obliga a actuar como una empresa de tecnología. Esa es “la habilidad crítica aquí; trate sus activos más como productos ".

Se acerca la uberización de los bancos , por lo que actuar como una empresa de tecnología es, según Eyal, un "cambio para que los bancos sobrevivan".

Es de suponer que esa es la razón por la que Eyal no tiene miedo de compartir lo lejos que ha llegado CIBC en ese sentido:

  • La Fundación API se utiliza en todo el banco, con un consejo de gobierno que exige su uso, a menos que haya una buena razón para no hacerlo.
  • Hay un entorno de contenedores administrado con una red de desarrollo ya implementada.
  • Han creado un programa de formación para desarrolladores adyacente , con el objetivo de crear una comunidad interna alrededor de la plataforma.
  • Hay un piloto del mercado de API disponible en la actualidad, con un modelo de autoservicio que permite a los desarrolladores utilizar la API sin una sola reunión o llamada (lo que permite un ahorro de costes del 50% al 70% por integración).

Consejos de Eyal para su plataforma API

Estos son algunos de los consejos de Eyal para crear su propia plataforma API de alto rendimiento, con la fantástica metáfora de un edificio de ladrillo y cemento:

  • Los cuatro pilares : Desarrollar una red poderosa es un acto de equilibrio. Haga crecer su API, nube, DevOps y estrategias ágiles juntas para que todo funcione sin problemas.
  • La base : su solución debe construirse sobre una base sólida, que va desde su equipo de tecnología y operaciones, a través de la estructura organizativa de la empresa, hasta los valores y la cultura corporativos ¿Puede convencer a los funcionarios del banco de que la innovación es el enfoque correcto?

Eyal termina con lo que él considera la idea más importante para el éxito: construir para el cambio. Los sistemas de TI están cambiando y, aunque no podemos saber hacia dónde se dirigen, podemos construir con esa incertidumbre en mente.


Publicar un comentario

0 Comentarios