+86 135 410 16684 如果你在使用中有任何aws上云服务器维护问题,可以随时联系我们!AWSOK你最好的合作伙伴!Mon. - Fri. 10:00-22:00

AWS Certified Developer – Associate 準備心得

AWS Certified Developer - Associate 準備心得

AWS Certified Developer – Associate 準備心得

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

AWS_Certified_Developer_Study

準備

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

建議閱讀 – 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 都考過了,心得是:就是助理級。單純考試範圍的深度、廣度、複雜度來說:

  • 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,繼續往下一個方向努力。

Developer-Associate

參考資料