Azure Application Architecture Guide

Azure Application Architecture Guide Overview

1. A3G Overview Masashi Narumoto Principal lead PM AzureCAT patterns & practices Azure Application A rchitecture Guide

2. 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) Big bang release Frequent small update Manual management Automated self-management

3. Process of Software development Business alignment Technology alignment

4. Process of Software development Architecture style guide Design principles Compute selection guide Storage selection guide Best practices Design patterns Design review checklist Business capability Domain driven Data driven End to end traceability

5. Process of Software development

6. Analyzing business domain Functional – Domain driven or data centric Ubiquitous language to model business domains Bounded context shows service boundary Context map visualizes to service dependency Aggregate, Domain service/event lead to microservices and inter service comm Non-functional - RTO/RPO/MTO, SLO/SLA, Security, Operation 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 and topology Security leads to authN / authZ , encryption (transit, at rest) Operation leads to automated monitoring, management solutions

7. What if we don’t model around business? Spending too much time on the features nobody’s going to use Wrong assumptions are baked into data and service model Change in technology directly affects service model System is not scalable nor secure SLA target is not met System health is not visible to operators

8. What if we don’t model around business?

9. Example – Drone delivery service

10. Accounts Drone management 3 rd party transportation Call center Video surveillance Drone sharing Drone management Drone sharing 3 rd party transportation Shipping (Core) Call center Shipping Context map – Drone delivery service Surveyllance Accounts

11. Drone management Accounts Drone sharing 3 rd party transportation Shipping (Core) Call center Context map – Problem and Solution space Surveyllance Accounts Drone management 3 rd party transportation Call center Video surveillance Drone sharing Shipping

12. Accounts Drone management 3 rd party transportation Call center Video surveillance Drone sharing Drone management Drone sharing 3 rd party transportation Shipping (Core) Call center Shipping Context map – Drone delivery service Surveyllance Shipping Accounts

13. A ggregates and services in shipping domain Shipping Drone Package Delivery DeliveryScheduler DeliverySupervisor Account 3 rd party transportation Authentication Aggregate Domain service

14. Non-functional requirements – Shipping 10K to 100K rps to delivery scheduler 1M write/sec to geospatial index (geo-data / 4 sec / drone) Latency in 99 percentile has to be within 1 sec 99.99% uptime for delivery scheduler Daily update for ETA/Drone optimization algorithm CI/CD to support daily deployment Recovery time objective (RTO) should be 10 mins Recovery point objective should be an hour Drones and PII need to be protected from malicious attack Monitor the system for RCA and system health

15. Process of Software development

16. Choosing architecture style Domain Model Monolith? Microservices? CQRS? Web-queue-worker?

17. What if we don’t c hoose right architecture?

18. Architecture imposes constraints f or desirable outcome

19. Constraints in microservices - A service represents a single responsibility - Services don’t share its data Service calls only via API Every service has to be independently deployable R elease pipeline has to be de-centralized

20. Applying architecture style Business Domain Data access Business logic API

21. Choosing architecture style Business domain (Functional, Non-functional) Type/Complexity of domain Prerequisites Skillset, Team, Culture Benefits vs. Challenges Does benefits justify taking challenges? Degree of conformity Purist vs. Pragmatist

22. When to choose Microservices? Benefits Independent deployment Fault isolation Diverse technology Small focused team Separate scalability Challenges Complexity Network congestion Data integrity/consistency Testing Reliability Business domain Complex domain Deployment at high velocity Many independent teams Prerequisites Skill set for distributed system Domain knowledge DevOps culture M onitoring capability

23. Degree of distribution Monolith (Big ball of mud) microservices Corse grained Somewhat decomposed

24. Choosing architecture styles Dependency management Domain type/complexity N-Tier+ Horizontal layers (open/close) Traditional business domain Frequency of update is low Web-Queue-Worker Front/Backend jobs Decoupled by async messaging Relatively simple domain with some resource intensive tasks Microservices Vertical (functional) decoupling Service calls via API Complicated domain Frequent update is required CQRS R/W segregation Schema/Scale are optimized separately Collaborative domain where lots of users access the same data EDA Data ingested into streaming Independent view per sub-system Internet of things Big data Divide huge dataset into small chunks Parallel processing on local dataset Batch and real-time data analysis Predictive analysis using ML Big compute Data allocation to thousands of cores Embarrassingly parallel processing Compute intensive domain such as simulation, number crunching

25. User Business logic Polyglot Storage Device Gateway Streaming & analytics Device control Device State & Mgmt Business System Hot & Cold Storage Serving & BI Device API Gateway Web/Mobile application IIoT Data analysis Batch Analysis Near Real-time Analysis Notification Remote Service Cloud application architecture User management

26. User Business logic Polyglot Storage Device Gateway Streaming & analytics Device control Device State & Mgmt Business System Hot & Cold Storage Serving & BI Device API Gateway Web/Mobile application IIoT Data analysis Batch Analysis Near Real-time Analysis Notification Remote Service User management Microservices Cloud application architecture SPA Event Driven Big data N-Tier Web-Queue-Worker CQRS Big compute Lift & Shift

27. User Business logic Polyglot Storage Device Gateway Streaming & analytics Device control Device State & Mgmt Business System Hot & Cold Storage Serving & BI Device API Gateway Web/Mobile application IIoT Data analysis Batch Analysis Near Real-time Analysis Notification Remote Service Cloud application architecture User management

28. N-Tier+ architecture

29. N−Tier+ architecture Web tier Database Storage Remote service NVA Middle tier 2 Messaging Cache Middle tier 1 Jump Box User Admin

30. Best practices for N−Tier+ architecture Web tier Database Storage Remote service NVA Middle tier 2 Messaging Cache Middle tier 1 Jump Box User Admin Place multiple NVA for HA Use messaging to decouple tiers Cache semi-static data Protect internet access by NVA Restrict access to data tier Admin tasks via jump box Use separate subnet/availability set per tier with multi VMs Configure redundancy such as SQL AlwaysOn AG

31. N-Tier+ When to use : Migration scenario with m inimum refactoring from existing app Simple web applications(e.g. admin web site) You need unified development/management across on-premises and cloud Benefits : High portability Less learning curve Natural evolution from traditional model Open to heterogeneous environment (Windows/Linux) Challenges : Monolith prevents independent deployment Manageability is not optimal Versioning of each service running on VMs Configuring network security is not trivial Conforming to industry regulations (e.g. PCI, SOX, HIPPA)

32. Web-Queue-Worker architecture

33. Web-Queue-Worker architecture SPA & Mobile Web frontend services SQL NoSQL CDN Remote service Cache Worker s Messaging IdP

34. Best practices for Web-Queue-Worker SPA & Mobile Web frontend services SQL NoSQL CDN Remote service Cache Workers Messaging IdP Partition data Use polyglot storage Auto-scale instances Decouple resource intensive jobs Host static content Expose consumer friendly API Retry transient faults Cache semi-static data

35. SPA & Mobile Web frontend services SQL NoSQL CDN Remote service Cache Workers Blob Messaging IdP Design patterns for Web-Queue-Worker Throttling Circuit breaker Cache aside Federated authentication Index table Sharding Static content hosting Competing consumers Load leveling Valet key

36. SPA & Mobile Web frontend services SQL NoSQL CDN Remote service Cache Workers Messaging IdP Anti-patterns in Web-Queue-Worker Busy frontend No Cache Synchronous IO Improper instantiation Busy database Monolithic persistence Serial message processing Chatty IO Extraneous fetching

37. Web-Queue-Worker When to use Web applications with straightforward business logic You want to take advantage of managed services Benefits : Very first Azure architecture  Relatively simple architecture that is easy to understand Easy to deploy and manage Clear separation of concerns The front end is decoupled from the worker using asynchronous messaging Challenges Without careful design, the web front end and the worker can become large, monolithic components that are difficult to maintain and update. There may be hidden dependencies, if the front end and worker share data schemas or code modules.

38. Microservices architecture

39. Microservices SPA & Mobile Microservices SQL NoSQL API Gateway CDN Remote Service Blob IdP

40. Microservices – Best practices SPA & Mobile Microservices SQL NoSQL API Gateway Remote Service IdP DevOps Release process Release process Each service has a single responsibility Don’t share the data directly Every request goes through GW Model service around business domain Isolate failure Decentralize all things Don’t leak implementation details Service calls via API Offload cross cutting concerns to GW Use polyglot storage

41. Microservices When to use Requires continuous innovation Requires d eployment at high velocity Deals with complex domain Benefits Independent deployment Fault isolation Diverse technology Small focused team Separate scalability Challenges Complexity Network congestion Data integrity/consistency Testing Reliability

42. CQRS architecture

43. Microservices + CQRS SPA & Mobile Microservices SQL NoSQL API Gateway CDN Remote Service Cache Read model Write model Microservices Blob Command Query Messaging IdP

44. Decoupling data by CQRS Delivery Account DeliveryID PackageID Drones 1234 0011 003154 DeliveryID PackageID Date Delivered 1234 0011 99 01/19/2017 Write model ( Event sourcing) Read model (Materialized View) Eventually consistent Account Delivery history Drone Message Broker PackageDelivered

45. SPA & Mobile Microservices SQL NoSQL API Gateway CDN Remote Service Cache Read model Write model Microservices Blob Command Query Messaging IdP Design patterns for microservices/CQRS Read model GW- aggregation Bulkhead Sidecar Backend for frontend Event sourcing Materialized view Ambassodar GW- offloading

46. CQRS When to use Collaborative domain with lots of operations to the same data R/W mismatch causes issues High scalability is required Benefits Separate scalability for R/W Decoupling Read from Write Optimal schema for read and write Challenges Data consistency issues Complex implementation

47. User Business logic Polyglot Storage Device Gateway Streaming & analytics Device control Device State & Mgmt Business System Hot & Cold Storage Serving & BI Device API Gateway Web/Mobile application IIoT Data analysis Batch Analysis Near Real-time Analysis Notification Remote Service IIoT User management

48. Event Driven Event ingestion Event producers Event consumers Event consumers Event consumers

49. Event Driven When to use Multiple subsystems process the same event Real-time processing with minimum time lag Complex event processing such as pattern matching Event processing with high ingestion rate such as IoT Benefits No point to point Integrations Immediate actions at consumer (minimum time lag) Very well decoupling producers from consumers Highly scalable and distributable Challenges Reliability, losing a single event could make system unstable (guaranteed delivery) Order of processing Exact once processing

50. EDA( IoT ) Reference Architecture Device Serving layer Application backend Cloud gateway Device gateway Provisioning API Identity and registry store Device state store Stream processors Storage Analytics & Machine learning BI Adaptor to External system

51. EDA( IoT ) Reference Architecture Device Serving layer Application backend Cloud gateway Device gateway Provisioning API Identity and registry store Device state store Stream processors Storage Analytics & Machine learning BI Adaptor to External system Car Machine e tc. IoT Hub EvenytHub IoT Hub Azure storage Custom app Azure stream analysis Storm Spark Azure storage ADLS Azure ML Spark HBase SQL DB SQL DWH Spark Cassandra Power BI Excel SSAS Tableau Qlikview Custom app Actor FW Azure Batch Custom app

52. Cloud Design Patterns ‘Cloud Design Patterns’ http://aka.ms/cloud-design-patterns

53. User Business logic Polyglot Storage Device Gateway Streaming & analytics Device control Device State & Mgmt Business System Hot & Cold Storage Serving & BI Device API Gateway Web/Mobile application IIoT Data analysis Batch Analysis Near Real-time Analysis Notification Remote Service Big Data User management

54. Big data architecture

55. Big data reference architecture Data source Batch processing Stream analysis Serving layer Data streaming Business intelligence Orchestration Data storage

56. Data ingestion pattern Data source Batch processing Stream analysis Serving layer Data streaming Business intelligence Orchestration Data storage

57. Best practices for Big data Data source Batch processing Stream analysis Serving layer Data streaming Business intelligence Orchestration Data storage Implement retention policy Upload large dataset using multiple threads in parallel Scrub sensitive data before publishing Partition the data Automate data ingestion and process by orchestration tools Provision a separate cluster for Hbase /Storm than batch processing Prevent data skew issue Use protocol conversion to speed up

58. Big data – service mapping Data source B atch processing Stream analysis Serving layer Data streaming Business intelligence Orchestration Data storage Device Weblogs Click stream OLTP Azure Data Lake Store Azure storage EventHub IoT Hub Kafka ASA Spark Storm ADLA HDInsight HBase Cassandra DocumentDB SQL DB/DWH Spark Power BI Excel SSAS Tableau Qlikview Custom app Azure Data Factory Oozie SSIS

59. Big data When to use Process TB ~ PB of data in a timely manner Pre-process raw data and pass the aggregated results to BI Real-time processing Experiment new data type quickly Predictive analysis Benefits Cost effective solution for large dataset High performance by parallel processing with data locality Challenges Data ingestion Numerous combination of technologies Too many knobs to optimize performance Security

60. Example – Drone delivery service

61. Accounts Drone management 3 rd party transportation Call center Video surveillance Drone sharing Drone management Accounts Drone sharing 3 rd party transportation Shipping (Core) Call center Shipping Context map – Drone delivery service Surveyllance

62. A ggregates and services in shipping domain Shipping Drone Package Delivery DeliveryScheduler DeliverySupervisor Account 3 rd party transportation Authentication DeliveryScheduler DeliverySupervisor Delivery Package Authentication Drone Account 3 rd party transportation Microservices Microservices In different BC

63. DeliveryScheduler Package Drone Delivery Mobile app Event sourcing Delivery Supervisor DeliveryEvents RequestEvents GW Status 3 rd party Service Account Service DroneMgmt Service Microservices in Shipping BC Account Service Auth Service 3 rd party transportation Account Account Service

64. DeliveryScheduler Package Drone Delivery Mobile app Delivery Supervisor GW Design patterns Auth Service 3 rd party transportation Account Load leveling GW- routing Throttling Scheduler-Agent-Supervisor Event sourcing Circuit breaker Competing consumers Bulkhead Sidecar Ambassador GW- offloading Federated auth Sharding Ambassador 3 rd party Service Account Service DroneMgmt Service Account Service Pub-Sub

65. User Business logic Polyglot Storage Device Gateway Streaming & analytics Device control Device State & Mgmt Business System Hot & Cold Storage Serving & BI Device API Gateway Web/Mobile application IIoT Data analysis Batch Analysis Near Real-time Analysis Notification Remote Service Drone delivery application architecture User management Drone geolocation and ETA User device geolocation Account management Drone scheduling ETA Drone placement