先前有寫了個文來分享 【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 給它列管。
因為我們是小公司，所以用雲端服務來說以「價格」導向為主的，不過每個 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 不建議使用縮寫
看到新文章（新的葉佩雯）立馬查了一下官方文件 HTTP/HTTPS Load balancing1 跟我想的一樣，它終於支援 HTTPS 了!!!
HTTP/HTTPS load balancing provides global load balancing for incoming HTTP or HTTPS requests, allowing these requests to be sent to different sets of backends based on patterns in the URL. HTTP requests can be load balanced on ports 80 or 8080, and HTTPS requests can be load balanced on port 443. HTTPS load balancing also includes support for SPDY and HTTP/2.
如果職務只管到雲端部署，那還是只算 operation/sysadmin 而已，即使是用了 docker/puppet 等等比較自動化的工具。
即使只是這樣也有很大的進步了（以現狀態說就有著很大的進步空間）。
雲端部署還是有很多東西要弄的，Dev 以發展產品為主，Ops 傳統上比較篇向把產品弄進去能動為主，而其實在整個環境的整理上仍有許多「待開發」的東西，這些可能是由 Ops 給 Dev 發 requirement 或是運用現有的工具。不過台灣來看，大多的 team 都太小把資源大多投入在 RD 或行銷，變成 SysAdmin 投入的不夠多（沒有這個人或是沒能請到足夠品質的人選），只能由「devops 是開發者兼操作員吧」。
DevOps 本身指的並不是把二種角色加起來的 Dev & Ops，而是要去除這中間做事方式與目標的隔閡，並加速由開發到維運間的工作流程。Dev 以發展新功能為主要目標，而 Ops 以 Service 穩定為主要目標。而 Dev 與 Ops 分別熟悉的 Toolset 與 Mindset 都不同，需要互相熟悉一下對方能用的工具，來找出適當的作法，或處理事情的策略。
--
(以下抱怨文)
不過，俺目前看起來是 DevOps 大概會由 Dev 吃掉，因為習慣維運的並不一定想改變現有的做事方式，由於不能配合行動。只我也不想陪著活在已知用火的年代，除了開始學習新的工具使用，還有改變流程，甚至還會恐嚇大家（笑）像是，
禁止手工安裝必要的軟體或程式到 Server 上，不然每回想要重弄或新部署時，就把該負責的人當作一個可以 call 的 function，不方日夜打給他，請他協助。
取而代之的，應該要被整合至部署用的 ansible playbook 內。
在之前有想過覺得薪水低的 MIS or SysAdmin 可以多學一下 Cloud Solution 跟 DevOps 需要的知識跟工具，這樣自動化的工作會越來越多。在它被成「基本技能」前，可以用比較高的水準的薪資進入職缺。
那麼當它在變成「基本技能」之後呢？倒不是說薪水提不起來的問題，而是原先死抱著設備、實體主機不放、視擁有管理者帳號密碼為權力的心態，將會隨著 DevOps 的「文化」擴散而被驅逐，取而代之的是 immutable deployment 與 disposable servers。原來佔著位置的人，也許是到較傳統的開發環境或者再也無法進入門檻。
這件事不單純是一個 DevOps 是否要不要學習的問題，而是由「工人智慧」轉化為「自動化管理」的差別，這會外顯於「工作量」與「執行者」的比例。
大量依賴人工的情況，工作量大，就需要的人多，成長曲線會依工作量需增加人數或者「人月」，走向自動化的理想目標則是人數或人月不需要隨著工作量增加而快速成長。這去除了一個「人因」的工作承載量的瓶項，也有機會解救一些能善用工具的人於苦勞之中。
這文章讓我想起上回的 論文口試，啊，不對是 上回在 Soft_Job 版徵人1。其中有大部分的時間是在說明為何我們公司目前技術的 stack 長成這個樣子。
不過，仍有些人抱持著技術舊、工時正常即為養老的看法。看了這篇文章，我想我抓到了些重點。