雲產品的8/2選擇原則
在雲端應用場景下，80%的企業（默認情況）會選擇雲產品，只有20%的企業會考慮自行搭建對應服務。比如，有SLB，企業肯定不會自己去搭建Nginx做負載均衡；再如，有RDS，企業也定不會自己去搭建MySQL。
對於雲產品的選擇，有件事情讓我印象深刻。一次去北京出差，與同事一起拜訪了一家公司。這家公司在雲領域有十幾臺服務器，由一位運維人員負責維護。該公司的數據庫都是在ECS上搭建MySQL來運行的，於是我問那位運維人員，“為什麼不選擇RDS？”那位運維人員不假思索地說，“在ECS上搭建也挺方便的，為什麼要用RDS？”聽到這個回答，我有點不高興了，比較嚴肅且強勢地說，“使用RDS就不用你考慮安裝配置、調優、備份、擴展等問題，拿來就用，為什麼還要自己去折騰搭建！”所以選擇合適的雲產品，相比自行搭建，有以下技術方面及非技術方面的優勢。
五個技術優勢
安裝配置方面
一些軟件的編譯安裝，比如PHP，經常會有依賴包、版本兼容等問題，其安裝配置沒有想象中那麼簡單。而對於雲產品，我們不用再去官網找安裝包，也不用自己手動安裝、配置，這一切雲產品都默默地替你做了。
調優方面
對於雲產品，我們也不用關心一些性能參數要如何去優化，這一切雲產品也會默認替你實現。比如，MySQL的配置優化對細節、技術、經驗都有較大的挑戰，如果你對其性能要求較高，只需要在管理界面選擇更高規格的配置型號，或者選擇集群版本即可。
備份方面
在傳統運維過程中，我們需要搭建主從、編寫備份腳本以及操作Binlog來進行對應的備份及恢復，這方面對運維人員來說都是較大的挑戰。但使用雲產品時，我們也不用關心冷備、熱備方面的問題了，因為這一切雲產品都默認幫你實現了，你只需要“傻瓜式”地操作即可，哪裡不會點哪裡。
高可用方面
使用雲產品，我們不用擔心出現高可用方面的問題，也擔心什麼時候掛了沒辦法提供服務。在ECS、SLB、RDS、OSS等阿里雲產品中，都是採用集群的方式部署對應的雲產品，保證我們使用對應雲產品的高可用性。比如，ECS和OSS都是三副本的數據冗餘，而RDS，則是採用DNS+雙Master架構來保障高可用性。除了開放給用戶的一個RDS庫以外，還有一個隱藏的從庫未開放給客戶（舉例：進入RDS MySQL，通過“show slave statusG”可以看到隱藏的從庫）。
安全性方面
對於安全性方面，使用雲產品，不用關心軟件版本的安全性問題，也不用關心這個版本的軟件有哪些補丁、漏洞要去修復，更不用關心這個軟件會被攻擊的問題，這都是雲產品默認會做到的。
兩個非技術優勢
責任方面
在非技術方面，雲產品有一個很大的優勢，即如果是自己搭建維護的平臺出了問題，那麼對客戶、對領導都要負責，對應的損失也得自己承擔；相反，如果使用雲產品出現了對應問題（當然主要是雲產品穩定性、性能、安全性、高可用等本身問題，不包括因用戶不會使用及對應誤操作等導致的問題），那麼對應的損失甚至可以找雲廠商進行索賠。
部分企業在面向客戶服務的時候，想要自己招聘運維人員，而不想找第三方服務公司，覺得不安全，怕數據被第三方公司竊取，或者出現安全性問題。眾所周知，企業招聘員工，本身在成本和管理上就有很大的困難，這裡先不談這方面的挑戰。換個角度，企業招聘員工本身就是安全風險非常高的事情，比如，怎麼保障這個員工不洩密？其實很多企業的數據洩露，不是因為被黑客竊取，而往往是因為公司內部人員洩密。有時候，我們也會看到一些有意思的故事，比如“從刪庫到跑路”。雖然大家把這些故事都當成笑話，但殊不知這都是真實的案例。比如，一個運維人員因加班而失戀，之後格式化了所在公司的所有服務器並離職。因此員工造成的問題，結果只能是企業自己扛。若面對的是第三方專業團隊，那麼這些問題就可由第三方專業團隊解決，甚至向其索賠。
費用方面
當然，雲產品責任方面的優勢只是從特定的某個方面來說，具體情況還得看業務需求和業務場景。在實際應用中，很多用戶會覺得使用雲產品成本較高，不如自建平臺。單純使用高規格的雲產品的費用的確不低，但是深入瞭解後你會發現，想自行在ECS上搭建出和雲產品具備相同性能的環境，所採用的ECS臺數和ECS配置的費用加起來也不比使用雲產品的費用低多少，如下表所示。
這裡有一個需要注意的地方，RDS的8核16GB配置只是一個規格配置參考，並不代表我們自己ECS上部署的MySQL也要採用8核16GB配置，這是個細節誤區。RDS最主要的規格性能參數是：“最大連接數：4000; IOPS：8000”。所以在實際部署中，要讓數據庫達到如此性能。我們一般採用CPU和內存配比為1∶4的ECS配置（數據庫偏向內存型應用，具體實踐參考第5章），如4核16GB、8核32GB、16核64GB。在上述ECS的配置清單中，默認推薦選擇8核32GB是為了保障自建數據庫的性能和穩定性。而且RDS的高可用版是雙機高可用版，我們在ECS上自建的MySQL是單機版，這裡還需要再開一臺做主從，以保障數據庫數據的安全性和高可用。這樣一來，成本就進一步增加了。
選擇自建環境的條件
那麼，具體在什麼場景下我們才需要自己搭建對應的服務呢？對此主要從功能性和靈活性等方面來考慮，這也是自行搭建服務平臺的相對優勢。阿里雲的很多雲產品，如SLB、RDS、CDN等，其核心都是基於開源技術進行了封裝並做了相應優化，然後形成對應的雲產品。相應的封裝給我們帶來了相應的優勢，但同時也給我們帶來了相應的缺陷，比如，做了封裝，必然會使很多原生態的功能和特性存在一定的使用限制，下面我們具體來看。
七層SLB的功能限制
何為七層負載均衡？更多地稱之為反向代理，大家最為熟悉的就是Nginx。何為七層反向代理/負載均衡？是因為它不只是能做七層轉發，而更多的是能在七層上做很多Rewrite的七層控制等。而早期的SLB產品，連虛擬主機功能都不支持，只是可以簡單地七層轉發。當然，當前SLB產品已經支持虛擬主機，具有七層代表性的核心功能。如果想用Rewrite等更多七層功能，我們只能自行在ECS上搭建Nginx。
連接Redis，有密碼鑑權
有些客戶問這個密碼鑑權能不能去掉，代碼中採用了一個老的Ruby框架，不支持這個鑑權，也沒辦法改代碼。所以這時候我們只能無奈地在ECS上自己搭建主從Redis，然後結合Console+DNS做高可用。
RDS MySQL對Myisam存儲引擎的支持
在用戶的業務中，需要MySQL支持Myisam存儲引擎。而RDS MySQL版默認只支持Innodb的存儲引擎，所以我們只能在ECS上搭建MySQL來滿足業務需求。
雲數據庫MongoDB對跨地域多副本冗餘的支持
若客戶對數據的安全性要求較高，並且雲端和他們線下IDC做了專線打通，他們需要將雲端的MongoDB數據在線下IDC中做個副本，當前雲數據庫MongoDB結合DTS還不支持此功能。所以我們在雲端搭建了兩個副本，在IDC上同步一個副本，組成MongoDB的副本集。
綜上可見，有些功能是雲產品沒辦法支持的，且當前企業沒辦法調整自己的業務架構及代碼。這個時候基於靈活性和功能性方面的考慮，只能選擇在ECS上搭建相應的服務。