首先，現在很多學生跟客戶都已經懂得「雲端」/ Cloud 這個概念。要知道其實 Cloud 並不是甚麼新奇的東西，也不是這近 10 年才出現的東西，這個（類似的）系統 60 年代就已經存在的了，只不過當時我們叫它做「Client Server Model」而已。至於 Cloud，與其說它是一個技術，我反而覺得它比較像一個 Marketing 用的術語，對於要用在 technical document 裡面，我就比較有保留。
甚麼是雲端 / Cloud
我對雲端的見解基本上就是
別人的電腦
托比
這個我也曾在 Hong Kong Open Source Conference 2020 說過這個（不過是比較以開玩笑的角度來說），而實際上，如果你真的要向一個完全不理解雲端技術的人說明到底雲端的東西存放在哪裡，基本上你也會回答出類似的答案。
現代的網絡與雲端
很多時候現在的開發者對現代的網頁系統架設都是有以下幾種想法
- 是一個 Web Hosting Service 架設的網站，我只要在他們的伺服器上上載我的網頁檔案即可（例如 Github page 或是一些免費的 web hosting 網站）
- 直接在網頁上編輯網頁的供應商（例如 wix / wordpress）
- 一台電腦，上面開著 XAMPP / WAMP / LAMP 來架設網站（例如自己寫的 php / HTML 網站）
- 一個 process 開著一個程式以處理要求（e.g. Nodejs / Golang）
可是實際上現代的網頁系統比你想像中的要複雜一點，基本上會自己架伺服器的已經不多了，還會用上很多第三方的 cdn 檔案等等。但是由於這篇文章不是用來教你設立網站，所以我直接跳到結論：
現代的網頁應用程式對於第三方依賴性比以前高很多
例子好像說 Cloudflare 、AWS / Google / Azure 的 VM 、CDN、Github / Gitlab 等等
成本與依賴性
通常我說依賴性，我指的有兩種，一種是開發的依賴性和運作的依賴性。如果你有寫過 Nodejs 或是 Golang 的網頁你應該都有聽過 module 這東西，這東西就是我所說的開發依賴性之一；另外一種就是運作的依賴性，例如說 cdn、api 之類的東西。
我對第三方依賴性其實沒有甚麼特別抗拒，畢竟你還是需要把你的系統跟其他的網頁系統連接在一起。例如分享到社交平台、電郵等等。然而，有一些東西是我絕對不會碰的，就是具有平台依賴性的 API。
甚麼是平台依賴性？
平台依賴性是指你寫的程式必須要使用某一供應商的平台才能正常運作。例子如 Firebase、Lambda 等等。
為甚麼具有平台依賴性的 API 應該盡量避免？
平台依賴性的 API 會讓你無法轉移系統到另一平台，做成 Vendor lock-in 的情況。這情況除了網絡之外其他平台也會出現，例如說必須依賴 Windows API 的（古老）程式、必須依賴 iPhone + iOS 的硬體才能運作的 App 等等，這些都是 vendor lock-in 的例子。
你可能會覺得：這個我只是用來試試市場或是所謂的 Proof of Concept 作品而已。用這些 API 也沒甚麼吧？
不對，因為很多時候商業機構看到你的 PoC 作品能用就會直接在上面加建成為他們的最終產品，然後繼續用它來發展商業項目。這個時候就會變成真正的 Vendor Lock-in 了。如果有一天供應商中止他們的服務或是突然收取很高昂的平台使用費，到時候你就沒辦法只好乖乖的付錢了。
所以我一向的做法都是當有客戶要選擇使用雲端服務建立網頁系統的時候我都會推薦他們用 VM。VM 的 Guest OS 我一向都會選擇開源的 Debian 或是 Ubuntu。這樣萬一有需要改換供應商的一天，整套系統也可以很輕易的從一個 Linux VM 轉移到另一個 Linux VM 而不需要更新原本的 code base。
可是如果不依賴第三方 API 有這麼多好處，為何這麼多人還是在用具平台依賴性的 API？
最主要還是成本問題。這些 API 的供應商一般都會做出簡單易用的網頁界面，讓網頁系統的開發者很容易就可以透過 API KEY 來存取到他們在雲端上的數據庫、core logic 或是其他本來需要伺服器運算的東西。他們能夠省下更多開發及架設後端的時間，更不用對著 Linux terminal 輸入指令還要處理間中跳出來又看不懂的 linux 錯誤。在以 man-hour 收費的 IT 界來說，這種能夠節省成本、客人又看不出來而且又省功夫的做法，誰不想用？
一分錢一分貨
很多人以為軟體跟去超市買菜一樣，能叫價就叫價、去比較便宜的那家買就好。其實與其說 Software 是一件商品，你應該視它為一件藝術品。再怎樣簡單的程式也能夠有便宜和貴價之分別，如果你沒有 technical 背景可能看不出來，但是很多時候這些價錢差就差在
- 有沒有使用說明及技術文件
- 有沒有處理 Edge Case
- 處理速度、穩定性
- 界面的人性化設計、Flow 設計跟使用者體驗
- 兼容性、平台依賴性
- 開發者溝通能力
所以說，開發軟體真的是一分錢一分貨，貪小便宜只會麻煩到未來的自己。
實用與理想之差別
不過回到現實情況，如果你的系統需要完全沒有第三方的依賴性這是不可能的，畢竟你不可能從沙開始煉硅晶。但是你可以做的是盡量減少 runtime dependencies。這樣的話你的程式就算 cdn 壞掉、第 三方的 deprecate 等等，只要你的 Host 主機還存在，你的系統都能運作。這也是為啥我開發的商業用網頁系統大部分 dependencies 都是從自己的主機載入的。雖然這樣會吃掉更多流量，但是我可以確認如果我的系統有 bug 一定是我弄出來的，而不是由於第三方的更新或是甚麼我沒法處理要等別人修理的問題。
ArozOS 與依賴性問題
如果你有看過 ArozOS 的源碼，你就知道 ArozOS 是一個基本上沒有 runtime dependencies 的一套系統。
https://github.com/tobychui/arozos
它所有 dependencies 都是在 compile 的時候需要，一但你 compile 它成執行檔並啟動之後你把它的網絡斷掉它也是能繼續正常運作的。這也是我一直堅持的開發原則：不會被第三方的資源或 api 影響到 ArozOS 的運作穩定性。現在就只差一塊 100W 太陽能板和一個電池組來驅動一塊裝有 ArozOS 的 raspberry Pi 它就真的可以完全 off grid 的運作了（不對
當然，這種這麼高層次的獨立性在一般用途上是用不著的（畢竟如果你把網絡斷掉的話別人都連接不了你的網站），但是如果能做到的話能夠獨立於這個（有夠混亂）的互聯網說不定也是一件好事。
結論
所以結論就是，除非真的必要，不要用有平台依賴性的工具或是 api。也盡量不使用開源方案，以保證自己開發的系統的獨立性。對，AWS 、Google 或是 Microsoft 壞掉的機會率是不高，但是說不到有一天你就突然連不到 Google Drive （之前不是試過一次它們的登入系統故障？）或是你 Office 365（最近他們才出現過一次 DNS 問題）
所以這個情況下還是有可以自動切換備用方案會比較好，當然最好還是不要把核心功能依賴到第三方平台啦。
當全世界的網頁都掛掉可是你的系統完全沒影響的時候的優越感一定超棒的喔~
才怪（