Azure Application Architecture Guide ~Design principles for Azure applications~ (Azureアプリケーション アーキテクチャ ガイド ~Azureアプリケーションの設計原則~)
•
3 likes•1,832 views
https://satonaoki.wordpress.com/2018/03/13/azure-design-principles/ https://info.microsoft.com/JA-AZUREPLAT-WBNR-FY18-03Mar-09-AzureApplicationArchitectureGuide-MCW0003602_02OnDemandRegistration-ForminBody.html https://docs.microsoft.com/azure/architecture/guide/ https://docs.microsoft.com/azure/architecture/guide/design-principles/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Azure Application Architecture Guide ~Design principles for Azure applications~ (Azureアプリケーション アーキテクチャ ガイド ~Azureアプリケーションの設計原則~)
Similar to Azure Application Architecture Guide ~Design principles for Azure applications~ (Azureアプリケーション アーキテクチャ ガイド ~Azureアプリケーションの設計原則~) (20)
More from Naoki (Neo) SATO
More from Naoki (Neo) SATO (20)
Recently uploaded
Recently uploaded (20)
Azure Application Architecture Guide ~Design principles for Azure applications~ (Azureアプリケーション アーキテクチャ ガイド ~Azureアプリケーションの設計原則~)
- 1. Azure Application Architecture Guide - Design principles for Azure applications – Azure アプリケーション アーキテクチャ ガイド - Azure アプリケーションの設計原則- SATO Naoki (Neo) Azure Technologist Microsoft
- 6. Traditional vs. Modern application Traditional on-premises Modern cloud Relational database Polyglot persistence Strong consistency Eventual consistency Design for predictable scalability Design for unbound scalability Serial and synchronized processing Parallel and asynchronous processing Monolithic, centralized Decomposed, de-centralized Snowflake servers Immutable infrastructure Integrated authentication Federated authentication Design to keep app running (MTBF) Design for failure (MTTR) Onetime big update Frequent small update Manual management Automated self-management
- 7. Functional & Non-functional requirements Choose architecture style Choose technology Apply design patterns & best practices Process of Software development Design principles
- 9. Design principles for Azure applications • Use managed services • Minimize coordination • Partition around limits • Design to scale out • Design for self-healing • Make all things redundant • Use the best data store for the job • Design for evolution • Design for operations • Build for the needs of business
- 11. Use managed services • Managed service reduces management tasks significantly • Patch, Version, Resource tuning, Cluster management • Setting up elasticsearch yourself vs. using Azure search • Managed services can be used even in IaaS workload • Cache, Messaging, Storage etc. • If version, scalability limit, cost , portability doesn’t meet your requirements, then consider pure IaaS approach
- 12. Minimize coordination - Silence is golden
- 13. Minimize coordination - Silence is golden
- 18. Design to scale out
- 19. Design to scale out • Avoid instance stickiness • Find the bottle-neck and resolve it instead of blindly scale up/out • Stateful part of the system is most likely become the bottle-neck • Use built-in auto-scaling feature • Schedule based for predictable, parameter based for un- predictable load • Design for scale-in to make sure you won’t drop balls • Consider aggressive auto-scaling for critical workload
- 22. Design for self-healing • Retry operations at transient faults • Protect failing remote services (Circuit breaker) • Compensate failed transactions • Bulkhead • Throttling • Fall back operation • Service degradation • Load leveling • Leader election • Fault injection • Chaos engineering • Check pointing long running transactions. Restart from where it failed.
- 24. Make all things redundant • Load balancing • Availability set • Paired region • Auto-Failover / Manual-failback • Synchronize front and backend • Redundant Traffic manager • Geo-replica • Partition for availability • A/A vs. A/P topology • Point in time Backup/Restore • RTO/RPO
- 25. Use best data store for the job
- 26. Use best data store for the job • Don’t use SQL for everything (monolithic persistence) • Logging, Blob, Documents • How to choose right storage • Data type, Use case, Others • Microservices architecture encourages use of polyglot storage • Each service owns its private data in best format • Shift from ACID to BASE transaction • Eventual consistency • Compensating transaction
- 28. Design for evolution • Key for continuous innovation (independent deployment) • Keep high cohesion loose coupling • Capture domain knowledge in one place • Compose tightly coupled features together • Use asynchronous messaging to avoid waiting • Avoid fat GW, it should be dumb pipe • Expose open standard interface • Design and test against service contract • Abstract infrastructure away from domain logic • Offload common tasks to a separate service
- 30. Design for operations • Make things observable • Instrument for both monitoring and root cause analysis • Use distributed tracing and correlation • Automate management tasks • Track and version configuration • (Aggregate logs and metrics) • Standardize logs and metrics • Involve operation teams in design and planning
- 31. Build for the needs of business
- 32. Build for the needs of business • Functional – DDD, DCA • Bounded context leads to service boundary • Context map leads to service dependency • Aggregate, Domain service/event lead to microservices and inter service comm • Non-functional - RTO/RPO/MTO, SLO/SLA • RTO leads to failover period • RPO leads to backup interval • SLA leads to choice of services w/ level of redundancy • Throughput/Latency leads to choice of SKU w/ partitioning
- 33. Traceability from business to software Business Domain Core domain Bounded context & context map Further breakdown per service characteristics Business modeling Group of high cohesive services talking to each other via loosely coupled API
- 34. Accounts Drone management 3rd party transportation Call center Video surveillance Drone sharing Drone management Accounts Drone sharing 3rd party transportation Shipping Call center Shipping Surveillance
- 35. Shipping domain with aggregates Shipping Dron e Package Delivery DeliveryScheduler DeliverySupervisor
- 36. DeliverySchedule r Package Drone Delivery Mobile app Event sourcing Delivery Supervisor DeliveryEvents RequestEvents GW Status 3rd party Service Account Service DroneMgmt Service Microservices in Shipping BC AAD Account Service Auth Service 3rd party transportation Account