Study Notes - Architecting for the cloud (AWS Best Practices, Feb 2016)

1. 2018/01/12
Architecting for the Cloud
AWS Best Practices
1

2. Versions
2
● Architecting for the Cloud: AWS Best Practices - (Feb 2016)
○ 比較官腔的寫法
● Architecting for the Cloud: AWS Best Practices - (Jan 2011)
○ 比較有人性的寫法

3. Cloud Computing Difference
3

4. Cloud Computing Difference
4
● IT Assets Become Programmable Resources
● Global, Available, and Unlimited Capacity
● Higher Level Managed Services
● Security Built In

5. 5

6. Design Principles
6

7. ● Scalability
● Disposable Resources Instead of Fixed Servers
● Automation
● Loose Coupling
● Services, Not Servers
● Databases
● Removing Single Points of Failure
● Optimize for Cost
● Caching
● Security
Design Principles
7

8. ● Scaling Vertically
○ Scale-up, scale-down
○ c4.large → c4.xlarge → c4.2xlarge
○ CPU, Memory, IO
● Scaling Horizontally → Scale-out, Scale-in
○ Stateless Applications
○ Stateless Components
○ Stateful Components
○ Distributed Processing
● Elasticity is one of the fundamental properties of the cloud.
○ EC2, ELB, ECS, EBS, EIP, ENI,
Scalability
8

9. ● Push mode: distribute a workload is through the use of a load balancing solution
○ ELB routes incoming application request across multiple EC2 instances
● Pull mode: async event-driven workloads do not require a load balancing solution.
○ tasks that need to be performed or data that need to be processed could be stored as
messages in a queue using Amazon Simple Queue Service (Amazon SQS) or as a streaming
data solution like Amazon Kinesis.
Stateless Applications
9

10. 10Architecting for the Cloud: AWS Best Practices - (Jan 2011)

11. 11

12. ● Instantiating Compute Resources
○ Bootstrapping → EC2 Userdata
○ Golden Images or Containerize
○ Hybrid
● Infrastructure as Code
Disposable Resources Instead of Fixed Servers
12
06. Resource Provisioning and DevOps

13. Hardware (c4.xlarge)
Operating System
Language
Integreter
Application
Server
Tools Code
Build an Environment
Amazon Machine Image
(AMI)
instances
create-image
run-instances
13

14. *.lab1.abc.com
*.lab2.abc.com
*.lab3.abc.com
Infra as Code: CloudFormation / Terraform
Route 53
Workers / API / Batch
ELB: BBB-lab-abc-com
DNS: BBB.labN.abc.com
db.lab.abc.com
(RDS)
14
ELB: AAA-lab-abc-com
DNS: AAA.labN.abc.com
ELB: BBB-lab-abc-com
DNS: BBB.labN.abc.com
AutoScalingGroup
CloudFormation - Infra
CloudFormation - Cloud Services
awsops
gfs.lab.abc.com
(GlusterFS)

15. 15

16. ● Elastic Beanstalk: PaaS
● EC2 Auto recovery
● Auto Scaling
● CloudWatch Alarms
● CloudWatch Events
● OpsWorks Lifecycle events
● Lambda Scheduled events
Automation
16

17. Auto Scaling
● 前提：Resource Provisioning - 環境建置自動化
● 白話文：
機器 (零件) 隨時能被置換
能砍掉重練
17

18. ● Well-Defined Interfaces
● Service Discovery
● Asynchronous Integration
○ decouple your components
● Graceful Failure, design for failure and nothing will fail
○ Route53 policy
Loose Coupling (鬆耦合)
18

19. Well-defined Interfaces
● 清楚 Input / Output
○ 資料結構
○ 資料型態
○ 清楚的錯誤定義
19

20. Decouple Your Components
20Architecting for the Cloud: AWS Best Practices - (Jan 2011)

21. Design for failure
21
SRE: Site Reliability Engineering
CH13 Emergency Response
Things break; that’s life.

22. ● Managed Services
○ SQS, CloudWatch, ELB, S3, EBS RDS, SES ...
● Serverless Architectures
○ Lambda, API Gateway
○ Whitepaper: Serverless Architectures with AWS Lambda (November 2017)
Services, Not Servers
22

23. 以下摘錄自『可口可樂的 Serverless 之旅』
● IT 人員花太多時間在解決網路問題、找尋故障排除方法等吃力不討好，又無法彰顯 IT價值的事務。
● IT 團隊將一半以上的時間浪費在對企業毫無價 值的問題。不僅企業質疑IT團隊的貢獻度，就連 IT人自
身的生活品質也大受影響 ，而這幾乎是每個企業都面臨的現象。
● 系統維運還包含更新修補檔、監控系統等工作。例如一早上班發現一臺機器必須更新 18個套件的安全
更新檔，對開發者來 說可是沈重的負擔。
● DevOps要能成功，關鍵在於 IT架構的可程式化與自動化，也就是 Infrastructure as Code。即使企業
已經採用雲端虛擬機器服務，但系統管理若仍透過網頁介面手動設定與調整，這樣的管理方法勢必無
法擴張，發揮不了DevOps的效果。
Serverless
Source: https://www.ithome.com.tw/news/112431
23

24. Servers AAHHHHHH!!!
Ref: Getting Started with Serverless Architectures

25. OS Patch
Instance Size
Service Capacity
Cost and Budget
OS Version
User Permission
OS Utilization
Performance OS Optimize
Package for Services
Config Management
Hardware Failuare
25
Operation Tasks for Servers

26. 26

27. ● Relational Databases
● NoSQL Databases
● Data Warehouse (Big Data)
● Search
Design Principles - Database
27
● Scalability
● High Availability
● Anti-Patterns

28. ● Introducing Redundancy
○ standby or active mode
○ when a resource fails, functionality is recovered on a 2nd resource using a process call
failover
● Detect Failure
○ Route53 Health Check
○ EC2 auto recovery
○ Auto Scaling
Removing Single Points of Failure (SPOF)
28

29. Removing Single Points of Failure (SPOF)
29
● Durable Data Storage
○ Maintain a variety of data
○ ync replication -> RAID1, RAID5, GFS (GlusterFS)
○ Durability: No replacement for backups
○ DR: RPO, RTO
● Automated Multi-Data Center Resilience
○ MultiAZ, VPC AZs
○ ELB AZ, DynamoDB, RDS
○ Region Levels
● Fault Isolation and Traditional Horizontal Scaling
○ Shuffle Sharding

30. Reference
1. Site Reliability Engineering
a. Chapter 22 - Addressing Cascading Failures
b. Chapter 23 - Managing Critical State: Distributed Consensus for Reliability
2. 高品質微服務
a. 第五章 容錯與災難預防
3. AWS Whitepapers
a. AWS Well-Architected Framework - Reliability Pillar (December 2017)
b. Building Fault-Tolerant Applications on AWS (October 2011)
30

31. 31

32. ● Right Sizing
● Elasticity
● Take Advantage of the Variety of Purchasing Options
○ Reserved Capacity
○ Spot Instances
Optimize for Cost
32

33. 33Architecting for the Cloud: AWS Best Practices - (Jan 2011)

34. ● Utilize AWS Features for Defense in Depth
● Offload Security Responsibility to AWS
● Reduce Privileged Access
● Security as Code
● Real-Time Auditing
Security
34

35. 35

36. 36
What is Architecture?

37. 37
What is Software Architecture?

38. Cloud Native
38
https://pivotal.io/cloud-native
https://www.cncf.io/

39. 39

40. 40
Reference
● Architecting for the Cloud (Feb, 2016) (PDF)
● Architecting on The Cloud (slideshare)
● Building Microservices
● Clean Architecture
● Site Reliability Engineering

41. 41

42. 42

43. 43
End