Downloaded 24 times
Uploaded byGustavo Alzate Sandoval
Cloud architecture patterns and pratices
This document outlines key concepts for cloud architecture patterns including microservices, CQRS, and event-driven architectures. It discusses technology choices for compute, data storage, and design principles for quality like scalability, availability, and resiliency. Common patterns are described like retrying operations, circuit breakers, and load balancing to improve reliability.
More Related Content
Similar to Cloud architecture patterns and pratices
Cloud architecture patterns and pratices
- 2.
- 3.
- 5. How many doyou know?
- 6. • N –Tier • Web-Queue-Worker • Microservices • CQRS • Event-Driven • Auto-Scaling • Big Data • Eventual Consistency • CDN
- 19. Technology Choice Compute IaaS VM PaaS Web Apps WebJobs Mobiles Apps FaaS AZ Functions Data Store SQL Sql DB MySql Postgres IaaS No SQL Cosmos DB (documen, key-value, graph, columns family) Blobs Redis
- 20. • Data Format •Scale • Consistency Model • Schema flexibility • Performance • Replication • Management and Cost • Security
- 21. • Design forself healing • Make all things redundant • Minimize coordination • Design to scale out • Partition around limits • Design for operations • Use managed services • Use the best data store for the job • Design for evolution • Build for the needs of business
- 22. • Retry failedoperations (Transient fault handling and Retry Pattern) • Protect failing remote services (Circuit Breaker) • Isolate critical resources (Bulkhead) • Fail Over (Load balancer) • Compensate failed transactions (Compensating transactions, Idempotency)
- 23. • Place VMsbehind a load balancer • Replicate databases • Enable geo-replication • Partition for availability • Synchronize front and backend failover • Include redundancy for Traffic Manager
- 24. • Avoid instancestickiness • Identify bottlenecks • Decompose workloads by scalability requirements • Offload resource-intensive tasks • Use built-in autoscaling features
- 26. • Scalability • Availability •Resiliency • Management and DevOps • Security
- 28. • Retry • CircuitBreaker • Compensating Transaction • Health Endpoint Monitoring • Materialized View • Pipes and Filters • Valet Key
- 32.
Editor's Notes
- #5 Introduction The cloud is changing the way applications are designed. Instead of monoliths, applications are decomposed into smaller, decentralized services. These services communicate through APIs or by using asynchronous messaging or eventing. Applications scale horizontally, adding new instances as demand requires. These trends bring new challenges. Application state is distributed. Operations are done in parallel and asynchronously. The system as a whole must be resilient when failures occur. Deployments must be automated and predictable. Monitoring and telemetry are critical for gaining insight into the system. The Azure Application Architecture Guide is designed to help you navigate these changes.
- #7 Keep in mind not common ones as well. Oreally Ebook: http://shop.oreilly.com/product/0636920023777.do
- #19 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #20 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #21 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #22 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #23 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #24 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #25 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #26 Consistency: Every read receives the most recent write or an error Availability: Every request receives a (non-error) response – without guarantee that it contains the most recent write Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes In other words, the CAP theorem states that in the presence of a network partition, one has to choose between consistency and availability. Note that consistency as defined in the CAP theorem is quite different from the consistency guaranteed in ACID database transactions.
- #27 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #28 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #29 https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-comparison
- #30 Consistency: Every read receives the most recent write or an error Availability: Every request receives a (non-error) response – without guarantee that it contains the most recent write Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes In other words, the CAP theorem states that in the presence of a network partition, one has to choose between consistency and availability. Note that consistency as defined in the CAP theorem is quite different from the consistency guaranteed in ACID database transactions.
- #31 Consistency: Every read receives the most recent write or an error Availability: Every request receives a (non-error) response – without guarantee that it contains the most recent write Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes In other words, the CAP theorem states that in the presence of a network partition, one has to choose between consistency and availability. Note that consistency as defined in the CAP theorem is quite different from the consistency guaranteed in ACID database transactions.
- #32 Consistency: Every read receives the most recent write or an error Availability: Every request receives a (non-error) response – without guarantee that it contains the most recent write Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes In other words, the CAP theorem states that in the presence of a network partition, one has to choose between consistency and availability. Note that consistency as defined in the CAP theorem is quite different from the consistency guaranteed in ACID database transactions.