Patrones de diseño para la nube

 Explicaré esto en español, pues hay muchas fuentes en Inglés y creo que esto es crítico y debemos entenderlo muy bien! 

Estos patrones de diseño los clasificaremos en:

• Diseño e implementación: Impacta en consistencia y coherencia en el diseño de sus componentes, además de despliegue, mantenabilidad a nivel administración y desarrollo, reusabilidad para permitir que el componente y sus subsistemas sean usados por otras aplicaciones en otros escenarios.
• Mensajería: La naturaleza de las aplicaciones de la nube requiere una infraestructura de mensajería que conecta servicios y componentes, de manera poco acoplada para maximizar la escalabilidad. Los mensajes asincrónicos proveen sus beneficios, pero genera otros problemas como ordenamiento de mensajes, manejo de mensajes "envenenados", idempotencia, etc.
• Administración y monitoreo: Dado que no se posee acceso a los servidores remotos, es importante exponer información en tiempo de ejecusión para permitir a los administradores y operadores administrar y monitorear el sistema, como así dar soporte sin la necesidad de requerir que la aplicación se detenga y se despliegue.
• Rendimiento y escalabilidad: Tipicamente las aplicaciones en la nube sufren variación en su demanda y picos en su actividad. Predecir estos comportamientos, o esencialmente un "anti-tenant" es imposible. La aplicación debe ser capaz de escalar si la demanda crece y decrecer cuando la demanda baja. Esto no solo conciernte a los servidores, sino a elementos como almacenamiento de datos, estructura de mensajería, etc.
• Resilencia: Basicamente es cuando un sistema se recupera de fallas, sobre todo en un contexto donde los servidores compiten por recursos, ancho de banda, etc es un ambiente propicio a que algunas fallas surjan.
• Seguridad: Existen muchos usuarios poco confiables sobre todo en aplicaciones abiertas a internet. Las aplicaciones deben diseñarse y desplegarse en una manera que esté protejida de ataques maliciosos.

Cache-aside

Clasificación	Rendimiento y escalabilidad.
Descripción	Carga los datos a pedido en un cache desde un repositorio de datos.
Contexto y Problema	Si bien las aplicaciones suelen usar cache, normalmente no resulta práctico esperar que los datos sean coherentes con los datos en el repositorio de datos. Las aplicaciones deben implementar una estrategia que ayude a garantizar los datos sean fidedignos.
Solución	Existen sistemas comerciales de lectura y escritura simultánea o retrasada. Si los datos no están en caché, se recuperan de forma transparente del repositorio de datos. Cualquier modificación en la memoria caché, se escribe en el repositorio de datos. Una aplicación puede emular la funcionalidad de caché de lectura directa implementado la estrategia de almacenamiento Cache -aside (caché aparte). Esta estrategia carga de maanera eficaz en la caché según demanda.
Problemas y Considerandos	Vida útil de los datos almacenados en caché: Hay que asegurarse que la política de caducidad coincida con el patrón de acceso de las aplicaciones. No haga que el período de vencimiento sea demasiado corto porque esto puede hacer que las aplicaciones recuperen continuamente datos del repositorio de datos y los agregue a la caché. Tampoco viceversa  porque los datos pueden quedar obsoletos. Los datos cacheados son para datos estáticos o que se leen con mucha frecuencia. Datos de desalojo: Conviene desalojar la cache, si es de manera global hay que tener en cuenta que no haya datos costosos de recuperar. También se puede configurar en particular. Esto conviene hacerlo pues los cachés no poseen gran capacidad de almacenamiento como lo son los repositorio de datos. Preparado de caché: Muchas aplicaciones rellenan previamente la caché con los datos que la aplicación podría requerir. Este patrón puede seguir siendo útil en estos casos. Caché local (en memoria): Al existir varias instancias de la aplicación, si se realiza una estrategia de caché local, habrá inconsistencias con las otras instancias, salvo que se actualice con más frecuencia. Es mejor en estos escenarios investigar por mecanismos de caché compartido o distribuído.
Cuándo usar este patrón	Cuándo usarlo:  Si no proporciona operaciones nativas de lectura y escritura. La demanda de recursos es impredecible. Este patrón permite que las aplicaciones carguen datos bajo demanda. No hace suposiciones sobre qué datos requerirá una aplicación de antemano. Cuándo no usarlo: Si el conjunto de datos es estático. Si los datos caben en el espacio de caché diponible, mejor preparar la caché con los datos iniciales y aplicar una política que evite que los datos caduquen. Si se almacena en caché los datos de sesión en una granja de servidores web. En este entorno, se debe evitar introducir dependencias basadas en afinidad cliente-servidor.
Librerías y Aplicaciones	Redis: Es una base de datos en memoria que se utiliza a menudo como sistema de caché.  Memcached: Similar a Redis. Ehcache: Biblioteca de cache para Java. Guava Cache: Proporciona una forma de implementar cachés locales en aplicaciones java. Caffeine: Sucesor de Guava Cache, también para Java. Sprint Cache: Facilita la implementación de diferentes patrones de caché. Microsoft.Extenstions.Caching: Ofrece varias estrategias de caché, especialmente para ASP.NET Core Varnish: Si bien es más conocido como un caché http inverso, Varnish puede configurarse para comportarse como Cache Aside. Windows Azure Cache
Patrones similares	Caching Guidance Data consistency primer

Circuit Braker

Clasificación	Resilencia
Descripción	Maneja fallas que pueden tardar una cantidad variable de tiempo en rectificarse al conectarse a un servicio o recurso remoto. Este patrón puede mejorar la estabilidad y resistencia de una aplicación.
Contexto y Problema	Si bien las aplicaciones suelen usar cache, normalmente no resulta práctico esperar que los datos sean coherentes con los datos en el repositorio de datos. Las aplicaciones deben implementar una estrategia que ayude a garantizar los datos sean fidedignos.
Solución	Existen sistemas comerciales de lectura y escritura simultánea o retrasada. Si los datos no están en caché, se recuperan de forma transparente del repositorio de datos. Cualquier modificación en la memoria caché, se escribe en el repositorio de datos. Una aplicación puede emular la funcionalidad de caché de lectura directa implementado la estrategia de almacenamiento Cache -aside (caché aparte). Esta estrategia carga de maanera eficaz en la caché según demanda.
Problemas y Considerandos	Vida útil de los datos almacenados en caché: Hay que asegurarse que la política de caducidad coincida con el patrón de acceso de las aplicaciones. No haga que el período de vencimiento sea demasiado corto porque esto puede hacer que las aplicaciones recuperen continuamente datos del repositorio de datos y los agregue a la caché. Tampoco viceversa  porque los datos pueden quedar obsoletos. Los datos cacheados son para datos estáticos o que se leen con mucha frecuencia. Datos de desalojo: Conviene desalojar la cache, si es de manera global hay que tener en cuenta que no haya datos costosos de recuperar. También se puede configurar en particular. Esto conviene hacerlo pues los cachés no poseen gran capacidad de almacenamiento como lo son los repositorio de datos. Preparado de caché: Muchas aplicaciones rellenan previamente la caché con los datos que la aplicación podría requerir. Este patrón puede seguir siendo útil en estos casos. Caché local (en memoria): Al existir varias instancias de la aplicación, si se realiza una estrategia de caché local, habrá inconsistencias con las otras instancias, salvo que se actualice con más frecuencia. Es mejor en estos escenarios investigar por mecanismos de caché compartido o distribuído.
Cuándo usar este patrón	Cuándo usarlo:  Si no proporciona operaciones nativas de lectura y escritura. La demanda de recursos es impredecible. Este patrón permite que las aplicaciones carguen datos bajo demanda. No hace suposiciones sobre qué datos requerirá una aplicación de antemano. Cuándo no usarlo: Si el conjunto de datos es estático. Si los datos caben en el espacio de caché diponible, mejor preparar la caché con los datos iniciales y aplicar una política que evite que los datos caduquen. Si se almacena en caché los datos de sesión en una granja de servidores web. En este entorno, se debe evitar introducir dependencias basadas en afinidad cliente-servidor.
Librerías y Aplicaciones	Redis: Es una base de datos en memoria que se utiliza a menudo como sistema de caché.  Memcached: Similar a Redis. Ehcache: Biblioteca de cache para Java. Guava Cache: Proporciona una forma de implementar cachés locales en aplicaciones java. Caffeine: Sucesor de Guava Cache, también para Java. Sprint Cache: Facilita la implementación de diferentes patrones de caché. Microsoft.Extenstions.Caching: Ofrece varias estrategias de caché, especialmente para ASP.NET Core Varnish: Si bien es más conocido como un caché http inverso, Varnish puede configurarse para comportarse como Cache Aside. Windows Azure Cache
Patrones similares	Caching Guidance Data consistency primer

https://github.com/gbrancolini/cloud-design-patterns/tree/main/CacheAside