Patrones para el diseño de aplicaciones en la Nube

Patrones para el diseño de aplicaciones para la Nube

Jim Saenz | Especialista Microsoft SharePoint

@JimSaenzDedios

AGENDA

01 | Categoría de problemas Comunes

02 | Patterns for Resiliency & Availability

03 | Patterns for Scalability

04 | Área de desarrollo

05 | Aplicaciones de ejemplo


1.1 | Resiliency

1.2 | Availability

1.3 | Performance and Scalability

1.4 | Data Management

1.5 | Design and Implementation

1.6 | Messaging

1.7 | Management and Monitoring

1.8 | Security


1.1 | Resiliency

La resistencia es la capacidad de un sistema para manejar con gracia y recuperarse de los fallos.

La naturaleza de cloud hosting, donde las aplicaciones son a menudo varios inquilinos, el uso compartido de

servicios de plataforma, compiten por recursos y ancho de banda, se comunican a través de Internet, y

ejecutarse en hardware significa que hay una mayor probabilidad de que surjan fallas permanentes tanto

transitorios y más . La detección de fallos y la recuperación rápida y eficaz, es necesario mantener la

resistencia.


1.2 | Availability

Disponibilidad define la proporción de tiempo que el sistema es funcional y de trabajo. Se ve afectada por errores

del sistema, problemas de infraestructura, los ataques maliciosos y la carga del sistema. Por lo general se mide

como un porcentaje de tiempo de actividad.

Aplicaciones en la nube suelen proporcionar a los usuarios un acuerdo de nivel de servicio (SLA), lo que significa

que las aplicaciones deben ser diseñadas e implementadas de una manera que maximiza la disponibilidad.


1.3 | Performance and Scalability

El rendimiento es una indicación de la capacidad de respuesta de un sistema para ejecutar cualquier acción

dentro de un intervalo de tiempo dado, mientras que la escalabilidad es la capacidad de un sistema, ya sea para

manejar los aumentos de carga sin impacto en el rendimiento o para los recursos disponibles para

incrementarse fácilmente. Aplicaciones en la nube por lo general se encuentran con cargas de trabajo variables

y picos de actividad.

Predicción de estos, especialmente en un escenario multi-tenant, es casi imposible. En su lugar, las aplicaciones

deben ser capaces de escalar dentro de los límites para satisfacer los picos de demanda, y la escala en que la

demanda disminuye.

Preocupaciones de escalabilidad no sólo computan los casos, pero otros elementos como el almacenamiento de

datos, infraestructura de mensajería y más.


2.1 | Circuit Breaker

2.2 | Compensating Transaction

2.3 | Leader Election

2.4 | Retry

2.5 | Scheduler Agent Supervisor

2.6 | Health Endpoint Monitoring

2.7 | Queue-based Load Leveling

2.8 | Throttling


2.1 | Circuit Breaker

Manejo de fallos que pueden tener una cantidad variable de tiempo para rectificar cuando se conecta a un

servicio remoto o recurso.

Este patrón puede mejorar la estabilidad y resistencia de una aplicación.



Implementar controles funcionales dentro de una aplicación que herramientas externas pueden acceder a través

de los extremos expuestos en intervalos regulares.

Este patrón puede ayudar a verificar que las aplicaciones y los servicios están funcionando correctamente.


2.8 | Throttling

Controlar el consumo de los recursos utilizados por una instancia de una aplicación, un inquilino individual, o un

servicio completo.

Este patrón puede permitir que el sistema siga funcionando y cumplir con los acuerdos de nivel de servicio, aun

cuando un aumento de la demanda supone una carga extrema en los recursos.


3.1 | Cache-aside

3.2 | Competing Consumers

3.3 | CQRS

3.4 | Event Sourcing

3.5 | Index Table

3.6 | Materialized View

3.7 | Priority Queue

3.8 | Queue-based Load Leveling


3.9 | Sharding

3.10 | Static Content Hosting

3.11 | Throttling


3.3 | CQRS

Command and Query Responsability Segregation.

Separar las operaciones que leen datos de los datos que actualización mediante el uso de interfaces separadas.

Este patrón puede maximizar el rendimiento, la escalabilidad y la seguridad, el apoyo a la evolución del sistema

en el tiempo a través de una mayor flexibilidad, y evitar comandos de actualización de causan combinaciones de

conflictos en el nivel de dominio.


3.4 | Event Sourcing

Utilice un append-only store para grabar la serie completa de acontecimientos que describen las acciones

emprendidas en los datos en un dominio, en lugar de almacenar sólo la situación actual, por lo que la tienda se

puede utilizar para materializar los objetos de dominio.

Este patrón puede simplificar las tareas en dominios complejos, evitando la necesidad de sincronizar el modelo

de datos y el dominio de negocio, mejorar el rendimiento, escalabilidad y capacidad de respuesta; proveer

consistencia de los datos transaccionales, y mantener pistas de auditoría completas y la historia que pueden

permitir acciones de compensación.


3.6 | Materialized View

Generar vistas previamente llenas sobre los datos en uno o más almacenes de datos cuando los datos tiene el

formato de una manera que no favorece las operaciones de consulta necesarios.

Este patrón puede ayudar a apoyar consulta eficiente y la extracción de datos y mejorar el rendimiento de la

aplicación.


3.9 | Sharding (database architecture)

Divida un almacén de datos en un conjunto de particiones fragmentos horizontales.

Particionamiento horizontal es un principio de diseño de base de datos mediante el cual las filas de una tabla de

base de datos se llevan a cabo por separado, en lugar de estar divididos en columnas (que es lo que la

normalización y la partición vertical hacen, en diferentes grados). Cada partición forma parte de un fragmento,

que a su vez puede ser ubicado en un servidor de base de datos separada o ubicación física.

Son numerosas las ventajas de este enfoque de partición. Puesto que las tablas están divididos y distribuidos en

múltiples servidores , se reduce el número total de filas en cada tabla en cada base de datos . Esto reduce el

tamaño del índice , lo que generalmente mejora el rendimiento de la búsqueda . Un fragmento de base de datos

se puede colocar en hardware separado , y múltiples fragmentos puede ser colocado en múltiples máquinas .

Este patrón puede mejorar la escalabilidad al almacenar y acceder a grandes volúmenes de datos.


4.1 | Data Replication and Synchronization

4.2 | Multiple Datacenter Deployment

4.3 | Autoscaling

4.4 | Caching

4.5 | Data Consistency

4.6 | Data Partitioning



4.1 | Data Replication and Synchronization

Al implementar una aplicación de más de un centro de datos, tales como la nube y ubicaciones en-premisas,

debe considerar cómo va a replicar y sincronizar los datos de cada instancia de la aplicación utiliza con el fin de

maximizar la disponibilidad y el rendimiento, garantizar la coherencia, y reducir al mínimo la transferencia de

datos cuesta entre ubicaciones.


4.2 | Multiple Datacenter Deployment

Implementación de una aplicación a más de un centro de datos puede proporcionar beneficios tales como una

mayor disponibilidad y una mejor experiencia de usuario a través de áreas geográficas más amplias.

Sin embargo, existen desafíos que deben ser resueltos, como la sincronización de datos y las limitaciones

reglamentarias.


4.3 | Autoscaling

Controlar constantemente el rendimiento y la ampliación de un sistema de adaptación a las cargas de trabajo

fluctuantes para cumplir con los objetivos de capacidad y optimizar los costos operativos puede ser un proceso

laborioso.

Puede que no sea posible llevar a cabo estas tareas de forma manual. Aquí es donde la autoescala es útil.


4.4 | Caching

El almacenamiento en caché es una técnica común que tiene como objetivo mejorar el rendimiento y la

escalabilidad de un sistema copiando temporalmente los datos de acceso frecuente a un almacenamiento rápido

situado junto a la aplicación.

El almacenamiento en caché es más efectiva cuando una instancia de aplicación lee repetidamente los mismos

datos, sobre todo si el almacén de datos original es lenta en relación a la velocidad de la memoria caché, que

está sujeta a un alto nivel de contención, o está muy lejos dando lugar a la latencia de red.


4.5 | Data Consistency

Aplicaciones en la nube suelen utilizar datos que se dispersan a través de almacenes de datos. La gestión y el

mantenimiento de la coherencia de datos en este entorno puede convertirse en un aspecto crítico del sistema,

en particular en cuanto a los problemas de concurrencia y disponibilidad que pueden surgir. Con frecuencia

necesita para operar una fuerte consistencia para el rendimiento.

Esto significa que puede que tenga que diseñar algunos aspectos de sus soluciones en torno a la noción de

consistencia eventual y aceptar que los datos que las aplicaciones utilizan pueden no ser completamente

consistente todo el tiempo.


4.6 | Data Partitioning

En muchas soluciones a gran escala, los datos se divide en particiones separadas que se pueden gestionar y

acceder por separado.

La estrategia de partición debe ser elegido cuidadosamente para maximizar los beneficios y reducir al mínimo

los efectos adversos.

Las particiones pueden ayudar a mejorar la escalabilidad, reducir la contención, y optimizar el rendimiento.









This example shows how a worker role instance can become a leader among a group of peer instances. The leader

can then perform tasks that coordinate and control the other instances; these tasks should be performed by only

one instance of the worker role. The leader is elected by acquiring a blob lease.



This example shows how you can set up a web endpoint that checks the health of dependent services by

returning appropriate status codes. The endpoints are designed to be consumed by a watchdog monitoring

service such as Windows Azure endpoint monitoring, but you can open and invoke the endpoint operations from

a browser to see the results. You can also deploy and configure your own endpoint monitoring tool of choice to

send requests to the service operations and analyze the responses received.



This example contains two components: the Sender worker role is responsible for sending messages to a Service

Bus queue, and the Receiver worker role retrieves messages from the queue and processes them. The Receiver

worker role is configured to run with two instances to simulate competition between consumers.



This example shows how you can implement priority queues by using Service Bus Topics and Subscriptions. A

worker role is responsible for sending messages to a topic. It assigns a priority to each one. The receiving worker

roles read messages from subscriptions that have the corresponding priority. In the example, The

PriorityQueue.High worker role runs with two instances, whereas the PriorityQueue.Low worker runs only with

one. This ensures that high priority messages are read from the queue more quickly than low priority messages.



This example shows how to reference static content from a publicly accessible storage service. The example

contains a Windows Azure web role, which hosts a web application that references JavaScript files and images

deployed to a Windows Azure storage account. This type of content is typically deployed to the storage account as

part of the application deployment process. However, to simplify the example, these files are deployed to the

storage account when the application starts up.

Patrones para el diseño de aplicaciones para la Nube

Jim Saenz | Especialista Microsoft SharePoint

@JimSaenzDedios

Date post:	03-Jul-2015
Category:	Technology
Upload:	jim-saenz
View:	323 times
Download:	3 times

Patrones para el diseño de aplicaciones en la Nube

Technology