Header Ads Widget

Ticker

6/recent/ticker-posts

Modernización heredada con API, microservicios y eventos

 


Asesoramiento experto sobre cómo estrangular el monolito y no el negocio

Dividir el monolito en microservicios especializados es un concepto de moda. La idea es modernizar los sistemas heredados mediante la creación de servicios aislados más pequeños alrededor de dominios específicos. Esto podría traer beneficios increíbles, como una reutilización mejorada, mejores integraciones de socios y DevOps acelerado.

Pero romper un gran sistema monolítico es una tarea que requiere una diligencia lenta. Si se intenta todo a la vez, como un Big Bang, su transformación de TI podría causar una complejidad catastrófica. En cambio, los expertos recomiendan The Strangler Pattern , en el que dominios específicos se exorcizan estratégicamente del monolito y se transmutan en microservicios uno a la vez mediante el uso de puertas de enlace API. Al hacerlo, las empresas pueden transformar inteligentemente sus activos de una manera manejable.

Hay muchos ángulos que cubrir en la modernización heredada . Por lo tanto, en nuestro LiveCast de modernización heredada , contratamos a Erik Wilde , catalizador digital de Axway, y Gibson Nascimento , director de soluciones de Sensedia, para presentar sugerencias y mejores prácticas para utilizar microservicios como una herramienta para exponer de manera inteligente las aplicaciones heredadas como API.

A continuación, proporcionaremos un tutorial paso a paso de The Strangler Pattern y demostraremos cómo extender los patrones API-first con Event Brokers para transformar progresivamente los sistemas monolíticos más antiguos.

Vea el LiveCast completo de Legacy Modernization aquí:

¿Qué pasa con un monolito?

En primer lugar, ¿qué es un monolito? ¿Estamos hablando de los misteriosos monumentos de la era espacial que aparecen en todo el mundo? Bueno no. Los monolitos de software son un poco menos de ciencia ficción que eso.

En la teoría del software, un monolito es un patrón de arquitectura de aplicaciones clásico. Este enfoque consolida el código y las dependencias en una sola pila vertical. Es autónomo y no distribuido.

Aunque tener todo en un solo silo puede parecer más simple, más fácil de administrar y más fácil de implementar, moverse alrededor de este objeto masivo es engorroso. La escalabilidad se ve afectada y las implementaciones son difíciles si actualiza todo a la vez. Puede encontrarse con problemas de conectividad y seguridad al intentar integrarse con socios. Además, dado que todo está conectado, los pequeños errores podrían tener un impacto desproporcionadamente grande .

Beneficios de los microservicios

La arquitectura de microservicios, por otro lado, divide el software en segmentos más pequeños que están más desacoplados y distribuidos. Podría decirse que este patrón es más apropiado para las necesidades de los entornos de software actuales: las aplicaciones están más descompuestas, están compuestas por muchos componentes de terceros y los datos son cada vez más abiertos . Los equipos tienen diferentes pilas de software, lanzándose a varios clientes, en diferentes plazos, y adoptando la entrega e implementación continuas para una mayor agilidad.

La creación de servicios de nicho independientes del cliente significa que puede reutilizarlos en toda la organización en diferentes contextos, especialmente si se crea con una interfaz estándar para la externalización (es decir, el mandato de Bezos).

Advertencias y consideraciones

Dividir el monolito en microservicios es un concepto de moda, y ya se ha dicho mucho sobre el tema. Pero, como las empresas se están dando cuenta, los microservicios traen salvedades no deseadas.

Por ejemplo, ¿cómo podemos gestionar la complejidad adicional de los microservicios? ¿Deberían los microservicios en segundo plano coincidir con los puntos finales de API expuestos a los consumidores desarrolladores? ¿Deberían romperse todos los sistemas monolíticos? ¿Qué escenarios requieren este cambio drástico? ¿Qué tamaño debe tener un solo microservicio? ¿Qué constituye exactamente un dominio empresarial específico?

Como puede ver, delinear dominios de microservicios e implementar el patrón en la práctica abre una lata de gusanos. Para comenzar este viaje, es útil tener una estructura básica para implementar este cambio.

El patrón del estrangulador

Erik Wilde discutió cómo transformar monolitos iterativamente con microservicios impulsados ​​por API.

El patrón del estrangulador es una de esas estructuras que ayuda a las empresas a probar la modernización de una manera relativamente económica y con aversión al riesgo. Le permite evolucionar iterativamente solo los elementos que deben cambiarse. Según Erik Wilde, The Strangler Pattern permite un proceso de modernización paso a paso, repetible y controlado.

Razones para estrangular el monolito

En primer lugar, es útil comprender las motivaciones: ¿por qué desea modernizarse con microservicios en primer lugar? Bueno, Erik ve dos razones principales. Un controlador es de abajo hacia arriba y el otro es de arriba hacia abajo.

  1. Preocupaciones operativas : con un monolito, escalar una base de código grande se vuelve exigente y costoso. Una pila que utiliza microservicios puede aprovechar tecnologías como contenedores , Kubernetes y sin servidor , una combinación mucho mejor para la escalabilidad bajo demanda.
  2. Transformación digital : quizás demasiada arquitectura represente lo que un grupo ha estado haciendo en el pasado y necesitan transformarse para permitir innovaciones.

"Es muy importante pensar en las razones", dijo Erik. Como puede ver, un factor importante son las preocupaciones operativas. El otro, transformar digitalmente, es más de arriba hacia abajo. Otros impulsores pueden incluir la agilidad empresarial, el diseño para el cambio, el aumento de la flexibilidad operativa y el cumplimiento de los requisitos reglamentarios .

Patrón de estrangulador: paso a paso

Solo una vez que una empresa tenga un propósito claro debe comenzar sus esfuerzos de modernización. El patrón del estrangulador es una forma de construir estratégicamente servicios de reemplazo alrededor de un monolito preexistente. Se cultivan microservicios paralelos alrededor de dominios monolíticos únicos hasta que ya no sea necesario usar el monolito para esas funciones.

Erik describió 13 pasos para estrangular el monolito:

  1. Comience con un monolito : comprenda por qué desea transformarse.
  2. Identificar componentes : seleccionar lo que podría ser útil de forma desacoplada, exteriorizada fuera del monolito.
  3. Diviértase : identifique un dominio específico en el que desee centrarse y forme esta capacidad con límites bien definidos.
  4. Comprender cómo funciona el dominio : comprender cómo funciona el dominio en el monolito. En muchos casos, el microservicio compartirá un estado o una base de datos con el monolito. (Este acoplamiento implícito es lo que dificulta la modernización).
  5. Exponer una API : diseñe una API para esta capacidad y diseñe independientemente del monolito.
  6. Administre la API : configure el control de acceso, la limitación y la seguridad adecuados. Introduzca la infraestructura para administrar este proceso, como una puerta de enlace API .
  7. Duplicar : vuelva a implementar su capacidad en un microservicio independiente.
  8. Cree una nueva API : proporcione una API a su nueva implementación; esta API debe ser idéntica para ambas instancias, lo que requerirá gobernanza .
  9. Estado de réplica : réplica de condiciones compartidas en el servicio independiente. Esto puede ser un poco complicado, ya que implica exportaciones, importaciones u otras acciones de bases de datos para mover el estado del monolito al microservicio.
  10. Switch : exponer el microservicio y motivar su uso. Esto podría implicar un interruptor físico o exponer dos fuentes en paralelo durante algún tiempo. Independientemente, oculte la complejidad con una puerta de enlace API y asegúrese de que la funcionalidad sea idéntica para los consumidores.
  11. Deprecate : deje de usar la implementación monolith. Gateway ahora solo expone el nuevo microservicio.
  12. Retirar : retira la implementación anterior en el monolito.
  13. Saque más partido : siga repitiendo los pasos del 1 al 12 para cada servicio que pueda resultar útil como servicio independiente.

Si completa estos pasos, podrá replicar con éxito el comportamiento monolítico en un microservicio independiente. Al repetir este proceso pieza por pieza, los equipos de TI pueden retirar de forma lenta (y segura) la dependencia de un monolito.

Incorporación de la arquitectura basada en eventos

Gibson Nascimento, Sensedia, exploró los beneficios de llevar EDA a la TI heredada.

Además de los microservicios RESTful API-first, ¿de qué otras formas podemos potenciar nuestras aplicaciones heredadas? Gibson está de acuerdo en que los equipos no deberían abordar la descomposición de monolitos de una vez. Otra forma de exponer el legado sin romper el negocio, argumenta Gibson Nascimento, es mediante la creación de una capa impulsada por eventos .

Detrás de la mayoría de las aplicaciones que usamos, hay una aplicación de backend que entrega y procesa información. Este backend puede estar compuesto por múltiples capas y componentes. Un simple clic para comprar un boleto, por ejemplo, podría activar muchas funciones, como pagos, geolocalización, seguridad, información de backend y recopilación de datos de terceros.

Últimamente, la arquitectura de software conectado está adoptando integraciones más asincrónicas . Muchos momentos de negocios , como los llama Gibson, son provocados por eventos. La transformación de una TI heredada con una arquitectura impulsada por eventos (EDA) podría generar ganancias significativas para el uso interno y las integraciones de socios . Una forma de lograrlo es mediante el uso de un agente de eventos.

Habilitación heredada con el agente de eventos (interno)

Los microservicios permiten implementaciones más pequeñas, alcance reducido y mejor escalabilidad. Un agente de eventos amplía estos beneficios, proporcionando la capacidad de admitir volúmenes que el software heredado no puede soportar.

Según Gibson, un agente de eventos ayuda a la arquitectura interna al reducir significativamente la contrapresión. Tomemos una aplicación de hace 10 años: es probable que no se haya creado para admitir miles de transacciones por segundo.

Las plataformas de Event Broker ayudan a organizar las solicitudes colocando información en una cola para ser procesada. Definir una cadencia de solicitudes ayuda a la gestión del tráfico y es bueno para la gestión de errores, dice Gibson.

Habilitación heredada con el agente de eventos (externo)

Mientras que las API REST estándar permiten comunicaciones síncronas (solicitud-respuesta), los eventos permiten comunicaciones asíncronas . Estos escenarios reciben información cuando se desencadenan eventos; Gibson los llama momentos comerciales .

Además de agilizar las transacciones internas, Events Brokers aporta beneficios externos a la arquitectura heredada, dijo Gibson. Podrían ayudar a las empresas a definir nuevas estrategias, crear nuevas experiencias digitales y llegar a nuevos socios aprovechando nuevos mercados y nuevos clientes.

Consejos para el patrón estrangulador

El patrón del estrangulador es un excelente punto de partida para reducir el riesgo. Permite un proceso iterativo y estratégico para imaginar capacidades monolíticas como API. Los equipos podrían implementar un agente de eventos dentro del patrón de estrangulador sin cambiar demasiado el orden de las acciones.

Sin embargo, no espere que la modernización sea fácil, recordó Erik. Los equipos deben evitar reintroducir el acoplamiento. Además, crear dominios será un trabajo duro. Al delinear un dominio, el tamaño y el alcance son variables.

Por ejemplo, una única API de pagos técnicamente podría tener muchos dominios más pequeños, como depósito, verificación de fondos, procesamiento por lotes, remesas, etc. Las cosas pueden volverse granulares rápidamente. Un servicio financiero para el modelado de riesgos, señaló Gibson, podría actuar como un servicio independiente que podría evolucionar de forma independiente.

“Un gran fracaso de SOA fue que se trataba de exponer las API”, dijo Erik. "SOA no se centró en cómo gestionamos el código que expone las API".

Ya sea que 1 o 1000 microservicios sirvan una API, la complejidad debe ocultarse al consumidor. Ahora que las capas de gestión modernas hacen énfasis en el aspecto de gestión de código, ya que podría exponer esencialmente múltiples microservicios de manera unificada, dentro del mismo portal API uniforme. La misma lógica se aplica a los eventos empresariales, dijo Gibson.

Por último, comience poco a poco y no sobredimensione, reiteró Gibson. The Strangler Pattern evita un enfoque de Big Bang y privilegia la evolución lenta. Del mismo modo, aunque la orquestación de Kubernetes para microservicios puede parecer atractiva, es posible que no necesite un modelo de implementación sofisticado de inmediato. Deje que la biblioteca de microservicios crezca primero.

Transformación incremental heredada

La infraestructura heredada suele ser bastante opaca. No es fácil externalizar información vital para socios, clientes y uso interno. Sin embargo, al desarrollar una segunda vía en torno a una utilidad comercial monolítica especializada y alentar su uso a través de API, cualquier departamento de TI puede pasar lentamente de un monolito a microservicios, y hacerlo de forma segura. Haga eso lo suficiente y podría eliminar por completo una dependencia monolítica. Además, al utilizar nuevos estilos impulsados ​​por eventos, los arquitectos están bien posicionados para reimplementar el valor de TI oculto de una manera optimizada y de alto rendimiento.

Publicar un comentario

0 Comentarios