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 EngineerSystem OperatorITMISAutomation EngineerQE (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

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲