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


Menú principal de Patrones de diseño en la nube

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.

Menú principal de Patrones de diseño en la nube

About the author:

Matías Creimerman

Matías Creimerman
I’m a specialist in design, development and management of software solutions with almost 20 years of experience. Microsoft Certificated Professional (MCP). Expert in dot net and Microsoft technologies. Experience and skills in designing solutions in a wide range of commercial, industrial and production areas. Design of architectures, software applications and processes. Skills in leadership and team management. Tech trainer. Technology researcher. Self-taught and dedicated to continuous learning. Skills in estimation, quotation, projects proposals and solutions design. Entrepreneurial spirit. Strong Tech profile but also customer oriented. I perform roles as fullstack dev, tech consultant, technical referent, development leader, team leader, architect, cross leader, tech manager, tech director, trainer, ramp-up & follow-up teams, software factory manager, DevOps and release manager. Regular chess player and musician.

Professional Website

In

Blogger

Github

About Me

Portfolio

Wordpress - Arquitectura y desarrollo de software

Wordpress - Personal Blog

Microsoft - Youracclaim Badges

Microsoft - Tech Profile

Microsoft - ASP.NET Forum

tw
Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License
Creative Commons License
This content is property of Matias Creimerman Any misuse of this material will be punishable
This work is licensed under a International Copyright Law protects “original works of authorship”
including photographs, videos, and blog posts posted on social media sites
The content has no rights to be shared without authorization or citation to the author.
This content cannot be sold be adapted or modified partially or totally.
All content shared outside this blog that doesn’t belong to the author must have citations to the author.

Publicado por:

Matias Creimerman

I’m a specialist in design, development and management of software solutions with 20 years of experience. Microsoft Certificated Professional (MCP). Expert in dot net and Microsoft technologies. Experience and skills in designing solutions in a wide range of commercial, industrial and production areas. Design of architectures, software applications and processes. Skills in leadership and team management. Tech trainer. Technology researcher. Self-taught and dedicated to continuous learning. Skills in estimation, quotation, projects proposals and solutions design. Entrepreneurial spirit. Strong Tech profile but also customer oriented. I perform roles as fullstack dev, tech consultant, technical referent, development leader, team leader, architect, cross leader, tech manager, tech director, trainer, ramp-up & follow-up teams, software factory manager, DevOps and release manager. Regular chess player and musician.

Categorías arquitectura,Cloud,Patterns,TeoríaEtiquetas , , , , , , , , , , Deja un comentario

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