考試重點回到 Developer，考試範圍除了 Solution Architect (ASA) / SysOps Administrator (ASOA) 都已經很熟悉的 VPC / EC2 / IAM / S3 … 等，另外的重點都在 DynamoDB / 3S (SQS, SES, SNS) / SWF / AWS API。

準備

同樣是以 BluePrint 為主。

BluePrint

BluePrint 提到四點：

• 1.0 AWS Fundamentals 10%
  • AWS Services: EC2, RDS, S3, SWF, SQS
  • DynamoDB, Beanstalk, CloudFormation
  • tradeoff between RDS and installing on EC2
• 2.0 Designing and Developing 40%
  • Config an AMI
  • AWS API
• 3.0 Deployment and Security 30%
  • Cloud deployment and maintenance
  • Cloud Security Best Practices
• 4.0 Debugging 20%
  • General troubleshooting
  • Best Practices in debugging

我個人歸納重點大概如下：

• 基本的 EC2 / 網路 troubleshooting
• Beanstalk 的生命週期、使用場景
• DynamoDB 的概念 (重點)
• 3S: SQS / SES / SNS 的基本概念、生命週期，API
• S3 的基本概念與權限管理
• CloudFormation 的基本概念，主要有哪一些 Elements、Functions

最好跑過上述的 Sample Code，以 Java 來說，用 AWS Toolkit for Eclipse 就會有相關的 Sample Code，降低設定的複雜度。

必讀 – DynamoDB

這張考試內容 DynamoDB 佔很重的比例，特別是這幾個重要概念：

• Read Consistency: Eventually Consistent, Strongly Consistent
• Primary Key: Partition Key, Partition key and sort key
• Secondary Indexes: Local Secondary Indexes (LSI), Global Secondary Indexes (GSI)
• Provisioned Throughput: 怎麼計算 Read / Write Capacity Unit (RCU, WCU)
• Query and Scan

建議閱讀 – DynamoDB

DynamoDB 設計理論源自於 Amazon 的論文： Dynamo: Amazon’s Highly Available Key-value Store，以下幾篇推薦深讀 (由淺至深)：

• DynamoDB 概述
• Amazon DynamoDB 筆記
• DynamoDB 深度體驗 (InfoQ 簡中)
• 解读 NoSQL 技术代表之作 Dynamo
• Deep Dive on Amazon DynamoDB (Youtube, AWS Summit)
• Dynamo: Amazon’s Highly Available Key-value Store: DynamoDB 設計理論基礎，作者包含了現任 AWS CTO Werner Vogels
• Eventually Consistent – Revisited by Werner Vogels, 中文翻譯
• Amazon DynamoDB – a Fast and Scalable NoSQL Database Service Designed for Internet Scale Applications, by Werner Vogels

其他有關的概念，包含在分散式系統著名的理論：Brewer’s CAP Theorem, 1999 by Eric Brewer

學習資源

AWS Documentation 官方文件不管是實務上，還是考試，都是要翻過的。除了這個之外，另外還有幾個很不錯的地方，特別是有問題不了解的時候：

• AWS Support FAQs: 不管是不是準備考試，都很有參考價值，特別是第一次使用 AWS
• AWS Discussion Forums: AWS 官方的 StackOverflow，會有 AWS Support 上去回答問題。
• AWS Knowledge Center: AWS 蒐集客戶的問題，整理出來的

上一張有提到 A Cloud Guru 是不錯的學習參考，但是題目以及內容都偏簡單。一定要去用相關的服務，然後試著找問題、解決他。這點在 AWS 的考試應該都是必要的學習方法。因為考試題目通常都是給個案例，然後從案例中找問題、找最佳解決方法。

AWS SDK / CLI

從上一張開始，我就很常逛這些地方：

• AWS CLI Reference
• AWS SDK for Python (boto3)
• AWS SDK for Javascript
• AWS SDK for Java

如 ASOA 所述，我目前是一個 SysOps / Admin 的角色，但是我還是喜歡用 Code 來做 Operation 相關的事情，所以善用 CLI / SDK 就變成必要的。

整天用 AWS Console 做事情，其實沒啥效率，所以儘可能的 auto it 就是現在的基本的精神，最終變成 Ops as Code。以下是我已經或者正在進行中的：

• awsops-ec2: EC2 AMI, Snapshot 自動備份 / 刪除, Billing 統計
• awsops-iam: 管理 IAM policies, groups, roles, users，讓權限管理也可以到版本控管。
• awsops-sec: 管理 Security Groups, Network ACLs，同樣也是可以版本管理。

這兩個小工具可以讓 operator 透過 config file (yaml, json) 方式管理這些東西，而不是在 AWS Console 上。有幾個重要的原因：

• 這些異動通常要有原因，隨便異動會是爭議的來源，特別是資安事件發生的時候
• SG / NACL 的紀錄內容 (IP) 需要有對應的說明，注意使用單位、需求名稱、聯絡人。

但目前上述 流程、制度面的事情，無法在 AWS Console 上做，而且 AWS Console 在組織裡不是每個人都可以進去，資訊不透明。

小小的心得：不要用 node.js / js 來做維運管理任務，因為維運任務通常是程序性的，而 non-blocking 會把你的扣弄的跟大便一樣髒。同時通常維運人員都不是真的 coder 出身，會寫扣得不懂系統維運是啥，他會無止境的發散維運的邏輯。 js 那種 functional 的寫法，讓你死得很慘。所以最後我都改用 Python，它是比較適合做維運自動化的工作。

Serverless

現在很夯的 Serverless 相關的課題，未來考試內容可能會有這塊？不知道。

不過也是趕流行，以下是一些不錯的參考點 / 書：

• cloudonaut: AMAZON WEB SERVICES IN ACTION 這本書的作者。除了 Serverless 相關，也有很多關於 CloudFormation 的介紹，github 上有很多相關資料。
• AWS Hall of Fame: AWS 非官方的 certification 統計。整個網站都是用 API Gateway + Lambda + DynamoDB 做的。
• A Cloud Guru: Serverless: ACG Serverless 專區，同時 ACG 整個網站也都是 serverless 架構
• Serverless Architectures on AWS With examples using AWS Lambda: 寫這篇心得的同時，正在出版中。作者 Sam Kroonenburg 是 A Cloud Guru 的 Co-Founder、Peter Sbarski 則是 VP Engineering。
• Serverless Single Page Apps: 作者 Ben Rady
• AWS Serverless Multi-Tier Architectures (pdf)

考試心得

開發者跟 AWS 的關係？

考這張的過程當中，我一直在思考：開發者 (Developer) 需要了解 AWS 多少？了解多深？多廣？

大部份的 Developer 通常會深陷滿足商業需求的泥淖中，如果加上公司本身不重視方法、流程，通常沒時間想太多。AWS 這麼強大、好用且完整的服務，往往只會變成另一種比較方便的虛擬機罷了。

不過這幾年因為社群活躍，不管是有企業介入的，還是民間自己的組織，都有相當程度的資訊流通，很多概念以往不被重視的 (薪水也不會太高)，像是：

• 測試:
  • 這幾年的 Unit Test 都已經開始被重視
  • 各式各樣的驅動模型與方法論：BDD, TDD
  • 測試工作寫 code 是基本的
• 部署 / 維運:
  • Deployment and Provisioning
  • CI / CD / Infra as Code:
  • 一直到這幾年潮到出水的 DevOps
  • 上述東西以前我統稱: Releng: Release Engineering
  • 上述跟傳統 IT / MIS 有一些技能是重疊，但是本質上是完全不一樣的角色。
• UI / UX: 很多人分不出來這兩個差異，現在這都已經是必要的常識。
• 資安: 資安事件每天都有，所以開發者的資安知識是必要的。
• Data：也是因為 Big Data 而潮翻天。

這些東西漸漸的被看到，這些角色以往在企業裡是被忽略或者不被看重的，現在都變成了顯學。

特別是 DevOps Engineer 這個角色，很多人對這角色定義都很亂，像是 SE (System Engineer)、又像是 Release Engineer、System Operator、IT、MIS、Automation Engineer、QE (Quality Engineer) …. 。 一堆 Conference 一堆人都在討論這個不管是角色、文化、技術、流程的 名稱，我自己定義如下：

能夠針對產品特定版本，快速完成部署整套產品的角色

精神只有這句話。部署不只是針對現場產品，而是包含能給各種目的，像是正式環境、測試、開發、壓測、給客戶的 Sandbox、給業務 Demo 的 … 包含基礎架構 (Infra)、部署、版本管理、跨地區部署、還原等。如果說了一堆文化、技術、流程，然後無法快速完成這個任務，對我來講，都只是在呼口號。特別是特定 版本，很多公司的部署都是單向的，也就是部下去之後 就回不去了，或者無法任意部署特定的版本。

而這些東西，在 AWS 大部份都已經涵蓋相對應的概念，同時也包成服務、甚至是內建的，像是資安、維運、效能、CI、CD、Infra as Code。

然後使用 AWS 通常會跟錢有關係，開發者可以學習成本管理，以下是幾個不錯的例子 (Serveless)：

• Two university students take just 54 hours to build a Census website that WORKS – for $10 MILLION less than the ABS’ disastrous site: 兩個澳洲昆士蘭的大一學生花了 54 小時用 Serverless 做出類似人口普查的網站服務，花了 $500, 而政府做出來的網站則花了 $10m。
• 30K Page Views for $0.21: A Serverless Story

所以如果開發者可以善用 AWS，了解他背後設計的本質，將會如虎添翼。所以 AWS 跟 Developer 的關係，我用吉他手跟設備的關係來說明：

• 用百萬的設備 (AWS)，加上爛爛的演奏技巧 (Developer) = 彈出 30 塊的聲音
• 用一百塊的設備 (PC)，加上超強的演奏技巧 (Developer) = 彈出不錯的聲音
• 用百萬的設備 (AWS)，加上超強的演奏技巧 (Developer) = 彈出超屌的聲音

所以東西好不好用，人才是關鍵，但是工欲善其事，還是要有利器。

Associate Level 助理級？

三張 (ASA / ASOA / ADEV) Associate Level 都考過了，心得是：就是助理級。單純考試範圍的深度、廣度、複雜度來說：

• Solutions Architect – Associate: 廣、深、小複雜
• SysOps Administrator – Associate: 廣、不深、很雜
• Developer – Associate: 不廣、稍微深、不複雜

感覺上跟另外兩張 Pro 還差滿多的，所以我覺得這三張的內容算 AWS 入門而已，對於定義的三種角色是具備完整的 Overview，要在 AWS 上做事是沒問題的，但能不能解決問題，就要看個人的功力了。

但不代表沒什麼鑑別度，因為三種角色都有各自的 Domain 以及 Know How，同時範圍都很廣，入門不難，但要花一點時間，肯讀應該都考得過。

Computer Science 的基本功：資料結構、演算法、計算機組織、計算機結構、作業系統、計算機網路、離散數學、統計學

技能、經歷、專業，資深、開發、研究

技能像是會一些東西，像是：

• PHP, Java, Python, Node.js, C#
• Linux, Nginx, MySQL
• AWS: VPC, S3, EC2, ELB ….
• ooxx framework
• …

經歷通常在履歷上呈現的或是這樣：

• OOXX Developer (5y)
• OOXX QA (5y)
• OOXX Manager (3y)
• IoT (3y), EC (2y)
• Project Management (5y) …

面試的經驗告訴我，通常經歷不一定會等於專業。履歷上很漂亮的經歷，結果一問三不知的很多。十年的經歷，大部份只是用同一個方式，重複了十年。技術還是停留在十年前，更別提專業部分。

專業，就要說成：

• 導入 XXOO，為公司帶來 5000w 的收益
• 提出 XXOO 架構，解決搶票瞬間巨量，同時滿足瞬間 xxxx request
• 因為要分析使用者行為，提出 big data 解決方案，使用 A,B,C,D 方法
• 利用 xxxooo 方法，讓 SLA 達到 99.99999

 

有解決問題的專業能力，但是如果這樣的專業沒有辦法回歸到純粹的技術，那可能只是曇花一現而已，這個循環的接點叫做 研究，探索事物的本質。

很多公司都有 RD 部門，其實是很大的錯誤。在國外是沒人在這樣講的，人家講的是 R&D，這是兩個角色、兩個單位：Development and Research。大部份台灣做的都只有 Development，Research 通常只有在一定規模的公司才會有，通常會請一堆 PhD ，然後以學術方法做研究。微軟、IBM 都有 研究員 的角色，真的就是做研究。

前面提到的 DynamoDB 設計的依據是 AWS CTO 的論文，可以看成是解決問題之後，透過研究，轉化回到技術，然後 再創造，或者叫 再發明 (reinvent)。

一家能夠長久經營的企業，必須要有這樣的能力，也要做這樣的投資。

AWS 的年度大會 re:Invent 的命名，有其意涵所在。

所以回到 音樂 的說明，必須再補上一點：

• 創造：重新發明新方法，然後創造新的音樂。像是:
  • Jimi Hendrix 重新定義電吉他這個樂器、Van Halen 發明了點弦這個演奏技巧、SRV 開創新的德州藍調曲風、Eric Clapton 開啟白人的藍調、伍佰定義了台灣的藍調搖滾 ….
  • 巴哈證明了十二平均率在音樂轉調的可行性

 

職涯經歷 Software Developer (IBM, Middleware) -> Software QA Manager (IoT) -> System Operation Manager (EC)，剛好是 DevOps 三個圈圈 三種角色的歷練，我想要透過學習 AWS 技能的過程中，重新定義自己的職涯。而 Software Architect 才是我想要的目標，知道自己缺什麼，所以要繼續努力。然後很重要的是，達到這些之後我很清楚自己下一步要做什麼。

以前在教吉他的時候，有時候會很感慨，因為通常老師都比學生還努力認真。我花在準備教學的時間，不管是找資料、寫譜、讀文章、練琴，會比學生練琴的時間還多很多。

我一直很喜歡日劇『王牌大律師 2 EP7』裡的一段對白，那是一個漫畫家老師傅和徒弟在法庭上的對話：

老師傅：「才能這種東西，本來就是該靠自己挖掘創造的！我也不是什麼天才，我只是比任何人都拼命工作，一步一腳印走過來了。等我回頭一看，背後沒有 一個身影，那幫懶惰的人在山腳念叨著『誰叫那傢伙是天才』，開什麼玩笑，我最討厭悠哉悠哉地長大的慢性子！比我有時間、有精力、情感豐富的人，為什麼比我 懶惰？那就給我啊，要把這些東西都浪費掉的話，就通通都給我，我還有很多很多想創造的東西，給我啊！但是，穗積」導演語調一轉，說：「你要是那麼想讓我道 歉，我就道歉，想要錢，我就給你錢。」

這段對白，讓我更深刻地感覺到：『大部分人努力程度之低，根本輪不到拼天賦』這篇文章所描述的。有時候覺得自己很努力了，但看到一些同事、看到這些文章，似乎又覺得根本不值一提。

步入職場多年之後，其實一直很想回去唸書，同時也發現，讀書考試跟工作比較起來是最單純的事情。面對忙碌、茫然、沒有方向範圍的工作，單純考試 (有方向、清楚的範圍) 反而是單純的。

Anyway，繼續往下一個方向努力。

參考資料

• 大部分人努力程度之低，根本輪不到拼天賦
• STARTUP 2.0工程師創業手冊