這三個大概是現在雲端服務做前三名的，規模的順序大概就是標題的順序 AWS 是最大的，其次 Azure ，Google Cloud發展較晚，是排名第三。
這篇文章不談一些AI的運用，只談資料庫與一般軟體整合的運用。一般寫好Web檔案，會採取兩種策略，一種是開個VM（虛擬機器），然後架設一個Web Server在虛擬機器上，把檔案放上去。這種策略跟地端的架設網站是一樣的，只是把地端的網站伺服器放到雲端。有些服務雖然是直接部署應用程式，但也需要VM的執行個體，Azure就有這種服務，我將它視為是相似的。
還有一種是不需要VM，做Serverless的架構，直接把程式碼或容器放到雲端，根據使用付費或者根據叢集付費（K8s）。直接將程式碼放到雲端的就是像AWS Lambda、Azure的Azrue Function、Google的Cloud Function。這種對於小型的程式很經濟實惠，有些連編譯都不用，直接放程式代碼上去就變成一個API。但安全性的控管就很重要，因為API若是公開，可能會讓惡意使用導致不能預期的結果（如資料異常存取或者費用爆炸）。
容器整個放上去的做得比較好的就是Google Cloud Run，Kubernates（K8s）三家平台都有，AWS、Azure都是根據叢集就要付70~80美金一個叢集的費用，Google則是較彈性的收費。
我的選擇
在評估雲端平台與使用的架構的時候，我花了大約1年的時間，從Azure的VM到AWS的EC2採取虛擬機器的架構，其實雲端的虛擬機器相當穩，比起地端自己架設IIS（我是走微軟的C#作為後端），當機一年有一次就算多。
我不會考慮Lambda和Azure Function、Cloud Function，因為程式碼多半很龐大，分割開來一個一個API部署會要命。
有時想想如果採取虛擬機器的架構，其實就跟十幾年前開始興盛的虛擬主機差不多，只是自訂的程度比較高而已，可以用SSH、RDP直接操作整台機器。如果是有24H要Run的Application那一定得走VM，如果只是放個RESTful API，其實VM浪費掉很多不必要的成本（比如下班以後可能只有一兩個人使用，又不能關機，閒置的vCPU就等於是浪費）。
由於現在公司開發的軟體前台是Angular，產生的是靜態頁面，只需要放AWS Amplify或者Google Firebase就可以了。費用跟VM分開算相當低。
所以刪去法，就往Cloud Run或K8s方向走。容器化的部署，可以將程式切割成大小不一的容器，有些容器會頻繁的呼叫，如確認Login狀態的API，因為運算很少，用到資源很少，可以用相當小的資源量分開來節省成本。
有些API可能會影響主要運算APIs的效能的比如圖形處理，如果把它放在主要容器裡面，那vCPU要配多一個。成本就變高很多，且又是不應該的資源浪費。就將它獨立成一個小的容器，部署在Cloud Run的另一個API位置，部署1個vCPU給他。而主要的APIs因為是資料庫處理，我們寫得最精簡和優化，所以也只需要1~2個vCPU。
Cloud Run的特色是可以設定閒置時期不分配資源，也就是不收費，這又節省掉很多VM浪費的資源。只是閒置後的第一次啟動延遲較久（會破1000ms）。
K8s是下一個要實踐的部分，因為都是容器化在部署了，轉K8s也不需要多太多的工作。因此我們公司選擇Google Cloud。
