re:Invent 2020: Werner Vogels Keynote

前言

隨著科技的發展，工廠設備需要一直更新才能追上產能需求。如今，科技的趨勢也從以往的中央運算（Central computing）方式，發展成邊緣運算（Edge computing），因此 AWS Snowcone 就是一個很好用的邊緣運算設備。

主要的特色有：

小型、輕量：Snowcone 大約長 9 英寸、寬 6 英寸、高 3 英寸，重量為 4.5 磅。具備 2 個 CPU，4GB 內存，8TB 可用容量以及支援 Wi-Fi 或有線網絡。
堅固：可承受高溫、低溫的環境，甚至受到撞擊仍可以正常使用，即使碰到水，也不會故障。
安全：支援多層次加密，可確保資料在傳輸及儲存上的安全性
支援 IoT Greengrass 及部分 EC2 Instance Type：使用者在搬遷資料的過程中，即使使用者所在位置的網路訊號不佳，還可以持續做資料處理的工作。

CloudShell

由於今年疫情關係，迫使許多企業必須做數位轉型，我們必須做出改變才能適應新的環境，像是開發工作不再限制於辦公室內，或其他特定地點。

因此像是 Cloud9 等 Web IDE 服務在今年變得非常熱門。像是哈佛都使用 Cloud 9 來上程式設計相關的課程。

既然 Web IDE 好評如潮，有著不需要安裝開發環境的良好特性，廣受開發者喜愛，AWS 現在推出 AWS CloudShell。讓大家更方便的使用 AWS 提供的 CLI 工具，且不需要收費。

現在開始，大家可以從 AWS Console 上方導覽格看到開啟 CloudShell 的 icon：

按下按鈕等待幾秒鐘時間，即可下達指令操作，它的環境是以 Amazon Linux 2 所建置，你可以在這個環境中儲存 1GB 的資料，要注意的是，僅有在 $HOME 路徑底下的資料會永久儲存，其他位置則是當 Session 關閉後，資料就不會存在。且內建 Python、Node Runtime、Bash、PowerShell、jq、git、ECS CLI、SAM CLI、npm 以及 pip 等工具，使用者還可以在裡面安裝 CDK 或是其他工具，在使用上更加方便哦！

注意：使用這項服務的話，必須要擁有 AWSCloudShellFullAccess 這項權限，倘若超過 20 分鐘以上閒置狀態時，必須要重新整理頁面。

Infrastructure 的重要性

企業在使用雲端時，主要的考量之一是雲端的高可用性，而雲端之所以有高可用性主要要歸功於他的 Infrastructure ，跟這座百年工廠一樣，從電源方面的考量開始。

為了保證服務底下的機器維持在可用的狀況，就要去思考當災難來臨時，如何設計應對災難的適宜方案，從 Infrastructure 基礎建設最底層的電源系統開始，AWS 供電的方式如下：從電力公司取得電能後，經由 UPS 再傳輸到設備。當電力公司發生問題時，AWS 會短暫的利用 UPS 供電，並透過 Switch Gear 將電源切向發電機，達到電源供應的的高可用性。

隨著時代的演進，工廠的設備會慢慢更新，往效能更好、更省錢的方向前進，因此 AWS 也鼓勵使用者慢慢將 CPU 往 ARM-based 的 Graviton2 轉換，因為 Graviton2 對於 Nodejs、Python 及 .net 都做了優化，連 ECS、EKS、CodeBuild 都可以用。

VPC Reachability Analyzer

使用 AWS 服務時，通常最複雜的事就是管理網路，在過去要追蹤測試 VPC 裡面的流量是一件費時又費工的事，需要經過慢慢的除錯才能定義出問題在哪裡，透過 VPC Reachability Analyzer 使用者可以不用發出任何流量，就可以有一個網路服務的流程圖做驗證，是個很好的 troubleshooting 工具。

假設現在要看 VPC Peering 是否互通，選擇在這兩個不同 VPC 內的 Instance 測試，除此之外也可以測試：

Transit Gateways
VPN Gateways
Elastic Network Interfaces (ENIs)
Internet Gateways
VPC Endpoint
VPC Peering Connections

創建完成後，使用者可從顯示在 Console 的分析圖，知道連線是否互通的狀態，而且也能清楚了解到在這中間經過了哪裡流程，大大幫助網路除錯的問題。

Fault Injection Simulator

在以往，要對整個系統進行故障測試時，通常需要耗費很大的成本，也很難驗證結果的正確性，使用 AWS Fault Injection Simulator（即將在 2021 年推出）可以輕鬆進行 Chaos Engineering，透過這項服務，發現系統整體的安全性問題，觀察系統的響應方式並優化、改善整個系統，避免造成嚴重後果。

Netflix 的分享介紹了混亂的工程（Chaos Engineering）技術。這是一個簡單的概念：強迫錯誤發生，所以你可以；

防止未來再次發生
了解如果發生故障該如何應對

通過這個服務使用者可以更輕鬆的實踐系統的高可用性，不用像以往等到錯誤發生、系統崩潰時才知道哪裡有問題，以利企業打造出更優良的 Application。

Amazon Prometheus & Grafana

Prometheus 是一個能夠幫助使用者輕鬆的監測大量容器化應用程式的開源專案。AWS 推出 Prometheus 的託管服務後，使用者可以不用管理太多的底層架構、調整設定，直接使用 Prometheus 查詢語言（PromQL），來管理 Amazon EKS 和 Amazon ECS 中的容器喔!

Grafana 則是一個著名的開源視覺化工具，可以按照不同需求新增各種套件，收集來自四面八方的資料（例如：來自 Google、Microsoft 雲端的運行指標），在 AWS 推出了 Grafana 託管服務（AMG）後，使用者無需管理 Grafana 的配置、版本升級、安全修補等等跟 workload 無關的瑣事，AMG 還內建了各式各樣的圖表，讓使用者輕鬆的使用 Grafana。

總結

這次 Keynote 的真正意義在於「搞清楚應用程式的趨勢」。

儘管那些新的服務多好玩、多好用，但 Keynote 還是不斷地圍繞在 高可用性 這個議題。Werner 引入並闡述了「可靠性」的概念，以及 builder 關注可靠性的重要性。真正重要的是要 building well。

Keynote 深度探討了很多維運上的細節，但整體而言是 builder 需要考慮實際情況的。

預見的（Foreseen）
可預見的（Foreseeable）
不可預見的（Unforeseeable）

這意味著團隊需要為將要發生的事情、可能發生的事情做好計劃，並準備好在一些不可預知的事情發生時做出反應。

所以在這次 Keynote 中 Werner Vogels 主要點出 4 個達到 building well 關鍵：

Everything fails, all the time

是 Werner Vogels 在過去一直強調的重要概念，無論我們努力地增強 IT 系統及基礎架構，失敗從來都不是「如果」的問題，而是「何時」的問題。有很多企業都認為在基礎設施投入大量成本，讓架構夠穩固，那麼就能一勞永逸，但誰能保證發生故障機率為零呢？

基本上，非常難達到 100% 的可靠度，因為就算在硬體上投資了鉅額的成本，但誰能保證設備永遠不斷電？即使硬體、團隊、流程處理能力再好，偶爾還是會發生錯誤的。我們並不是要傾力去預防故障發生，需要將邏輯顛倒過來！擁抱失敗，而且以「最快恢復」為目標，去處理一切。

Encrypt everything

現今有許多企業開始注重 Defence-in-Depth 概念，去保護自家系統不受任何異常影響，而最好辦法就是 — Encrypt everything，讓其他人無法輕易的擷取你的數據，AWS 幾乎所有服務都內建加密的功能，確保大家能夠對所有內容進行加密。

Operations are forever

在專案一開始選擇開發工具或平台時，要考慮的因素很多，像是要使用哪種語言？每一種語言的特性可能在開發過程中可以減少很多不必要的問題，但最需要在意的地方應該是 可靠度。因為應用程式在運行的時間一定大於開發時間，而且需要長時間維護。所以使用者在挑選解決方案時要加入 Operations are forever 的思維才行。

Monitoring ≠ Observability

當整個系統被拆成許多不同的小服務的時候，以往地端使用 DBG 的偵錯模式，就會有很好的改變。在以前開發者可以透過 DBG 去逐步調試它，並監視程式執行中變數的變化情形，但拆成很多小服務就沒辦法這樣做了。

目前大部分的團隊都著重在監視（Monitoring），但要非常了解整個系統才能達到有效的監控，因為必須知道整個系統的所有運作細節，才能在最關鍵的流程或執行狀態中收集到最有用的資料，而 Observability 是希望整個系統能夠有一些衡量指標來觀測系統整體穩定性。

坐而言，不如起而行！

Now! Go! Build!!!

Keep invent and reInvent. – Andy Jassy