2022/10/15 完賽，前面有些 AWS 服務的內容沒有補完

學習多個雲，真的有需要嗎?

實際情況是，有些公司強調服務的高可用性時，不會允許某一朵雲的服務發生狀況。可能會用備用機房或是把服務導向另外一朵還存活的公有雲，避免公司的服務中斷。

每間公有雲的服務也很不一樣，像 AWS 的 S3 對應到 Azure 的 Storage 服務。而相比於 AWS 的 S3， Azure 的 Storage 就非常的多樣，也有 API 儲存 NoSQL 的資料。

過程中你也可以思考各個公有雲這樣做的架構究竟為什麼，甚至針對同樣的解決方案 (例如 IoT、智慧醫療) 都會有共同的點或是不同的思維方式。

我認為架構師的任務，就是設計能夠符合公司 有能力維護的架構 並且能夠 減少日後維護成本 。

賽後心得

坦白說 30 天內能準備的東西有限，可能我一天就會有好幾篇內容，有些地方我沒有研究的透徹只能在前面掛個 (Not Finish) 真的很抱歉，因為我不希望這個服務的精隨我沒有消化完提供給大家，反而讓各位看得霧沙沙，我自已也霧煞煞的急就章草草了事。

這 30 天我學習到的東西真的只有大概，但是我不希望自己只學習個大概。

最大的心得是自己對於架構方面有更進一步的認識，甚至知道很多名詞跟現在解決某些情境的解決方案。

而且在學習過程中，有太多服務有新功能、新設定。

學習、常常使用雲服務，永遠都有新的技術跟架構可以體驗。

這個挑戰賽讓我養成了每天去嘗試新技術，這個習慣我養成了的話，一年我就變強 37 倍了！(不過我更希望薪資可以成長 37 倍...)。

每天花兩三個小時了解技術的用途，也不一定能消化吸收並且產出，我覺得這部分我自己也需要加強！

每天能讀的量不一樣，就跟重訓一樣，我認為重點在於每天的累積，養成習慣比較重要。

大話 AWS 雲端架構 這本書真的寫得很好，如果有心研究雲端架構，真的可以買一本來讀看看，裡面用到很多實際的案例，透過哲學的方式，用現實生活中發生的狀況來舉例。例如: 工廠下單、按摩店、Pizza 店.....等。

我建議 一定要畫架構圖 、 一定要畫流程圖 、 一定要畫流程圖

畫架構圖是加速你對架構了解最快的捷徑，釐清資料流程與 AWS 服務彼此的關係相當重要。

再來就是文章品質、寫作格式與內容描述我覺得也需要更精煉，從業以來，我遇過兩個主管曾經對我說過...

專業的人不是說自己會什麼，而是能把自己會的東西用對方能理解的方式說出來，這才是「專業」

挑戰回顧

我列出這三十天的實際執行後，我認為有些成功的部份，下次可以繼續保持！

跟有些我覺得沒那麼好、失敗可以改善的部分來分析自己的弱點。

成功的部份

• 保持每天輸出的習慣

  • 已經持續 30 天了，已經度過困難的維持期了！繼續保持下去

• 設定好目標、內容框架

  • 這次有明確的目標設定
  • 30 天要呈現的內容框架在前面幾天就大致上訂好了

失敗，可以改善的部分

• 文章品質、寫作格式與內容描述需要更精煉

  • 文章排版，文章排版的架構什麼時候應該用斜線、粗體、粗斜線下次一定要先定義好。這部分參考一下其他人怎麼寫的，我認為好閱讀的格式。

• Hands-on

  • 某些服務的實作我沒有很熟悉，只能瞭解這個服務大致上能做什麼。

• 高估自己的資訊吸收與產出的效率

  • 每天產出的量不一樣，但是我先維持住每天至少花半個小時，每週至少 7 個小時投入技術的研究及產出
  • 這部分真的有點高估了，原本預估我每天花 1 個小時來完成這些知識並且產出，但是發現執行下來至少得花 2 個小時以上，我覺得有幾種可能: 1. 真的不熟悉這個服務 2. 沒有相關實際運用
  • 沒有相關的實際運用可能對於業界常用的架構我還不熟悉，之後可以慢慢去看其他行業的系統架構是怎麼去做，是否很穩定、可用性很高
  • 是否能更有效率地去吸收資訊並提高產出呢？ 我之前在 PPA 有買瓦基的 化輸入為輸出 一直沒有認真上課.... 讓我上完之後實際執行裡面的內容期待我下次的鐵人賽吧！