Contenido


Desarrollo rápido de aplicaciones (parte 4): uso de patrones de desarrollo

Comments

Tabla de contenidos

Introducción
Patrones de desarrollo
Patrón de aplicación de página única (SPA)
Patrón de backend para frontend (BFF)
Entidad y patrones agregados
Patrones de servicios
Patrón de microservicios de adaptador
Patrón de aplicación Strangler
Qué hacer a continuación

Introducion

En esta serie de 6 partes sobre el desarrollo de aplicaciones de microservicios, presentamos el contexto para la definición de un proyecto piloto basado en la nube que resulte ideal para las necesidades actuales y posibilite la preparación para una decisión de adopción de nube de largo plazo.

En la parte 4, examinaremos los patrones para el desarrollo de aplicaciones de microservicios.

Estas son las partes de la serie:

Patrones de desarrollo

Martin Fowler creó el principio de diseño que establece que todo equipo debe organizar los microservicios de una aplicación a partir de las capacidades empresariales esenciales. Existen patrones establecidos para el desarrollo de microservicios para la aplicación monolítica que su equipo está transformando, así como para el desarrollo de microservicios partiendo de cero en un contexto nativo de la nube.

Sea cual sea su camino de adopción de la nube, estos patrones proporcionan un marco básico para la evolución de una aplicación basada en microservicios.

Patrón de aplicación de página única (SPA)

Con la convergencia de los navegadores más poderosos, las redes más rápidas y los lenguajes del lado del cliente, muchas interfaces web empezaron a incorporar todas las funcionalidades en aplicaciones de página única. El usuario tiene acceso a través de una interfaz que nunca vuelve a cargar la página de aterrizaje o posibilita una navegación distante de la experiencia inicial. Creadas a partir de una combinación de HTML, CSS y JavaScript, estas aplicaciones responden a las entradas del usuario por medio de llamadas de servicio dinámicas a servicios basados en REST de respaldo que actualizan partes de la pantalla, en lugar de realizar la derivación a una página completamente nueva. Esta arquitectura de aplicación suele simplificar la experiencia de frontend, aumentando la responsabilidad asociada a los servicios de respaldo.

Patrón de backend para frontend (BFF)

Si bien la aplicación de página única resulta efectiva para experiencias de usuario de canal único, este patrón proporciona resultados deficientes cuando se cuenta con varias experiencias de usuario en diferentes canales, lo cual a veces sobrecarga el navegador con la gestión de las interacciones con muchos servicios de respaldo basados en REST asincrónicos.

El patrón de backend para frontend representa una evolución en la que un servicio agregador de backend reduce la cantidad total de llamadas desde el navegador y, a su vez, maneja la mayor parte de la comunicación dentro de servicios de respaldo externos, devolviendo finalmente una solicitud más fácil de gestionar al navegador. El patrón permite que los equipos de frontend desarrollen e implementen su propio servicio de agregador de backend (BFF) para manejar todas las llamadas de servicio externas necesarias para su experiencia del usuario particular, que con frecuencia se diseña para un navegador, una plataforma móvil o un dispositivo de IoT específicos.  El mismo equipo crea tanto la experiencia del usuario como el BFF, muchas veces con el mesmo lenguaje, mejorando el desempeño general de la aplicación y la entrega de la aplicación.

En esta arquitectura, por ejemplo, se puede ver una capa de microservicios a la cual se accede por medio de la puerta de enlace de API de frontend. Estos BFF (móviles, web o compartidos) invocan otra capa de microservicios Java que se pueden reutilizar. En los proyectos efectivos, normalmente otro equipo escribe este elemento.  Los BFF y los microservicios Java se comunican entre sí por medio de un tejido de microservicios (como Istio).

Entidad y patrones agregados

Una entidad es un objeto que se distingue principalmente por su identidad. Las entidades son los objetos en el proceso de modelado que disponen de identificadores únicos.

En su libro "Domain-Driven Design" (Diseño orientado al dominio), Eric Evans explica que los objetos de entidad necesitan ciclos de vida de objeto bien definidos, así como una buena definición de cuál es la relación de identidad básica (qué significa ser lo mismo que otra cosa).

Sabemos del modelado de entidad-relación que a veces las entidades son bien definidas y cuentan con un identificador bien conocido, pero puede que no existan de manera independiente. Una combinación de entidades es un agregado. En los casos en que contamos con un clúster de entidades que necesitan mantenerse en unísono, de manera coherente, podemos considerar estas entidades como dependientes y necesitamos asegurarnos de saber cuál es la raíz del agregado, ya que la raíz define el ciclo de vida de las entidades dependientes.

Para los equipos de desarrollo que no están acostumbrados a diseñar en términos de interfaces empresariales, los patrones de entidad y de agregado son útiles para identificar conceptos empresariales específicos que se asignan directamente a los microservicios, realizando funciones empresariales amplias.

Naturalmente, la decisión de implementar todas las entidades empresariales como un microservicio no significa que todos sus problemas de diseño están resueltos. También necesitará considerar cómo se implementará el microservicio y cómo el microservicio está relacionado con otros servicios en su aplicación empresarial general.

Los microservicios empresariales tienden a contar con estado y a disponer de datos propios en una base de datos que administran.

Patrones de servicios

Los patrones de servicios ofrecen una manera de mapear las operaciones que no pertenecen conceptualmente a objetos/entidades específicos ni se agregan en un enfoque basado en entidad.

Evans sugiere que modelemos estos objetos como interfaces independientes denominadas "servicios", en conformidad con estas reglas:

  • Deben ser sin estado
  • La interfaz del servicio debe definirse en términos de otros elementos del modelo de dominio (entidades y objetos de valor)
  • El servicio debe hacer referencia a un concepto de dominio que no corresponda naturalmente a ninguna entidad particular u objeto de valor.

Patrón de microservicios de adaptador

El Patrón de microservicios de adaptador se adapta, según sea necesario, entre las API orientadas al negocio construidas mediante técnicas de mensajería ligera o RESTful (con las mismas técnicas orientadas hacia el dominio que se utilizan en los microservicios tradicionales) y un servicio SOAP basado en WS-* o de API heredada.

La adaptación es necesaria, por ejemplo, cuando un equipo de desarrollo no cuenta con un control descentralizado del origen de datos de una aplicación.

El microservicio de adaptador ajusta y traduce los servicios existentes (normalmente, basados en función) en una interfaz de REST basada en entidad. Este tipo de microservicio considera cada nueva interfaz de entidad como un microservicio, el cual se construye, se gestiona y se escala de manera independiente.

En muchos casos, se puede realizar de manera directa la conversión de una interfaz basada en función (por ejemplo, una interfaz creada por medio de SOAP) a una interfaz basada en concepto empresarial. Considere esto como la transición de un enfoque basado en verbos (funcional) a un enfoque basado en sustantivos (entidad).

Con frecuencia, las funciones expuestas en un extremo SOAP corresponden específicamente a las operaciones CRUD (crear, leer, actualizar, eliminar) de un tipo de objeto empresarial único y, por lo tanto, se asignan con facilidad a una interfaz de REST.

A continuación, estas operaciones simplemente envían los mensajes SOAP correspondientes al extremo SOAP existente y luego traducen los tipos de datos XML de las operaciones SOAP correspondientes a los tipos de datos JSON para la nueva interfaz de REST.

Patrón de aplicación Strangler

Este patrón se basa en el hecho de que las empresas y las aplicaciones nunca parten de cero. El patrón Strangler nos ayuda a gestionar la refactorización de aplicaciones monolíticas por etapas.

Como este patrón es fundamental para la transformación de las aplicaciones existentes en microservicios (lo cual es un tema recurrente en esta serie), vale la pena analizarlo de manera detallada. Su nombre metafórico se basa en el fenómeno botánico de las enredaderas que "estrangulan" el árbol al cual se adhieren.

La idea es que se puede utilizar la estructura de una aplicación web (el hecho de que la aplicación se crea a partir de URI individuales que asignan una funcionalidad a diferentes aspectos de un dominio empresarial) para separar una aplicación en diferentes dominios funcionales y reemplazar dichos dominios por nuevas implementaciones basadas en microservicios, dominio por dominio. Estos dos aspectos constituyen aplicaciones separadas que existen una al lado de la otra en el mismo espacio de URI. Con el paso del tiempo, la nueva aplicación refactorizada reemplaza a la aplicación original, hasta que finalmente se puede eliminar la aplicación monolítica.

El patrón Strangler incluye los siguientes pasos:

  • Transformación: cree un nuevo sitio paralelo (en una plataforma de nube como Bluemix, por ejemplo, o en su entorno existente) basado en el enfoque analizado en la entrada de blog anterior.
  • Coexistencia: mantenga el sitio existente en el lugar en que se encuentra durante algún tiempo. De manera gradual, realice el redireccionamiento del sitio existente al nuevo sitio para proporcionar funcionalidades recién implementadas.
  • Eliminación: elimine las funcionalidades antiguas del sitio existente (o simplemente deje de mantenerlas) cuando el tráfico deje de existir en esa parte del sitio anterior.

Lo bueno de este patrón es que su aplicación le permite crear valor incremental mucho más rápido que si tratara de hacer todo a través de una sola migración completa. Además, le proporciona un enfoque gradual para la adopción de los microservicios; si considera que el enfoque no funciona en su entorno por alguna razón, podrá cambiar de dirección con facilidad.

¿Cuál es la mejor manera de aplicar el patrón Strangler?

Si una página es demasiado pequeña y una aplicación completa es demasiado grande, ¿cuál es el nivel correcto de granularidad para la aplicación del patrón Strangler?  Para tener éxito, usted debe combinar dos aspectos distintos de la refactorización de aplicaciones:

  • Refactorización del backend para la adopción de un diseño de microservicios (se puede decir que esta es la parte interna)
  • Refactorización del frontend para adaptarlo a los microservicios y realizar los nuevos cambios funcionales asociados a la refactorización (se puede decir que esta es la parte externa)

Comencemos con la parte interna:

  1. Empiece por identificar los contextos limitados de su diseño de aplicación. Un contexto limitado es un marco conceptual compartido que restringe el significado de varias entidades en un conjunto más amplio de modelos empresariales. En una aplicación para compañía aérea, la reserva de vuelos constituye un contexto limitado, y el programa de fidelización de la compañía constituye un contexto limitado distinto. Aunque ambos contextos pueden presentar términos en común (como “vuelo”), las maneras en que estos términos se utilizan y se definen son muy diferentes.
  2. Elija el contexto limitado más pequeño y menos costoso. Clasifique los demás contextos limitados del menos complejo al más complejo. Deberá empezar por los contextos limitados menos complejos para probar el valor de su refactorización (y resolver los problemas relativos a la adopción del proceso) antes de hacerse cargo de las tareas de refactorización más complejas (y posiblemente más costosas).
  3. Planifique conceptualmente los microservicios dentro del contexto (mediante la aplicación del patrón de entidad, del patrón agregado y del patrón de servicios). En este punto, no estamos tratando diseñar detalladamente de todos los microservicios. Solo deseamos comprender cuáles microservicios probablemente existirán, para que podamos utilizar esta aproximación en los pasos siguientes.
  1. Analice las relaciones entre las pantallas de su UI existente. En especial, busque factores de ralentización que estén asociados a varias páginas. Si estuviera creando un sitio web para una compañía aérea, un factor de ralentización podría ser la reserva de pasajes, que constaría de varias páginas, las cuales proporcionarían la información necesaria para completar el proceso de reserva. Un factor de ralentización distinto podría estar asociado al registro en el programa de fidelización de la compañía. En cualquier caso, comprender el conjunto de factores de ralentización lo ayudará a pasar al paso siguiente de la refactorización.
  2. Al examinar su UI existente o su nueva UI, deberá buscar los aspectos que corresponden a los microservicios identificados en la parte interna. Necesitará identificar cuáles flujos corresponden a cuáles microservicios. El resultado de este paso es una lista de factores de ralentización de un lado de la página, con una lista de los microservicios que podrían implementar cada factor.
  3. Las partes se deben dimensionar tomando en cuenta que los cambios de UI tienen que ser autoconsistentes. Por lo tanto, considere que uno o varios factores de ralentización representan el tamaño mínimo del cambio que se puede poner a disposición del cliente (pero las partes pueden ser mayores). Por ejemplo, es posible que toda la fidelización del cliente constituya una parte única, aun cuando cuente con dos o tres flujos independientes.
  4. Elija entre lanzar cada parte de manera completa o dividirla en etapas.

Qué hacer a continuación:

Rick Osowski

Arquitecto principal de solución


Recursos para Descargar


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Big data y analytics
ArticleID=1051527
ArticleTitle=Desarrollo rápido de aplicaciones (parte 4): uso de patrones de desarrollo
publish-date=10272017