Header Ads Widget

Ticker

6/recent/ticker-posts

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

 

Los servicios financieros están a punto de convertirse en una parte integral de la economía API. Las fuerzas del mercado, tanto disruptivas en términos de nuevas ofertas de FinTech como regulatorias en forma de legislación anticompetitiva , están dando como resultado un número creciente de proveedores de servicios financieros que ofrecen API . La capacidad de ofrecer resultados en la economía de API significa naturalmente que las organizaciones bancarias deberán adaptar o cambiar sus arquitecturas para admitir este nuevo rol de proveedor de API.

"[Las API nórdicas] proporcionaron una enorme cantidad de valor en relación con la inversión, tanto en términos de costo como de tiempo". - Eyal Sivan, CIBC

Muchos proveedores de servicios financieros están aprovechando la oportunidad de reformar sus arquitecturas internas para estar listos para ingresar a la economía API. Una mejora comúnmente discutida es dividir las aplicaciones monolíticas internas en microservicios . Los microservicios se están convirtiendo en un estilo arquitectónico popular, ya que promueven el desacoplamiento de funcionalidades que están lógicamente separadas, permiten la reutilización lista para usar y el desarrollo acelerado en muchos equipos paralelizados. Los microservicios también complementan naturalmente la entrega de API, lo que permite diferentes velocidades de desarrollo, control de versiones y mashups de microservicios a través de una capa de mediación de API .

Consultamos a CIBC sobre su marco de microservicios.

Las API nórdicas trabajaron recientemente con una de esas organizaciones, el Canadian Imperial Bank of Commerce (CIBC), que se está embarcando en su propio viaje de microservicios para descomponer los backends monolíticos existentes. Una característica de este viaje es un marco de microservicios Light 4J , que CIBC eligió construir ellos mismos. Lo han ensamblado a partir de componentes de código abierto y lo están construyendo donde tiene sentido, en lugar de intentar personalizar una oferta comercial. A las API nórdicas se les asignó la tarea de revisar sus características y funcionalidades para validar su progreso y ofrecer comentarios constructivos.

En esta publicación, analizamos el fundamento de CIBC para crear su propio marco de microservicios y cómo esto podría brindarle ventajas a CIBC para el futuro.

¿Por qué adoptar microservicios?

Para cualquier organización que rediseñe sus aplicaciones monolíticas existentes, los microservicios se están convirtiendo en una opción sencilla. Dadas las ventajas que mencionamos brevemente anteriormente, este estilo arquitectónico ofrece el potencial para ciclos de desarrollo acelerados y oportunidades de reutilización significativas. En el caso de CIBC, Eyal Sivan, su Director Senior de Arquitectura Empresarial, describió los beneficios de un enfoque de microservicios de la siguiente manera:

“El auge de los dispositivos móviles y la web como los canales dominantes para atraer a los Clientes ha impulsado una enorme demanda de innovación en todo el sector financiero en todo el mundo. En muchos casos, estas nuevas oportunidades han sido aprovechadas por FinTechs más pequeñas y operadores de tecnología más grandes que invaden cada vez más lo que tradicionalmente ha sido territorio bancario. Además, los esfuerzos regulatorios como PSD2y otros están impulsando a los bancos a abrir sus datos y hacerlos públicos, a menudo utilizando tecnologías que son bastante avanzadas y desconocidas. Todas estas presiones exigen un grado de velocidad y agilidad que nuestra arquitectura de tecnología actual simplemente no puede soportar ... CIBC determinó que una arquitectura de microservicios era el mejor enfoque disponible en la actualidad para satisfacer nuestra necesidad actual de agilidad y prepararnos para lo que esperamos sea volátil. futuro."

¿Por qué crear un marco de microservicios internamente?

Por tanto, la elección de una arquitectura de microservicios en CIBC tiene mucho sentido. Sin embargo, la justificación para crear ese marco utilizando partes de código abierto parece menos obvia, por dos razones clave:

  • Las grandes organizaciones de banca minorista tienden a utilizar proveedores establecidos para su desarrollo de software y TI. La creación de tecnologías de bloques de construcción que son fundamentales para la forma en que operan sus aplicaciones de software no suele ser parte de su psique.
  • Ya hay una serie de componentes básicos de microservicios en el ecosistema, incluido el chasis de microservicios como Spring Boot . Usar uno de estos chasis de microservicios parecería la forma más práctica de poner en marcha el desarrollo.

Sin embargo, había una serie de ventajas claras al seguir la ruta de la cosecha propia. Las ventajas desde la perspectiva de Eyal eran claras:

“Nuestro análisis de la industria determinó que el mercado de soluciones de microservicios es actualmente muy volátil. No hay titulares ni líderes claros entre los proveedores, los estándares asociados son relativamente jóvenes y tienen un enfoque limitado, y las tecnologías subyacentes continúan evolucionando a un ritmo rápido. Como resultado, determinamos que una postura de “construcción” para nuestro marco de MSA actuaría como una cobertura efectiva contra este mercado volátil y nos brindaría la oportunidad de superar a nuestros competidores agregando características y servicios avanzados hechos a la medida de nuestras necesidades. "

En la revisión de las API nórdicas, también identificamos las siguientes ventajas específicas en la creación de un marco de microservicios propio:

  • Reconoce la necesidad de microservicios en un marco de desarrollo común y repetible que puede ser adoptado por toda la organización.
  • La creación de un marco de microservicios interno significa que puede desarrollarse junto con la madurez de microservicios de CIBC . Esto es de vital importancia ya que permite a la organización aprender lecciones y ajustar su enfoque de manera iterativa.
  • Este enfoque también ayuda a minimizar la deuda técnica al eliminar la necesidad de refactorizar los servicios para que se ejecuten en otro marco más adelante.

Estas ventajas significan que CIBC está en una buena posición para ajustar y experimentar con su arquitectura, tanto en términos de dominio como de tecnología. Este tipo de flexibilidad se presta al estilo de Arquitectura Evolutiva discutido por ThoughtWorks y considerado como un trabajo de la mano con una arquitectura de microservicio.

En términos prácticos, sin embargo, existen otras ventajas significativas al crear un marco de microservicios propio.

Hacer frente a preocupaciones transversales

En el mundo de los microservicios, se dedica una gran cantidad de tiempo a debatir las preocupaciones transversales y cómo gestionarlas. Estos son factores que se encuentran en cualquier aplicación ("atravesándolos") y generalmente se enfocan en los aspectos no funcionales del desarrollo de software. Ejemplos de preocupaciones transversales incluyen:

Revisión de cuentasInicio sesiónPersistencia
SeguridadModelado empresarialManejo de excepciones
Gestión de la configuraciónAdministración del EstadoTransaccionalidad

 

Al crear el marco Light 4J, CIBC está implementando un chasis de microservicios estandarizado que se ocupa de las preocupaciones transversales como una faceta clave del marco. El objetivo, y los autores de light-4j son claramente conscientes de este hecho dado su uso de middleware , es abstraer las preocupaciones transversales para que se conviertan en componentes conectables del marco.

La abstracción de las preocupaciones transversales de esta manera permite ignorarlas (cuando corresponda) durante el desarrollo y parametrizarlas para su ejecución a través de la integración y el despliegue continuos . Este enfoque ayuda a garantizar que se mitiguen adecuadamente y tiene el efecto secundario de acelerar el tiempo de desarrollo.

Lea también: Operación de una API del mundo real, de cero a 3 millones de llamadas

Incorporar seguridad en todo

La seguridad también es un buen ejemplo de cómo el Light 4J mitiga una preocupación transversal específica. Sin embargo, también muestra cómo el enfoque propio ha ayudado a CIBC a aplicar un enfoque de seguridad estandarizado en toda su plataforma.

El principal estándar de seguridad de CIBC es OAuth y se utiliza para la autorización del acceso de los usuarios a los componentes de la arquitectura CIBC. Sin embargo, el marco Light 4J también utiliza un mecanismo para la intercomunicación segura mediante el uso de JSON Web Tokens (JWT). Cuando se implementa un nuevo microservicio, un proceso de arranque garantiza que el microservicio sea sembrado con una nueva clave privada para que pueda unirse a la red. Aprovecha aspectos de la suite JOSE , es decir, claves web JSON con ID de clave y conjuntos de claves web JSON, de modo que a medida que se agregan claves, automáticamente están disponibles para la red y se pueden extraer del servidor OAuth .

Si bien existe una transversalidad en este contexto (dependencia del servidor OAuth para resolver las claves), la falta de disponibilidad del servicio OAuth no detiene el desarrollo local, la puesta en marcha o el servicio de solicitudes de los consumidores que ya conocen el servicio. Esta decisión de diseño significa que, desde el contexto de seguridad, el marco es enormemente escalable , agregando y resolviendo automáticamente nuevas claves a medida que los microservicios se implementan.

No se pierda la charla de Eyal Sivan en nuestra Platform Summit 2017: Adopción de API y microservicios en un banco importante

Flexibilidad en estilo API

El enfoque de cosecha propia también tiene ventajas al introducir flexibilidad en el estilo de API que puede ser compatible. Los microservicios se exponen naturalmente a través de una API, pero existe una tendencia en los marcos proporcionados por el proveedor a admitir solo un estilo arquitectónico principal, generalmente REST .

REST, por supuesto, no es la única opción al exponer una API. Puede satisfacer las necesidades de una parte significativa de la comunidad de desarrolladores que un proveedor de API exponga una API GraphQL o gRPC en lugar de estar obsesionado con ofrecer una oferta de API completamente heterogénea. La esencia de ser un proveedor de API es brindar a la comunidad de desarrolladores lo que desean. Ser capaz de hacer esto se basa en tener un marco que permita exponer varios estilos de API .

CIBC es claramente consciente de este hecho y ha creado implementaciones GraphQL y RPC en su marco. Este enfoque brinda a los arquitectos y desarrolladores flexibilidad y opciones para discernir la mejor opción para el tipo de API que utilizan para exponer su microservicio.

Pensamientos finales

Construir cualquier cosa por su cuenta en la TI empresarial tiene sus desafíos. Muchas organizaciones corporativas grandes, en primer lugar, y a veces el único, puerto de escala es su proveedor preferido, a quien instruyen para satisfacer sus necesidades. En muchos de estos casos, existe un desfase significativo entre la oferta y la demanda, lo que significa que estas organizaciones pierden la ventaja de ser el primero en moverse y, a menudo, obtienen un producto más pobre como resultado.

El paso para crear un marco de microservicios utilizando un equipo interno podría verse como un paso audaz en este contexto. Sin embargo, el enfoque, junto con un gran equipo , permite a CIBC una gran cantidad de opciones y flexibilidad en la forma en que eligen descomponer sus aplicaciones monolíticas. Además, a medida que se crean e implementan nuevos microservicios, pueden continuar madurando y refinando su enfoque, respaldados por la capacidad de experimentar tanto con su arquitectura como con los servicios mismos. En este contexto, CIBC se encuentra en una buena posición para continuar con su viaje de microservicios y API.

Publicar un comentario

0 Comentarios