Microsoft Azure 食譜
(www.azure-recipes.tw)
因為我們是小公司，所以用雲端服務來說以「價格」導向為主的，不過每個 team 有自己喜歡的玩法，我只是單純說說我自己的「雲端之道」（聽聽就好，也可以完全不用參考）。那麼純看價格，azure 在台灣的代銷給的價還不錯，可以跟 HiCloud 拼（所以，如果有促銷的話，那麼 HiCloud 就完全可以劃掉了）。
一般的 IaaS 類的服務，如果要由 Google Cloud 與 AWS 選，同樣是價格導向的話，Compute 與 Storage 來看，Google Cloud 有越來越有看頭的樣子，而且它的 Instance 放久了自然地跌價，不像 AWS 的需要靠 RI 來替常備型的 Server 降價。我們可以把「原價」與 RI 的「合約價 + RI 時價」換成二元一次聯立方程式，你可以發現合理的持有時間在六個月左右，所以一個簡單的 POC 不知道會不會活超過半年就不適合 RI，但可以思考別的方法。
此外，先前在 其他回覆1 也提過網路品質來說，現有的 log 表示 Google Cloud 略勝一籌，再加上又比 AWS 便宜一點點，所以就會讓 Google Cloud 再加點分。由於價格常常在變，單就「一般性用途」得儘可能讓一個「基礎」設施可以放便地在各種雲上搬來搬去，也不一定是用 Docker，也可能只是簡單的 Ansible Playbook 把東西架上去而已，過的一種「雲端」時代的「逐水草而居」的生活。去掉了各種雲「交集」的部分，得思考一下，哪些功能是讓你願意被 vendor lock 的呢？
以常見的 video transcode 功能來說，雖然各家都有轉檔的功能，但是算起來還是自己土炮用 Spot Instance 轉比較划算！
像我們大部分的檔案都放在 S3，但看上的其實不是 S3（最初是，但後來發現 CloudFront 沒有想像中的美好），是因為心甘情願被 EC2 Spot Instance 綁住，所以檔案放在 S3 是最直接的處置，不要在 EC2 做完轉檔再耗網路丟出來（反正使用者也不一定會看到每一個影片、每一種規格）。
AWS Transcoder : EC2 : EC2 Spot Instance == 11:4:1
費用比例大約是這樣，其他家的大概是在 AWS Transcoder ~ EC2 之間，我想應該很難做出比 EC2 Spot Instance 更省錢的做法（這其實是一種線性規劃的問題，不同的 instance type 出來的比例會不太一樣）。若要在這方便搶客，只能用差異化競爭解決。不是「轉檔轉得夭壽快」就是「可以轉一般使用者無法自己做的東西，像 DRM」才有辦法搶到使用者讓他們買單。
所以，結論是「同質性高的部分比 CP 值」，不相交的部分比「服務與使用案例的適用度」。像 Google Cloud 若以便利性來說，Big Query 無疑是個大量 log 撈數據的方便工具，至於 Azure ... 還沒深入研究.... pass (心得：我真是澳洲來的客人)
--
那麼回頭說說 Azure，最近剛把一組新的 Cache Server 放上去，是還沒遇到一直重開的問題。不過有先問一些「身經百戰」的苦逼人士，他們給了些建議，針對 IaaS 為主軸的用法歸納起來重點為：
- instance 要放 virtual network 內（每一台要給它設好固定的 IP，不然被重開 IP 可能會變），放在 vnet 內互連也比較順，例如 C* node 間互傳。
- 如果服務要固定 IP 可以用 reserved IP 要在建好 Cloud Service 後，放第 1 台 instance 做設定。不然 Cloud Service 會自動把 IP 設為第 1 台 instance 被指的 Public IP。這 IP 會是 Cloud Service 的 FQDN 的實際 IP，通常固是是為了方便設火牆或是綁金流服務。
- Cloud Service 用它其實最重要是為了 Loading Balancer，然後它去年底終於加了 sticky session2 的功能，遺憾的是目前只有 PowerShell 有支援這功能，對於非 ms 平台使用的 azure-xplat-cli3 還沒加上這個指令，這功能對一些 legacy web application 沒有處理 session storage 問題的情況很重要，沒有它就等於要改 code。
- 然後 Loading Balancer 部分有 internal LB 這到是不錯，至少可以內部分外都能做基本的 HA。(那個不定期重開的問題，看能不能從架構上避開，避不開就不要勉強搬上去，放些可以 stateless 的服務就好)
- 另外，考慮到任何雲端都有可能整個 region 不見的問題，其實應該在不同區建 Cloud Service（就只是個 instance 邏輯上的集合），用 Traffic Manager 來導流量（可以想像成用 Route 53 做 HA，只是它沒有管 DNS 的功能）
PS. 蠻多文件提到 API 有要建憑證的，但是大多提 Visual Studio 附的工具 makecert.exe，它在 mono 內也有附但我裝了 mono-dev 後下指令跟「原裝」的不太一樣，它認不出一些參數。好在 【鐵人賽 30 天】從開源角度認識 Microsoft Azure4 內有提到如何用 openssl 建立憑證（可是我還沒試過用這樣的憑證是否能打通 vnet 的 vpn）。
PS. reserved IP5 不建議使用縮寫
1
2
3
4
5
qrtt1
積分 1
Azure 部分少提到 Availability Sets（因為當時還沒理解它是做什麼用的），會知道是來自於 William Yeh1 FB 上的討論。引述湯姆哥的回文：
如果是硬體損毀，是以 VM 為單位重開，如果是 Host OS Security Patch 等維護，是以 Cloud Service 為單位重開，但是用戶若有設定類似 AWS Availability zone 的 availability set，Cloud Service 內的兩台 VM 不會同時重開
IngramChen
積分 0
AWS transcoder : spot instance 是 10 倍啊，AWS 賺很大啊這。
azure 的 cloud 跟 MS 生態系太接近了，看你這樣講一下子要 PowerShell，一下子要 makecert.exe，也許一開始你可以佈署 linux 上去，但三不五時就要搞一些 windows only 的工具，這實在不是我的菜。(但 windows 開發者應該很爽，像回到家一樣)
IngramChen
積分 1
Azure 三不五時重開機改善了嗎？
好奇台灣現在雲端的使用比例:
- AWS
- Google Cloud
- Azure
- HiCloud
我猜 還是 AWS 最大宗，剩下的都是喝湯的份...
基本上如果服務對向是台灣，我會選 Google Cloud，它們的機房在彰化的樣子，ping 值很低。AWS 則是在日本或新加坡，Azure 我不熟，好像最近 DC 在香港。
可能的話我也希望 AWS 在台灣有機房，但短期內好像不太可能...
Google Cloud有個缺點就是不能用SMTP寄信，因為他把port鎖起來了，一定要用mailgun之類的服務
先前有寫了個文來分享 【Cloud TIPS】雲端主機與 Email 寄送1，針對 Google Cloud 部分，直接的方法寄不通主要是在 network 層的 firewall 就擋了 port 252 ，用替代方案是必然的，但是最好是由系統設定下手，例如 使用 postfix 替你做 relay3 ，而不是改程式的寫法呼叫其他 send mail service 的 API，不然程式多，或 team 多，大家各弄個的，都在做重工的事。像我們公司是用 AWS SES 配合 postfix 來 relay 的。
PS. AWS 也不是沒擋，但量不大的話他其實不會管你，量大時你就得 填個 form 綁個 Elastic IP4 給它列管。
1
2
3
4
AWS/GCloud 會擋 email server 也是情有可原，不然久了之後所有 IP 都變黑名單了。
我個人的做法是有點混合，如果要用 AWS 寄信 (kaif 和訂便當管理系統)，那我就直接用 AWS SES Sdk 寄了，因為少了部署與管理 postfix 這層功夫。而且一旦用了 SES，你就要有 app server 去處理 bounce 的 notification，這件事無法交給 postfix 做，所以 app 最終還是要處理 email 的骯髒事，無法完全委託 postfix。
如果是在 GCloud 裡要直接寄信 (比方說是 command line tool)，而不是透過 application server ，那就會透過 postfix relay 了。目前在 GCloud 裡我是接 free tier 的 sendgrid，還 ok。不過我也沒透過它寄什麼信就是，最大宗還是透過 AWS SES。