你雲我雲•兄弟夜談會 第一季 企業雲

第一季 企業雲

第二季 5G

 

週五的晚上，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. 面向業務運維，而不是面向資源運維。時刻想着從業務出發，不要一直盯着那點資源。

 

本文只是記錄此次聊天的內容，僅僅是我的觀點，不針對任何行業和公司。 

 

感謝您的閱讀，歡迎關注個人微信公衆號：