Patrones de diseño en la nube – Diseño sobre infraestructura


Cuando hablamos de diseño nos referimos al diseño general de la aplicación y de todas las estructuras y partes que la componen. Es el gran diseño arquitectónico.
Son importantes los patrones de diseño de arquitectura de la nube para lograr consistencia y coherencia, mantenimiento y simplificación, escalabilidad y reusabilidad.

Los patrones de diseño que hacen referencia al diseño sobre la infraestructura, son los siguientes:

Patrón embajador:
Es particularmente un patrón que permite diseñar determinados factores asociados a manejadores o complementos de las aplicaciones, como por ejemplo, el logging, monitoreo, seguridad, tracing, transacciones, etc. Normalmente funcionan como un proxy para interconectar o permitir comunicar distintas partes del sistema o de componentes o interactuar con sistemas legacy. Es muy útil para separar cuestiones ajenas a la funcionalidad de la aplicación en si, que los desarrolladores no deberían considerar para poder hacer un desarrollo.

Patrón de capa anticorrupción:
Es la base de DDD (Domain Driven Design). Es un patrón que permite diseñar subsistemas para evitar la dependencia entre ellos. Con esto se garantiza que al dividir las aplicaciones o arquitectura en subsistemas y diseñando la forma de comunicación entre ellos a modo de fachadas o adaptadores evitamos el acoplamiento y la dependencia. Habitualmente también sirve para diseñar formas de comunicación entre sistemas legacy o que se están migrando. Este patrón se puede implementar con adaptadores, fachadas o con capas de aplicación que comuniquen distintas capas y subsistemas.

Patrón de backends para frontends:
Este patrón describe un diseño en el cual se desarrollan backends para atender a los frontends. Hay que separar los servicios que serán consumidos por los distintos clientes y evitar la personalizacion o aplicaciones gigantes con múltiples interfaces. Un ejemplo simple seria poder separar el backend para un frontend mobile y otro para un frontend web. Con esto simplificamos y separamos cada servicios según la necesidad.

Patrón de calculo de consolidación de recursos:
Este patrón es importante tenerlo en cuenta en términos de costos de la arquitectura. Siempre es importante considerar los costos y como optimizar lo mejor posible la arquitectura para poder reducir los costos. Es un tema importante siempre a discutir con nuestros clientes.
Por ejemplo, es común que muchos apliquen patrones de principios de separación de conceptos o unidades pero esto muchas veces es un problema. Quizás esto ayude a simplificar la arquitectura de la aplicación, pero complica el despliegue de la misma y genera costos altos de procesamientos, de recursos y de implementación de infraestructura. Es habitual que muchos arquitectos desliguen esto al cliente o al proveedor de la nube, pero es importante considerarlo. Si tenemos muchas unidades de trabajo, como servicios independientes, aplicaciones segmentadas, bases de datos, etc, conseguiremos aumentar procesamientos y uso de recursos que pueden ser altamente escalables y propicios para la aplicación, pero un dolor de cabeza en costos.
La mejor opción es siempre, no separar tanto, sino dejar grupos de procesos unidos.

Patrón de tienda de configuración externa:
Este patrón implica tener puntos centralizados de configuración para reutilizar o no tener que configurar o publicar constantemente. También es útil para unidades o componentes de software empaquetado que se utiliza como componentes o librerías, ahí es importante tener un repositorio separado, que tenga sus versiones de componentes para que utilicen las aplicaciones.
Es común utilizarlo cuando tenemos configuraciones compartidas o componentes que se mantienen de forma independiente a las aplicaciones (por ej repositorios nuget).
Desde el código de las aplicaciones también se puede implementar el patrón, donde el algoritmo verifica el versionado de los paquetes o las configuración y obtiene la correspondiente.

Patrón de agregado de puerta de enlace:
Este patrón se utiliza cuando necesitamos una puerta de enlace que genere una sola entrada hacia el solicitante y hacia el interior agrupar el resultado de varios procesos.
Para que se entienda mejor, por ejemplo, supongamos que tenemos una aplicación móvil que consume varios microservicios en la nube. Esta aplicación consulta por un lado por ejemplo, el estado de cuenta, por otro el detalle de los últimos movimientos y por otro los saldos de cada cuenta, en una misma pantalla. Si quisiésemos reducir recursos y llamadas, un gateway de agregado seria la solución. El gateway funcionaria como único punto de entrada (la aplicación hace la consulta integra a este punto) y luego el gateway se encarga de consultar a los 3 microservicios y armar un resultado con los 3 resultados parciales. La aplicación móvil recibiría solamente un resultado de una sola consulta, en vez de 3 consultas con 3 resultados.
En los servicios mas populares de nube, ya existen componentes que realizan esta funcionalidad pero aun así, podríamos desarrollar la funcionalidad.
En conclusión este patrón es útil cuando queremos comunicarnos con múltiples backends en una sola operación.

Patrón de puerta de enlace fuera de carga:
Este patrón es utilizado para quitarle carga a los backends utilizando una puerta de enlace para realizar operaciones que no son propias del backend.
Por ejemplo, es muy utilizado para la certificación de seguridad de la comunicación. Supongamos que tenemos un backend que tiene encriptada sus respuestas, en vez de sumarle carga de procesamiento a cada servicio del backend, le quitamos al backend la encriptacion y colocamos una puerta de enlace que se encargue de ello. De esta forma, cada consulta al backend solo quedara encriptada entre el cliente solicitante y la puerta de enlace, y el propio backend no queda encriptado entre la puerta de enlace y cada uno de los servicios, moviéndole la responsabilidad y carga solo a la puerta de enlace.

Patrón de enrutamiento de puerta de enlace:
Es comúnmente utilizado en enrutamiento. La idea es tener una puerta de enlace como único punto de entrada y la misma puerta de enlace redirige la comunicación al servicio adecuado. Hay que considerar que puede generarnos cuellos de botella.

Patrón de elección de líder:
Este patrón es utilizado para coordinar procesos. En este caso, un proceso principal se encarga de administrar la ejecución o la acción de procesos. Supongamos un caso simple, varios procesos quieren acceder a un mismo archivo para leer determinada información. Uno de los procesos se encarga de administrar las solicitudes, si un proceso esta leyendo el archivo bloquea todos los demás hasta su liberación.
De este mismo modo se aplica a arquitecturas en la nube.

Patrón de tuberías y filtros:
Este patrón es utilizado para particionar la aplicación en procesos mas pequenos, escalables y reutilizables.
Un ejemplo seria una tubería o pipeline de un deploy. Nosotros podríamos hacer un solo proceso que implemente o deploye todo lo que necesitamos para una aplicación, pero normalmente estos procesos realizan muchos pasos que pueden atomizarse, particionarse en procesos mas pequenos reutilizables. Luego esos pequenos procesos (preparar el ambiente, deployar la actualización de la base de datos, deployar una nueva versión de la aplicación, etc) puede comunicarse con los procesos que necesitamos entrelazar para completar el proceso mas grande que teníamos al principio.
Es muy común también utilizarlo con patrones de cola de procesos.

Patrón sidecar:
Se utiliza para desacoplar y separar funcionalidad que requiere la aplicación pero que no es parte de si misma. Los procesos o aplicaciones aplicando el patrón de sidecar por si solas no sirven para nada, sino que dan asistencia y funcionalidad agregada a la aplicación principal que las utiliza, por ejemplo, un servicio de logging. El logging por si solo, no sirve, pero a modo sidecar con otra aplicación, le brinda logging para la aplicación en si. Tener el loggin junto al proceso o aplicación principal, genera acoplamiento con la misma y sobrecarga de procesos. Incluso utilizar el patrón sidecar permite aislar la implementación y el versionado de cada parte.

Volver al menú

 

Matías Creimerman

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s