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 | ...
01 | Categoría de problemas Comunes
1.1 | Resiliency
1.2 | Availability
1.3 | Performance and Scalability
1.4 | Data Manag...
01 | Categoría de problemas Comunes
1.1 | Resiliency
La resistencia es la capacidad de un sistema para manejar con gracia ...
01 | Categoría de problemas Comunes
1.2 | Availability
Disponibilidad define la proporción de tiempo que el sistema es fun...
01 | Categoría de problemas Comunes
1.3 | Performance and Scalability
El rendimiento es una indicación de la capacidad de ...
02 | Patterns for Resiliency & Availability
2.1 | Circuit Breaker
2.2 | Compensating Transaction
2.3 | Leader Election
2.4...
02 | Patterns for Resiliency & Availability
2.1 | Circuit Breaker
Manejo de fallos que pueden tener una cantidad variable ...
02 | Patterns for Resiliency & Availability
2.6 | Health Endpoint Monitoring
Implementar controles funcionales dentro de u...
02 | Patterns for Resiliency & Availability
2.8 | Throttling
Controlar el consumo de los recursos utilizados por una insta...
03 | Patterns for Scalability
3.1 | Cache-aside
3.2 | Competing Consumers
3.3 | CQRS
3.4 | Event Sourcing
3.5 | Index Tabl...
03 | Patterns for Scalability
3.9 | Sharding
3.10 | Static Content Hosting
3.11 | Throttling
03 | Patterns for Scalability
3.3 | CQRS
Command and Query Responsability Segregation.
Separar las operaciones que leen da...
03 | Patterns for Scalability
3.4 | Event Sourcing
Utilice un append-only store para grabar la serie completa de acontecim...
03 | Patterns for Scalability
3.6 | Materialized View
Generar vistas previamente llenas sobre los datos en uno o más almac...
03 | Patterns for Scalability
3.9 | Sharding (database architecture)
Divida un almacén de datos en un conjunto de particio...
04 | Área de desarrollo
4.1 | Data Replication and Synchronization
4.2 | Multiple Datacenter Deployment
4.3 | Autoscaling
...
04 | Área de desarrollo
04 | Área de desarrollo
4.1 | Data Replication and Synchronization
Al implementar una aplicación de más de un centro de da...
04 | Área de desarrollo
4.2 | Multiple Datacenter Deployment
Implementación de una aplicación a más de un centro de datos ...
04 | Área de desarrollo
4.3 | Autoscaling
Controlar constantemente el rendimiento y la ampliación de un sistema de adaptac...
04 | Área de desarrollo
4.4 | Caching
El almacenamiento en caché es una técnica común que tiene como objetivo mejorar el r...
04 | Área de desarrollo
4.5 | Data Consistency
Aplicaciones en la nube suelen utilizar datos que se dispersan a través de ...
04 | Área de desarrollo
4.6 | Data Partitioning
En muchas soluciones a gran escala, los datos se divide en particiones sep...
05 | Aplicaciones de ejemplo
5.1 | Leader Election
5.2 | Health Endpoint Monitoring
5.3 | Competing Consumers
5.4 | Priori...
05 | Aplicaciones de ejemplo
5.1 | Leader Election
This example shows how a worker role instance can become a leader among...
05 | Aplicaciones de ejemplo
5.2 | Health Endpoint Monitoring
This example shows how you can set up a web endpoint that ch...
05 | Aplicaciones de ejemplo
5.3 | Competing Consumers
This example contains two components: the Sender worker role is res...
05 | Aplicaciones de ejemplo
5.4 | Priority Queue
This example shows how you can implement priority queues by using Servic...
05 | Aplicaciones de ejemplo
5.5 | Static Content Hosting
This example shows how to reference static content from a public...
Patrones para el diseño de
aplicaciones para la Nube
Jim Saenz | Especialista Microsoft SharePoint
@JimSaenzDedios
Upcoming SlideShare
Loading in …5
×

Patrones para el diseño de aplicaciones en la Nube

840 views

Published on

Patrones para el diseño de aplicaciones en la Nube, permite identificar que patrones de diseño se debe estudiar o revisar para atender un determinado problema.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
840
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Patrones para el diseño de aplicaciones en la Nube

  1. 1. Patrones para el diseño de aplicaciones para la Nube Jim Saenz | Especialista Microsoft SharePoint @JimSaenzDedios
  2. 2. AGENDA 01 | Categoría de problemas Comunes 02 | Patterns for Resiliency & Availability 03 | Patterns for Scalability 04 | Área de desarrollo 05 | Aplicaciones de ejemplo
  3. 3. 01 | Categoría de problemas Comunes 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
  4. 4. 01 | Categoría de problemas Comunes 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.
  5. 5. 01 | Categoría de problemas Comunes 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.
  6. 6. 01 | Categoría de problemas Comunes 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.
  7. 7. 02 | Patterns for Resiliency & Availability 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
  8. 8. 02 | Patterns for Resiliency & Availability 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.
  9. 9. 02 | Patterns for Resiliency & Availability 2.6 | Health Endpoint Monitoring 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.
  10. 10. 02 | Patterns for Resiliency & Availability 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.
  11. 11. 03 | Patterns for Scalability 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
  12. 12. 03 | Patterns for Scalability 3.9 | Sharding 3.10 | Static Content Hosting 3.11 | Throttling
  13. 13. 03 | Patterns for Scalability 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.
  14. 14. 03 | Patterns for Scalability 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.
  15. 15. 03 | Patterns for Scalability 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.
  16. 16. 03 | Patterns for Scalability 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.
  17. 17. 04 | Área de desarrollo 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
  18. 18. 04 | Área de desarrollo
  19. 19. 04 | Área de desarrollo 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.
  20. 20. 04 | Área de desarrollo 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.
  21. 21. 04 | Área de desarrollo 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.
  22. 22. 04 | Área de desarrollo 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.
  23. 23. 04 | Área de desarrollo 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.
  24. 24. 04 | Área de desarrollo 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.
  25. 25. 05 | Aplicaciones de ejemplo 5.1 | Leader Election 5.2 | Health Endpoint Monitoring 5.3 | Competing Consumers 5.4 | Priority Queue 5.5 | Static Content Hosting
  26. 26. 05 | Aplicaciones de ejemplo 5.1 | Leader Election 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.
  27. 27. 05 | Aplicaciones de ejemplo 5.2 | Health Endpoint Monitoring 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.
  28. 28. 05 | Aplicaciones de ejemplo 5.3 | Competing Consumers 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.
  29. 29. 05 | Aplicaciones de ejemplo 5.4 | Priority Queue 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.
  30. 30. 05 | Aplicaciones de ejemplo 5.5 | Static Content Hosting 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.
  31. 31. Patrones para el diseño de aplicaciones para la Nube Jim Saenz | Especialista Microsoft SharePoint @JimSaenzDedios

×