Cloud architecture patterns and pratices
Download as PPTX, PDF3 likes330 views
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.
Cloud architecture patterns and pratices
- 5. How many do you 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 Web Jobs 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 for self 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 failed operations (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 VMs behind a load balancer • Replicate databases • Enable geo-replication • Partition for availability • Synchronize front and backend failover • Include redundancy for Traffic Manager
- 24. • Avoid instance stickiness • 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 • Circuit Breaker • Compensating Transaction • Health Endpoint Monitoring • Materialized View • Pipes and Filters • Valet Key
- 32. www.Eltavo.net
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.