技術選型: Amazon ECS Launch Types: EC2 vs. Fargate

很開心能和好朋友 HC 一起在 AWS DEV DAY TAIPEI 2020 (Dec/04, 2020) 同台分享關於「技術選型: Amazon ECS Launch Types: EC2 vs. Fargate」這個主題。本篇主要釋出今天分享的投影片，以及提供些補充資訊與大家分享、交流。

簡報下載

AWS DEV DAY TAIPEI 2020 (Dec/04, 2020)

【技術選型: Amazon ECS Launch Types: EC2 vs. Fargate】投影片：

• Speakdeck 版本：線上瀏覽
• PDF 版本：下載

前情提要

這次整理的一些素材同時關於「技術選型」與「兩種 Amazon ECS Launch Types: EC2 和 Fargate 的比較」兩個主題，所以想說也將投影片內容整理成 blog post 好讀版，方便不同閱讀習慣的朋友可以快速掃讀或是低速咀嚼（有益健康（咦!?）。

這次的分享時間約 35 分鐘，由廣至深，切成三個段落，分別為通用的「技術選型」、「初探 Amazon ECS」、最後進入正題做「Amazon ECS Launch Type 比較」。

1. Technology Selection (技術選型) –> 燒烤式選型法!
2. Overview Amazon ECS (初探)
3. Amazon ECS Launch Type Comparison (比較)

開宗明義先聊到：有些問題，不是選擇 ________ 之後，就能解決。 (page.4)

搭配古裝劇，大概通常是如此開頭的：「這位施主，關於這個問題…」（大家就自己發揮創意造句了…

技術選型

聊「技術選型」似乎在 DEV DAY 這個下午時刻，太硬不好消化，因此這次在內容準備時，想說嘗試用比較輕鬆的方式，一方面整理個方便大家聽完這場分享之後，能夠帶著走的小工具回去用看看，一方面也逐步介紹我們團隊如何應用這組「土炮工作法」來拆解與整理問題，並且交付產品。這幾年待在傳統產業一段時間，距離電子、網路產業還是有些距離與隔閡，這些分享與各位先進相比可能太過於土炮，希望有機會能彼此討論、指教。請容我冒著可能會被主辦單位趕出場的風險，讓我們來試試「燒烤式選型法」吧！

首先在開始介紹「燒烤式選型法」之前，快速介紹一下我們團隊常用的兩個基礎預備工具。

0. 基礎預備工具

第一個預備工具是，想要從溝通的語句用字用語當中，判斷對方（可能是老闆、客戶、或是同事）在討論「目的」還是「方法」。

而想要拆解出「目的」與「方法」的目的是想在花時間花資源討論「方法」細節之前，先確立有釐清該方法背後的「目的」。「目的」有可能會帶出使用情境、限制條件等資訊，可輔助或加速聚焦討論「方法」的過程。

• 通常在表達「目的」的時候，人們會使用 想要/希望/要，這幾個字詞。例如：
  • 我想要…
  • 客戶希望…
  • 老闆要…
• 通常在表達「方法」的時候，人們會使用 會不會/能不能/知不知道/可不可以，這幾個字詞。
  • 誒，請問您會不會…
  • 阿這個能不能這樣這樣、那樣那樣…
  • 請問你知不知道那個功能可不可以這樣這樣、那樣那樣…

「想要希望要」這五個字還有押韻，多唸幾次試試看，好記好上手。

第二個預備工具是，拆解並識別出「主詞」與「動詞」。

主詞通常是名詞，並且避開使用代名詞。

這個先不多作解釋，我們稍後會使用到。

接著進入第一個主題「燒烤式選型法」，我們分成五個段落來理解與實作：

1. 想像
2. 環境
3. 拆解
4. 選擇
5. 目的

1. 想像

對於雲端，我們需要一些想像，藉由想像將各種知識領域的已知知識，對應到雲的世界。而眾多知識領域當中，談到「食物」通常是個比較大眾化、好上手的題目。

說雲端太遙遠
聊美食好上手
說得一口好菜
聊了一朵好雲

在此，邀請大家在自己腦海中，想像一個情境空間，今天這個乾淨的情境空間範圍裡頭，我們訂了一個目標 (goal)：「選擇一種燒烤店類型吃牛排」。

先忽略合理、原則、順序等大家常用的判斷原則，這裡先做個簡化過後的推理起點，稍後我們再來迭代修改。（個人傾向「修改」而不使用「修正」，想要帶出「迭代」是往目的性方向走，而不一定是往正確性方向走的意思。雖然有時自己還是容易脫口說出「修正」。）

2. 環境

這樣介紹可能會被主辦單位說不行
    -- 因為可能只有標題寫到 Fargate（被打

但是可能未來會吸引燒烤店贊助商
    -- 自我揭露: ex-Sponsorship Team of COSCUP

每個系統、每個專案、每個部署都會有對應的環境描述、場景、參數、乃至於名稱，以便於檢查與修正專案前進的方向、位置與範圍。對於技術選型而言，定義一組或多組環境，也有助於稍後的迭代修改。

對於今天的燒烤式選型法，我們來設定一下第一個環境：

燒烤或燒烤店有多種類型，假設今天來到一間燒烤店，主要是多人桌，假設是四人桌好了。桌上有烤爐、烤爐上有烤盤、裡頭有燒烤加熱食材的熱源。今天選定的單一食材（今天不是單一麥芽威士忌，這個我們另外後台再聊）是兩三公分厚的牛排（部位任君挑選），享用素食的朋友們可以換成自己喜歡的食材，換成稍有挑戰性、需要稍微照顧的食材，例如烤山藥切片也不錯。今天這間四人桌的燒烤店的客人需要自己動手烤，沒有提供桌邊服務。

那我們給這第一個環境一個名稱，方便稱呼，先稱呼它「Type A」好了。簡單、粗暴。但取名字嘛，總想說有個邏輯、關聯性，團隊成員們比較好記。是不是？那來想個名字吧。

這個自己動手烤，倒也是滿彈性的，自己想要怎麼料理牛排就怎麼動手，也可以考慮將「Type A」改名為「彈性燒烤 Type」。好記。

這「彈性燒烤 Type」烤著烤著，整桌客人們聊天聊得越來越起勁，常常忘了照顧牛排而經常烤焦，得再叫一塊新的牛排再烤一次，正所謂「彈性烤了又烤 Type」、「Elastic Cow 了又 Cow Type」，要不就這樣吧，給他縮寫一下，改稱「EC2 Type」吧。（揪咪 XDD （天啊這個要怎麼翻譯成英文…

再來設定第二個環境，有多個環境設定方便下個步驟進行比較、拆解：

這天來到另一間燒烤店，這家店只有吧台，坐上吧台之後也能看到烤爐，烤爐上頭也有著烤盤，烤盤下方有熱源。一樣選定單一食材，兩三公分厚度的牛排，且都是由服務人員進行料理，服務人員們還會與客人們互動、聊天、添加飲料茶水等等。

也來給這第二個環境一個名稱，方便代稱，先稱呼它「Type B」吧。省事，但不方便記憶，那也來想個名字吧。

在這種型態的燒烤店用餐，可以很自在地與朋友聊天、專注地品嘗食材進到口中的各種風味、時不時還能假裝幫忙照顧爐火創造話題（誒不是…）（回來回來），先改稱為「自在燒烤 Type」吧。

通常這類吧台型態的店面，都是比較狹長型的，如果坐在靠近門口的位置，常常門開開關關容易被打擾到，天氣寒冷的時候也容易冷風陣陣吹來（到底是有多靠近門口…）。經過一陣校調之後，讓我們坐在離門遠一些的位置吧，「Far Gate Type」「Fargate Type」好吧，就先暫時這麼稱呼了。（這鋪陳也鋪太久… 到底有沒有要技術選型啊…

好的，回頭提醒一下，我們這次的目標 (goal) 是：「選擇一種燒烤店類型吃牛排」。然後進到下一個段落「拆解」。

3. 拆解

這個段落開始動手拆解，這跟對著兩張圖找不同點的小遊戲很像 (spot the difference)，每一個不同點 (diff) 都是由至少一個變因 (factor) 所造成。識別出這些變因，除了會影響產出結果（距離我們的目標有多接近），也可以相對識別出所在場境或問題的限制條件或邊界條件。

在動手拆解前我們已經先定義了範圍（前一段落的環境），在範圍中我們可以運用土炮工作法的「嘔吐法」，開始嘔吐出我們環境中出現的幾個主要物件背後可能的各種變因，嘔吐時先不對嘔吐產出物進行過濾與檢視，專注在盡可能將物件各種面向進行拆解。

以下，是漚吐拆解後的一個舉例（不同人不同團隊，拆解的結果往往不會相同，大家可以練習看看）：

• 烤爐
  • 品牌/尺寸/材質/大小/導熱性/通風性/熱流/氣流
• 烤盤
  • 位置/形狀/品牌/尺寸/材質/大小/高度/溫度/沾黏
• 熱源
  • 木炭/瓦斯/原子炭/龍眼木炭/荔枝木炭/炭精/被長嘆(咦)
• 食材
  • 牛排/厚度/部位/產地/儲藏/醃製/時間/熟成/處理
• 製程
  • 前製程/灑鹽/奶油/迷迭香/溫度/直火/間接火/先高後低/LowAndSlow/後製程/靜置/時間

我們帶著我們對主要物件的拆解結果，以及我們這次的目標 (goal)：「選擇一種燒烤店類型吃牛排」一起進到下一個段落「選擇」。

4. 選擇

小孩子才做選擇，大人全部都要
每個大人，心裡都住著一個孩子
				     -- do chi?

我們團隊在使用土炮工作法時，有個工具叫做「比較表」是用來做選擇之用。但今天我們先做另一種簡化的選擇，分別考量「客觀條件」與「主觀條件」，過往我們進行選擇的過程，經常考量了許多客觀條件，但卻沒有納入主觀條件來做綜合，以至於產出結果與目標有所落差。

「客觀條件」是對動詞進行拆解，「主觀條件」是對於主詞進行拆解。

「客觀條件」包含了在所定義的環境中，能對主要物件所進行的動作，例如調整參數、採購不同部位的牛排、加入不同的香料。通常「客觀條件」可以由外/而內進行掃描檢視看看是否有遺漏。這些參數包含我們在前一個段落所嘔吐拆解的練習結果，但目前我們拆解的對象只包含了「客觀條件」，接下來我們來納入「主觀條件」。

「主觀條件」包含了在所定義的環境中，出場的角色們，例如哪些人走進了燒烤店。通常「主觀條件」關連了能力/時間。

綜合「客觀條件」與「主觀條件」可以結合出「場景」（環境、情境）。

整理一下這個段落的結論：

• 場景
  • 客觀條件：技術項目/內外的 變因 展開表/比較表/…
  • 主觀條件：團隊能力/時間的 變因 展開表/比較表/…

接著我們可以嘗試為我們這次練習的環境對「主觀條件」列出一些角色，並同樣進行嘔吐拆解的動作：

• 烹飪者
  • 能力/專長/經驗/熟練度/時間/意願
• 成本
  • 度量衡/單位/換算/風險

最後的段落，我們來對應回原本的目的性。

5. 目的

簡化過的目的性是一個角色實現一個任務的方向，過程中參照主觀條件與客觀條件，基於所參照的主觀條件與客觀條件將形成多種可能可以達成目的的方法。如果同時有多個目的需要實現，則需交差參照各個目的之主觀條件與客觀條件，特別留意角色是否變異，若角色變異或多種角色，則取百分比以比例實現。角色選定後決定了主觀條件，主觀條件將限制客觀條件。

用白話文來看稍早的環境設定，如果角色（烹飪者）本人不熟悉燒烤，則會限制客觀條件

(未完待續…)

錄影影片

• AWS DEV DAY TAIPEI 2020: 技術選型: Amazon ECS Launch Types: EC2 vs. Fargate