轉載自Sammy Liu博客
週五的晚上，4個搞雲計算的中年男人，在洗完碗、完成老闆交代的工作，並把小孩弄上牀後，10點多，通過微信羣聊，又『坐』在一起，從一個場景開始，聊起了幾個關於『雲計算』的話題。其實還有兩個人本來也要加入，但是一個人的小孩子那天睡得比平常晚，另一個人的女朋友臨時把他叫了過去，所有都沒能加入。
0.被討論的場景
一個傳統企業，之前養過一個研發團隊搞基於開源項目的雲平臺（比如OpenStack，Kubernetes 和Ceph），或者從一家小公司採購進來一個雲平臺。不巧，因爲各種原因，自己的研發團隊解散了，或者外部的小公司倒閉了。那麼，現在這個雲平臺該怎麼處理呢？如果時光倒流，允許從頭來過，這種結局有辦法能夠避免嗎？
1.關於這個問題的討論和結論
1.1 怎麼處理？
處理方式不外乎以下幾種：
重新搞研發團隊。這辦法說起來簡單做起來很難。
一來團隊散了再要重建的話，所付出的代價比當初養團隊要高很多。
二來要養一個搞定這三個或其中一兩個開源項目的開發團隊，估計至少得5個人。光人力成本，一年估計得200萬。另外小團隊的穩定性一貫是個大問題，少了一個人，那就缺了一塊，然後又很難招進來合適的人補上。
自己搞運維團隊，如果代碼有問題搞不定則找外面能提供服務的供應商。其實這就是自己組建L1團隊，花錢從外面買L2和L3團隊的服務。這應該是比較靠譜的做法。畢竟運維人員一般要比研發人員成本低不少，而且隨着開源項目越來越穩定，並沒有那麼多的代碼上的問題。但是這有幾個前提條件：
運維團隊具有一定的能力，運維問題都能搞定。如果搞不定，甚至還要買L1運維服務。
如果運維團隊裏面有一兩個人有一定的代碼能力（如果出現bug，能定位到代碼位置，並能從社區找到fix，然後更新平臺），那基本上從外面找L3服務就差不多了。
如果平臺源代碼是私有的，或者供應商基於開源項目做了大量定製，那麼從外面找 L2 和 L3 服務供應商都非常難。此時得考慮遷移。
將平臺遷移到新平臺。這裏面有很多問題需要考慮：
選擇什麼樣的新平臺？這個問題就又回到了下面 1.2 部分。
遷移成本多高？之前聽說過有客戶是這麼幹的。基於一個小供應商的某平臺經常出故障，小供應商後來沒了，不得不遷移到一家大廠的產品。這過程非常折騰，代價很大。
1.2 怎麼避免？
如果時光倒回去，假設你是決策人，要怎麼避免這個問題呢？可從以下幾個方向進行考慮：
對於基礎架構（iaas平臺、paas平臺、分佈式存儲、數據庫等），找大廠的成熟產品，採用偏保守策略。一來產品成熟，運維壓力不會太大；二來出現了代碼級問題，由大廠來解決；三來出了問題可以找大廠背鍋。這種產品其實可以分爲兩大類：
大廠的私有云平臺。此時企業需要有自己的平臺運維團隊，同時需要大廠提供代碼級支持。當然了，有錢的單位可以直接購買駐場運維，但也會帶來很多問題。
大廠的公有云平臺。其實企業只需要應用運維，雲平臺由公有云廠商搞定。
對於非關鍵業務環境（比如開發測試環境）或者管理平臺（比如CMP），以及輔助系統（比如監控和日誌系統），可以自己團隊基於開源項目搞定。一來這些東西不處於核心的數據平面上，因此即使出了問題也影響不會太大；二來可以鍛鍊團隊；三來可以根據自己的需求進行適當的定製。
如果不想或者不能或沒錢找大廠供應商，那最好能做到以下幾點：
供應商的產品的核心代碼是基於開源項目的，或者只有少量定製。
拿到源代碼。
藉助供應商，培養出自己的運維團隊，其中有幾個人具有一定的代碼能力。
2. 傳統企業如何決策基礎架構平臺？
決策過程要考慮很多因素，其中一個關鍵步驟是區分業務環境：
運行核心業務系統的生產環境：建議找大廠的成熟產品。對於這部分，穩定，有支持團隊，成本應該是三個主要的考量角度。
運行非關鍵系統的生產環境：可以找外面創業公司的產品。對於這部分，成本，新技術應該是主要的考量角度。一方面也支持創業公司和行業的發展；另一方面比自己搞時間和成本都要短一些。
非生產環境，比如開發測試環境：可以自己團隊搞，一方面鍛鍊團隊，另一方面也節省成本。對於這部分，成本，新技術，培養團隊應該是主要的考量角度。
3. 其它一些討論到的東西
3.1 對傳統企業來說比較合適的雲平臺架構是啥樣子？
下圖也許是一個比較合適傳統企業的架構：
3.2 對基於開源項目做產品化的公司說的幾句話
1. 如果是創業公司，你要說服或者替客戶想到避免廠商鎖定問題，那麼就要求在覈心組建上儘量和社區保持同步。要麼直接使用社區的，如果自己有定製的話，就同步到社區。
2. 看國外公司是如何基於開源項目做產品的，OpenShift 和 Rancher 是兩個挺好的例子。
3. 讓產品儘量保持簡單，不是越複雜約好，因爲，我個人不太看好各種 On 的架構，比如 K8S on OpenStack，OpenStack on K8S 等。想着運維壓力就頭大。
4. 如果是大廠（比如華爲華三這種），可以有定製，因爲大廠有能力給客戶提供長期支持。
3.3 MSP 的重要性會顯示去價值和重要性
1. 隨着公有云越來越廣泛地被企業用戶所接納，那上雲、架構設計、運維、安全等需求將會越來越多，這是MSP的業務範圍。
2. 企業中會出現越來越多的沒人管或沒人能管得了的雲平臺，MSP 有實力的話提供開源平臺的 L2 甚至 L3 運維服務的話，將會有客戶找上門。
3. 隨着混合雲的逐步推廣，網絡和安全將變得越來越複雜和重要，而這兩個東西門檻又非常高，正好這是MSP的業務範圍之一。
3.4 VMware 中短期內無法被替代
先看看vmware這5年的股價變化趨勢：
VMware vSphere 真是功能豐富、強大、穩定、可靠，還能在購買許可證上想想辦法。
現在還有CMP，對外提供自服務界面和API，分分鐘將虛擬化環境改造爲雲環境。
VMware 和 AWS 都合作得那麼緊密了，其價值對於AWS 來說顯而易見，對用戶來說，本地vmware 環境連上雲上vmware 環境，那用戶體驗還是相當爽的。
3.5 對開源社區想說的幾句話
1. 多關注企業用戶的需求，不要埋頭寫代碼。一直認爲開源社區應該有產品經理。當然了，有人說開源社區做的是開源項目，不是產品。如果只是玩技術，那結果很可能就是自己玩得嗨，用戶最多把你的東西放在邊緣環境或政績項目上。
2. 更加關注核心模塊穩定性，一開始就保持核心模塊的穩定，從而減少二次定製的需求。不要只想着做大。
3. 教育好利用你們的開源項目做產品的創業公司，他們該往什麼方向做，該如何和社區分工配合，如何幫助落地到用戶的數據中心等。
4. 對多長時間後能進企業的核心生產環境更加現實一些。
3.6 對公有云供應商說的幾句話
1. 多關注傳統企業吧，他們纔是未來你們的客戶的主力軍，不要成天只宣傳上億併發和秒殺了，這些東西傳統企業用不上估計也懂不了。他們更加關注的是穩定性、數據安全性、跟他們自己的數據中心打通、遷移成本、是否要改應用架構才能上雲、現有運維人員能夠做得了運維、成本、能否跟現有運營平臺整合等問題。
2. AWS 把 VMware 拉在一起合作，把 VMware 環境搬到他們的公有云和私有云上，推出 Outposts，這些是真正關注傳統企業的舉措。AWS + VMware 其實也可以類比爲 CMP + vSphere。
3. 真正的『以用戶爲中心』，是要時刻想着用戶的需求，不管自己之前說過什麼（AWS 之前說私有云不是雲，只有公有云纔是，言外之意VMware更不是雲）。現在用戶需要什麼，那就提供什麼。
3.7 對傳統企業說的幾句話
1. 雲可以有多種形式，VMware + CMP 可以看做雲，私有云其實嚴格來說不是雲，至少它缺乏雲應有的規模性和彈性，公有云纔是真正的雲。
2. 上雲不能只是資源上雲，上雲更是一種理念。如果只是把應用從物理機上遷移到虛擬機上，這並不叫上雲。上雲至少還包括開發上雲（面向雲開發，DevOps，CICD等）、應用上雲（面向雲制定應用的雲上架構並進行部署）等。
3. 在做雲平臺決策的時候，首先要做的是對自己的業務進行分級，多少核心業務系統，多少非關鍵生產系統，多少開發環境等，然後確定不同的需求。
4. 在做雲平臺決策的時候，想想做雲平臺的團隊將來要是撂挑子不幹了那要怎麼辦，誰來收拾局面。如果確定了做雲的人，不管是自己人還是外面的廠商，就對他們好點，把他們當合作伙伴對待，因爲他們是你出問題的時候救你命的人。
5. 算成本的時候，把養研發團隊、運維團隊、廠商支持服務的成本也一併算上。
6. 打算養研發團隊自己做雲平臺的時候要想清楚，是在基礎架構層定製呢還是在管控層面定製，是不是一定要私有云，是不是能上公有云，團隊穩定性和成本如何，如果幾年後團隊不在了該怎麼辦。
3.8 對雲開發和運維人員說幾句話
1. 雲底層開發將來更多的會存在於大廠那裏。小的雲團隊更多依賴於開源社區，只有大廠纔會有實力和業務需求養大的基礎架構研發團隊，這樣的團隊成員纔有機會做真正的底層技術研發。
2. 每個雲的用戶都會需要運維人員，不管是什麼樣的客戶，連公有云的用戶也需求運維。將來能看懂開源項目代碼並能修補一些簡單bug的運維人員會更有市場需求。
3. 雲運維人員要面向雲運維，以雲的理念做運維，能讓自動化工具乾的事情就不要人肉做。即使現在做的是傳統運維，有時間的時候，去考個AWS的雲架構師和雲運維專家認證，會很有價值。
4. 面向業務運維，而不是面向資源運維。時刻想着從業務出發，不要一直盯着那點資源。
本文只是記錄這次聊天的內容，僅僅是個人觀點，不針對任何行業和公司。