回想起當年怎麼都弄不懂無伺服器，乾脆把那些疑問整理出來請教博士。

伺服器消失了？魔法師的真面目

🧙‍♂️（博士）「🐣啊，今天我們要搞懂無伺服器。名字聽起來好像是“把伺服器變沒的魔法”，其實真相平實得多，卻深不可測。」

🐣（學生）「沒有伺服器？難道博士像哈利·波特那樣念“伺服器，消失！”它就真的不見了？」

🧙‍♂️（博士）「哈哈哈，這正是十個人裡九個的第一反應！其實並不是沒有伺服器。雲端深處那些機器照樣拼命工作，只是使用者不必再操心它們的存在。」

🐣（學生）「那不就是詐騙嘛。標著“無農藥蔬菜”，背地裡還狂灑農藥。」

🧙‍♂️（博士）「比喻離譜卻抓到重點。“無伺服器”的“無”是“免管理”。以前得自己養伺服器、裝系統、救火，就像在養倉鼠。無伺服器則由雲端服務商全包。」

🐣（學生）「倉鼠死了會哭，伺服器掛了客戶會罵，更慘。」

🧙‍♂️（博士）「而且伺服器不像倉鼠，只會在凌晨三點把你叫醒：“資料庫沒有回應。”」

📌 註記：無伺服器的基本概念 無伺服器（Serverless）並不是“沒有伺服器”，而是“伺服器的管理由雲端服務商代勞”的架構。

  • 傳統模式：自行採購、部署、維運伺服器
  • 無伺服器：雲端業者全權管理基礎設施，使用者專注程式碼

無伺服器的運作：只在被召喚時現身的忍者

🐣（學生）「聽起來好難用，跟普通伺服器到底有啥不同？」

🧙‍♂️（博士）「確實。無伺服器是被叫到才“砰”地蹦出來，處理完立刻消失。所以應用得設計成“短跑選手”，不適合馬拉松。」

🐣（學生）「也就是說喊“快算一下！”它就出現，完成就消失？」

🧙‍♂️（博士）「正是如此！就像忍者，呼叫才現身。平時潛伏，不用為空閒時間付房租。」

🐣（學生）「可是忍者每次都從不同地方冒出來吧。那 IP 位址怎麼辦？」

🧙‍♂️（博士）「問得好！他們沒有固定住址。每次都是新的伺服器，於是雲端的 API 閘道就像“忍者村的守門人”，把外部請求分派給合適的忍者。」

🐣（學生）「原來如此。但既然每次現身的忍者都不同，那不就沒有前一次的記憶？」

🧙‍♂️（博士）「沒錯。所以必須採用無狀態設計。不能說“接著昨天”，每次都是“初次見面”，記憶像金魚。」

🐣（學生）「那不是很不方便？登入、工作階段怎麼管？」

🧙‍♂️（博士）「得把狀態存到外部資料庫或 Redis。忍者本體不帶記憶，但會把卷軸寄放在倉庫。」

📌 註記：無狀態設計的重要性 無伺服器函式每次執行都會在新的容器啟動，本地狀態（變數、檔案、工作階段）不會保留。

  • 狀態管理：需使用外部資料庫、Redis、S3 等
  • 工作階段：使用 JWT 權杖或外部儲存
  • 檔案：除臨時處理外必須放在外部儲存

與傳統伺服器的差異：寵物 vs 忍者

🐣（學生）「具體起來是什麼樣子？」

🧙‍♂️（博士）「例如“上傳圖片就產生縮圖”。傳統模式得有一台 24 小時待命的伺服器一直等，耗電又可能故障。」

🐣（學生）「就像守門人一直站在門口“有人來嗎”。」

🧙‍♂️（博士）「沒錯，還會感冒倒下。無伺服器則是在“圖片上傳了！”這個鈴響時忍者現身，俐落地產生縮圖後消失。」

🐣（學生）「聽起來合理。但忍者出場會不會慢？」

🧙‍♂️（博士）「那就是冷啟動問題。忍者從睡夢中醒來準備要幾秒。尤其像 Java 那些重量級語言，就像迷糊的忍者先鋪瑜珈墊再吃早餐才開工。」

🐣（學生）「聽著就讓人著急。那是不是不適合即時處理？」

🧙‍♂️（博士）「有預熱機制，但整體仍擅長批次與非同步。“立刻回覆！”這種就不拿手。」

用實例理解：照片分享應用

🐣（學生）「舉個例子吧。如果要做照片分享應用呢？」

🧙‍♂️（博士）「好例子。傳統模式長這樣：」

傳統伺服器：

24 小時運作的 Web 伺服器（月費 5000 日圓）
↓
「照片已上傳」
↓
伺服器內執行縮圖產生
↓
存入資料庫

🧙‍♂️（博士）「這種方式就算沒人上傳照片也得付 5000 日圓，像“沒有客人也照樣繳房租的店面”。」

🐣（學生）「太浪費了。」

🧙‍♂️（博士）「無伺服器則是這樣：」

無伺服器版：

影像上傳到 S3
↓
S3 事件觸發 Lambda 函式
↓
Lambda 函式啟動（0.1 秒）
↓
產生縮圖並存入另一個 S3 儲存桶
↓
Lambda 函式消失
↓
計費：只按執行時間收費（每次約 0.001 日圓）

🐣（學生）「那沒人用就免費？」

🧙‍♂️（博士）「沒錯！基本上是“用多少付多少”。但一旦“突然爆紅”，帳單也會暴走。若病毒影片觸發一百萬次處理……」

🐣（學生）「就來一張 1000 日圓的帳單！」

🧙‍♂️（博士）「算得對，但實際上還得加上傳輸費、API Gateway 費、資料庫費，用不了多久就衝到數十萬。“爆紅卻破產”是現代的悲劇。」

📌 註記：按量計費的利與弊

優勢

  • 初期成本幾乎為零
  • 會隨使用量自動伸縮
  • 不必自行管理基礎設施

風險

  • 意料之外的天價帳單（尤其爆紅時）
  • 費率結構複雜
  • 多項服務疊加後成本難以看清

對策

  • 設定計費警報
  • 實作速率限制
  • 事先做壓力測試與費用試算

無伺服器的派別：忍者的專長

🐣（學生）「聽說無伺服器還分很多種類？」

🧙‍♂️（博士）「主要有三大流派：FaaS（Function as a Service）、BaaS（Backend as a Service），以及無伺服器容器。」

🐣（學生）「FaaS 是什麼？」

🧙‍♂️（博士）「就是“只託管函式”的服務。AWS Lambda、Google Cloud Functions、Azure Functions 都算。你寫好函式交給它，需要時才執行，費用照次數算，像壽司店。」

🐣（學生）「那 BaaS 呢？」

🧙‍♂️（博士）「是“資料庫、認證、推播通知全部包辦”的服務。Firebase、Supabase、AWS Amplify 等等。好比“媽媽全都幫你搞定的老家生活”。」

🐣（學生）「住在老家輕鬆，可得聽爸媽話。」

🧙‍♂️（博士）「完全正確！這就是供應商綁定的風險。回過神來就變成“沒有這個服務就活不下去的身體”。」

無伺服器擅長與不擅長的事

🐣（學生）「那努力一點自己扛不就好了？幹嘛用無伺服器？」

🧙‍♂️（博士）「因為速度。想到點子就能立刻上線，使用量少時幾乎零成本。“今晚想到的 Web 服務隔天早上就上線”完全辦得到。」

🐣（學生）「可也不是什麼都適用吧？」

🧙‍♂️（博士）「當然，擅長與不擅長的領域差異很明顯。」

擅長：

  • 影像處理（上傳→產生縮圖）
  • 資料轉換（CSV→JSON）
  • 發送通知（電子郵件、推播）
  • 定時批次處理（產生每日報告）
  • 輕量 API（使用者搜尋、資料讀取）

不擅長：

  • 即時處理（聊天、遊戲）
  • 長時間任務（影片轉碼、機器學習）
  • 需要複雜狀態管理的應用
  • 與傳統系統緊密耦合

🐣（學生）「也就是“爆發力強但沒耐力”？」

🧙‍♂️（博士）「沒錯！百米衝刺很強，跑全馬就不行的選手。」

計費的陷阱：忍者領時薪

🐣（學生）「所以這是“肌肉型選手用不上，一不小心就被帳單幹掉，可是聰明人能省錢”的技術？」

🧙‍♂️（博士）「沒錯！無伺服器就是“動腦就賺，鬆懈就爆炸”。不了解計費機制就會看到地獄。」

🐣（學生）「什麼樣的地獄？」

🧙‍♂️（博士）「比如寫了無限迴圈。傳統伺服器只是“伺服器變慢”，無伺服器卻會“新的忍者被無限召喚”。」

🐣（學生）「忍者大軍二十四小時工作，然後不斷來報時薪？根本恐怖片。」

🧙‍♂️（博士）「而且常常到月底收到帳單才發現：“咦？怎麼會是一百萬日圓？”AWS 被收好幾百萬的案例一大堆。」

🐣（學生）「太嚇人了。有對策嗎？」

🧙‍♂️（博士）「當然。設定計費警報、限制執行時間、限制同時執行數。就像好好寫下“忍者的聘僱契約”。」

真實事故：爆紅時的恐懼

🐣（學生）「真的有人被開過天價帳單嗎？」

🧙‍♂️（博士）「多得是。有名的案例是“照片美化應用爆紅被收 300 萬日圓”。」

🐣（學生）「哇……詳說。」

🧙‍♂️（博士）「某家新創做了“用 AI 美化照片”的應用，預估每張 0.1 日圓。」

🐣（學生）「結果呢？」

🧙‍♂️（博士）「在社群上爆紅，一天上傳 100 萬張，單張處理時間也超預期，實際變成“每張 3 日圓”。」

🐣（學生）「100 萬張 × 3 日圓 = 300 萬日圓……」

🧙‍♂️（博士）「而且連續 30 天。“爆紅但公司倒閉”就是現代悲劇。」

🐣（學生）「沒做防護？」

🧙‍♂️（博士）「沒有設定限制。因為覺得“不可能那麼紅”。現在大家都知道得設“成功上限”。」

🐣（學生）「“成功上限”這詞真諷刺。」

🧙‍♂️（博士）「“高興得尖叫”真的會變成哀號。」

開發體驗的變化：魔法的快感與限制的苦澀

🐣（學生）「開發時是什麼感覺？跟普通程式不一樣？」

🧙‍♂️（博士）「一開始很爽。“寫個函式按一下部署”就能全球上線，像變成魔法師。」

🐣（學生）「哇，聽起來真的很嗨。」

🧙‍♂️（博士）「但熟悉後問題浮現。本地不好測，除錯也麻煩。想問“為什麼不動？”時忍者早就消失，只能追日誌。」

🐣（學生）「像到案發現場只剩證據？」

🧙‍♂️（博士）「形容得精準，而且那些日誌散落在 CloudWatch、X-Ray、CloudTrail 等服務，得玩偵探遊戲。」

🐣（學生）「好麻煩。乾脆自己架伺服器不是更輕鬆？」

🧙‍♂️（博士）「這就是“無伺服器的陷阱”。起初像魔法，後來像詛咒。但一旦習慣，就再也不想回去伺候伺服器。」

🐣（學生）「意思是會上癮？」

🧙‍♂️（博士）「沒錯。“不用管伺服器”的快感像毒藥，卻換來“擔心帳單”和“設計限制”的壓力。」

無伺服器 vs 傳統：成本的現實

🐣（學生）「說到底還是錢。哪邊划算？」

🧙‍♂️（博士）「很複雜，取決於“使用量”和“可預測性”。我們用圖想像一下：

傳統伺服器

  • 固定成本：每月 5 萬日圓
  • 變動成本：幾乎為零
  • “定食餐館”模式

無伺服器

  • 固定成本：幾乎為零
  • 變動成本：依賴使用量
  • “迴轉壽司”模式」

🐣（學生）「哪邊便宜就看“吃多少”啊。」

🧙‍♂️（博士）「沒錯！小鳥胃去迴轉壽司，大胃王挑定食餐館。具體來說：

每月請求少於 100 萬次：無伺服器壓倒性便宜 每月請求超過 1000 萬次：傳統伺服器更划算 介於兩者之間：得把兩種方案和維運成本一起考量」

🐣（學生）「要是預測錯了呢？」

🧙‍♂️（博士）「那就像賭博。“去定食餐館準備大吃結果沒胃口”“去迴轉壽司想隨便吃結果變大胃王”都可能發生。」

無伺服器會成功嗎？

🐣（學生）「所以無伺服器究竟會成功還是會失敗？」

🧙‍♂️（博士）「不會有“完全勝利”或“徹底敗北”。傳統、容器、無伺服器會共存，各展所長。世界需要忍者、騎士、魔法師。」

🐣（學生）「懂了，沒有任何技術能包打天下。」

🧙‍♂️（博士）「對。沒有銀彈，但在合適場景非常強大。」

🐣（學生）「那推薦給什麼人？」

🧙‍♂️（博士）「比如說：

適合無伺服器的人

  • 想先快速做出能運作的東西
  • 有理解計費體系的算術能力
  • 比起完全掌控，更喜歡輕鬆管理
  • 對新技術能感到興奮

不適合無伺服器的人

  • 想全部自己管理的匠人型
  • 不擅長預算管理
  • 把穩定運轉看得高於一切
  • 離不開傳統系統的人」

🐣（學生）「也就是“喜歡新鮮事又會精打細算”？」

🧙‍♂️（博士）「總結得妙。這門技術需要同時具備“創新”與“節儉”。」

結語：把無伺服器當成生活方式

🐣（學生）「博士最後會推薦無伺服器嗎？」

🧙‍♂️（博士）「我不說“推薦”，我會說“理解後再用”。無伺服器是把“便利的誘惑”和“風險的現實”放上天平的現代咒語。」

🐣（學生）「咒語啊……可是咒語唸錯會反噬自己吧。」

🧙‍♂️（博士）「沒錯。所以要學會“正確的咏唱法”。無伺服器是“動腦就賺、鬆懈就爆炸”。不適合蠻力型，但聰明使用就是武器。」

🐣（學生）「懂了，也就是說：

  • 伺服器維運：靠肌肉硬撐的地獄修行
  • 無伺服器：用腦袋控制的帳單生存戰 對吧？」

🧙‍♂️（博士）「總結完美。選擇取決於情境，但“什麼都不選”已經不存在。現代工程師必須在“騎士、忍者、魔法師”之間抉擇。」

🐣（學生）「了解。先打好基礎，再考慮忍者。」

🧙‍♂️（博士）「保持這個心態，你也能成為出色的“忍者使役者”。只是別忘了盯帳單。」

🐣（學生）「明白！一定會設定計費警報！」

📌 最終註記：採用無伺服器的決策框架

是否採用無伺服器，需要綜合評估以下因素：

技術因素

  • 處理性質（批次 vs 即時）
  • 執行頻率（低頻 vs 高頻）
  • 狀態管理需求
  • 與傳統系統的整合

商業因素

  • 初期投資預算
  • 維運團隊的技能
  • 成長預測的可靠度
  • 對供應商綁定的容忍度

結論：無伺服器不是“萬能解”，而是“在特定情境發揮威力的專門技術”。理解並準備充足時它是強大武器，貿然導入則可能換來高額帳單。

對現代工程師而言，無伺服器是“必須了解的選項之一”，也是“必須因地制宜分工運用的技術”。