AWS Certified Developer - Associate 準備心得

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

Updated 2018/06/05：AWS 已經發布新版的 Developer 版本，正在準備的人請注意。相關資訊也可以參考我整理的 這篇說明。

準備

同樣是以 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 佔很重的比例，特別是這幾個重要概念：

更多相關細節整理在：Study Notes - DynamoDB 學習筆記

建議閱讀 - DynamoDB

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

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

學習資源

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

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

AWS SDK / CLI

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

如 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 相關的課題，未來考試內容可能會有這塊？不知道。

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

考試心得

開發者跟 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)：

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

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

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

Associate Level 助理級？

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

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

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

深度就要看個人的努力，特別是 Computer Science 的基本功：資料結構、演算法、計算機組織、計算機結構、作業系統、計算機網路、離散數學、統計學

我以前都這樣跟學吉他的同學說：『十年才剛入門而已』，考試過了代表指入門而已。 (刮自己的鬍子 XD)

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

上一張 談到專業這個問題，這次思考這三個東西：技能、經歷、專業

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

  • 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

用我熟悉的領域 音樂 說明：

  • 技能：會按一些和弦、會掃弦、可以彈很多各式各樣的音階、知道藍調曲式、會彈很多 251 句子，大概就是 吉他基本功 提到的東西
  • 經歷：有了技能，利用這些技能去賺點錢，像是做場表演、教學、寫寫文章唬爛、接案子編曲 … 等。
  • 專業：為某電影設計配樂，像是 功夫熊貓、為某個藝人量身打造歌曲，像是 小幸運

是這樣？我覺得還少了一個：從 專業 會回到 技術，也就是達到 再創造 的循環。

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

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

我以前的老闆在米國呆很久，回來台灣看到我們的目錄叫做 RD 他還問我這是啥意思 XD

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

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

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

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

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

後記

今年到現在，我不斷的考試、學習，像是馬拉松一樣，因為很清楚進步是要靠持續才會有效果。至於，這些內容能否在工作上發揮，或者有適當的舞台，除了機會、機運，也要一點經營，但持續學習是絕對必要的。

我的工作環境常會遇到名校出來的同事，不管是台灣的台清交成/中字輩、國外留學回來的 MIT / Stanford / Purdue / UCLA … 能從這些學校畢業，聰明是一定的。但是除了這個之外，他們不管是外語能力、人際關係、視野、才華，也都有一定的高度、程度，同時大部份的原生經濟條件都不錯。但除了這些之外，他們通常還有一些特質：努力、認真、敢嘗試、樂觀。

我想到一句話：

世上最可怕就是比你聰明的人，比你還努力還認真。

所以今年為啥我要這麼拼？因為知道自己不是很聰明的人 (可能有小聰明)，先天條件遠不如人，所以努力是基本且必要的。

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

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

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

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

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

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

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

延伸閱讀 (站內)

參考資料

Comments

2016/08/20 09:53:00
Table of Content
Categories
Tags

About

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學

    • 著作

  • 個人著作：SRE實踐與開發平台指南
  • 共同著作：軟體測試實務 (2023)
  • 譯著：分散式系統設計 (2019)

    • 演講

  • 演講錄影 @ Youtube
  • 探索職涯、複利人生 - AWS Career Exploration Day 2023
  • 個人著作 SRE 書友見面會
  • 軟體測試實務 - 新書發表會
  • 探索職涯、成就未來 - AWS Career Exploration Day 2022
  • 從理想、到現實的距離，開啟品味軟體測試之路
  • 91APP 在 AWS 上的 SRE 實踐之路
  • 在矩陣型組織裡，如何有效管理 AWS 的成本結構與系統架構
  • 災難演練 @ AWS 實戰分享
  • 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
  • 聊聊軟體交付的濫觴 談產出物管理
  • 從緊急事件 談 SRE 應變能力的培養
  • 邁向 API 經濟 - API Gateway 導入之旅
  • Monitoring Tools 大亂鬥 - AWS CloudWatch
  • Ops as Code using Serverless
  • 淺談系統監控與 CloudWatch 的應用

    • Facebook

    Complete Think

    AWS Certifications

  • 全站索引
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
    • ▲ TOP ▲