云計(jì)算轉(zhuǎn)型哪些地方會(huì)出錯(cuò)？

KoreyLee 發(fā)布于2019-06-28 10:56 / 1146人閱讀

摘要：盤點(diǎn)云計(jì)算的優(yōu)勢，較低的托管成本較低的基礎(chǔ)架構(gòu)復(fù)雜性較高的可擴(kuò)展性這些都是實(shí)實(shí)在在的好處。好雨，讓云落地，提供以應(yīng)用為中心的云計(jì)算產(chǎn)品和服務(wù)。

盤點(diǎn)云計(jì)算的優(yōu)勢，較低的托管成本、較低的基礎(chǔ)架構(gòu)復(fù)雜性、較高的可擴(kuò)展性……這些都是實(shí)實(shí)在在的好處。不過對于企業(yè)來說，選擇云計(jì)算最關(guān)鍵的驅(qū)動(dòng)在于產(chǎn)品速度，換句話說，利用適當(dāng)?shù)脑朴?jì)算產(chǎn)品和技術(shù)，我們可以在最短時(shí)間內(nèi)把理念變成用戶需要的實(shí)際產(chǎn)品。

過去三年里，有大量的企業(yè)投入到了容器化架構(gòu)的懷抱之中，從踩坑到克服未知的難題，再到得心應(yīng)手，一部分公司逐漸嘗到了“產(chǎn)品速度”帶來的甜頭。

但也有另一部分企業(yè)，容器運(yùn)行測試、擴(kuò)大測試范圍、得到管理層批準(zhǔn)、全面遷移上云，并且相信容器編排工具Kubernetes會(huì)處理好所有的事情，然后在一切似乎順利進(jìn)展的過程中，莫名其妙陷入了與指數(shù)級增長的復(fù)雜度抗?fàn)幍匿鰷u之中——監(jiān)控、存儲(chǔ)、處理不同組件、定義通信、網(wǎng)絡(luò)安全……進(jìn)退兩難。

問題到底出在哪呢？以下六點(diǎn)，拋磚引玉。

第一：基礎(chǔ)設(shè)施

企業(yè)一般會(huì)在IaaS廠商那里買幾臺(tái)機(jī)器，希望通過將基礎(chǔ)設(shè)施遷移到云端來達(dá)到馬上省錢的目的，卻發(fā)現(xiàn)成本非但沒有降低，反而可能有些上升，于是開始反思是不是哪里出了問題。

出現(xiàn)這種情況其實(shí)是正常的，首先通過不斷的調(diào)優(yōu)，資源方面的節(jié)省才能顯現(xiàn)出來；其次云計(jì)算的核心更多在于低風(fēng)險(xiǎn)和敏捷性，而不完全是“可見的成本“。

想象我們用過去普遍的方式為數(shù)據(jù)中心購買硬件，很可能會(huì)買到錯(cuò)誤的大小或者錯(cuò)誤的機(jī)器，此時(shí)我們應(yīng)該拿這些機(jī)器怎么辦呢？另一方面，把應(yīng)用調(diào)整到一個(gè)不適合的環(huán)境中本身是一個(gè)耗時(shí)費(fèi)力的過程，這方面的成本怎么算？

選擇云計(jì)算的話，以上問題迎刃而解，原本購買基礎(chǔ)設(shè)施的風(fēng)險(xiǎn)要小得多，配置環(huán)境的時(shí)間和人力成本同樣大大降低，也就是說我們產(chǎn)品速度上的成本降低了。對于開發(fā)者，是花兩年時(shí)間來做對業(yè)務(wù)有直接價(jià)值的工作，還是與錯(cuò)誤的環(huán)境斗爭到底，答案是很明顯的。

所以第一個(gè)經(jīng)驗(yàn)是，首先思考如何降低風(fēng)險(xiǎn)，而不是降低硬件成本。

第二：自動(dòng)化

過去的經(jīng)驗(yàn)告訴我們，私有云也可以實(shí)現(xiàn)非常高的自動(dòng)化水平，一切取決于企業(yè)是否選擇了正確的服務(wù)和工具，像自動(dòng)化部署、CI/CD、自動(dòng)化配置、伸縮等等。

在這一方面需要注意的問題主要集中在落地模式和建設(shè)規(guī)劃兩方面。落地模式上，企業(yè)需要按照自身情況來做出選擇，是使用定制化產(chǎn)品，還是在開源框架的基礎(chǔ)上自己進(jìn)行開發(fā)；建設(shè)規(guī)劃上，企業(yè)的自動(dòng)化過程往往不是一蹴而就的，需要一個(gè)循序漸進(jìn)的過程，前期的IT架構(gòu)梳理極為關(guān)鍵。

第三：文化

在技術(shù)向云計(jì)算轉(zhuǎn)變的同時(shí)，企業(yè)文化也應(yīng)該隨之而變。傳統(tǒng)的模式下，企業(yè)規(guī)避風(fēng)險(xiǎn)即不惜一切代價(jià)將不確定性最小化，這導(dǎo)致很多企業(yè)IT拒絕進(jìn)行改變，也就逐漸在競爭中落了下風(fēng)，而這也是部分企業(yè)在云計(jì)算技術(shù)方面實(shí)施后，發(fā)現(xiàn)并沒有解決問題，反而產(chǎn)生了新問題的原因所在。

正確的做法是應(yīng)用一種“實(shí)驗(yàn)“的文化，通過分析、規(guī)劃、評估和測試來嘗試不同的方法，根據(jù)結(jié)果來進(jìn)行調(diào)整，隨時(shí)準(zhǔn)備好迭代、準(zhǔn)備好回滾、準(zhǔn)備好再一次嘗試。

這也就是為什么DevOps被公認(rèn)為是一種文化，也是IT轉(zhuǎn)型的重要途徑。當(dāng)然文化本身的轉(zhuǎn)變也不是一朝一夕的事情，需要從早期開始落實(shí)，更需要持續(xù)不斷的影響和強(qiáng)調(diào)。

第四：微服務(wù)

關(guān)于微服務(wù)架構(gòu)的定義、優(yōu)勢等等不必多言，從spring cloud、dubbo到最新的service mesh，這些年大紅大紫的微服務(wù)架構(gòu)，真正能夠拿出來作為可實(shí)踐案例的不多。

除了對于技術(shù)棧的選擇困難，很多企業(yè)的誤區(qū)在于“一步到位”的錯(cuò)覺，導(dǎo)致企業(yè)本身將最初的門檻設(shè)立極高，而正常的過程是應(yīng)當(dāng)以最小代價(jià)發(fā)布第一個(gè)微服務(wù)，在跨過這個(gè)門檻之后，剩下的工作可以被復(fù)制而且速度會(huì)越來越快。

另一個(gè)教訓(xùn)，其實(shí)不止是微服務(wù)架構(gòu)方面，就是盡量不要重復(fù)造輪子，參考或者選用成熟的解決方案永遠(yuǎn)會(huì)是最便捷的落地途徑。

第五：容器化

Docker是容器化最突出的技術(shù)代表。利用Docker構(gòu)建一個(gè)容器，包含一個(gè)微服務(wù)所需的所有依賴，而后部署在任何想要部署的地方。

而在最近，docker受到了一些批評和質(zhì)疑，我們認(rèn)為原因在于很多企業(yè)對docker的期望有些不切實(shí)際，而忽略了容器化同時(shí)需要考慮的調(diào)度編排、存儲(chǔ)網(wǎng)絡(luò)、服務(wù)注冊發(fā)現(xiàn)以及宿主機(jī)管理等等緊密聯(lián)系的技術(shù)問題。

另一方面，我們要知道Docker其實(shí)并不是一項(xiàng)新技術(shù)，它的創(chuàng)新更多是在思想層面，在它對于封裝、隔離、發(fā)布的改進(jìn)。

第六：編排

真正用于生產(chǎn)的應(yīng)用往往會(huì)跨越多個(gè)容器，往往會(huì)部署在多臺(tái)機(jī)器上，會(huì)涉及到如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、高可用、存儲(chǔ)、網(wǎng)絡(luò)等等。目前容器編排事實(shí)上的標(biāo)準(zhǔn)是Kubernetes。

關(guān)于Kubernetes，難點(diǎn)在于這一容器編排工具本身包含很多高難度技術(shù)概念，學(xué)習(xí)門檻很高、學(xué)習(xí)曲線很陡峭，同時(shí)缺少管理流程。所以這里容易出現(xiàn)的是“用不起來“的問題，解決辦法除了活學(xué)活用，還可以考慮使用第三方包裝好的Kubernetes面板和解決方案。

好雨，讓云落地，提供以應(yīng)用為中心的云計(jì)算產(chǎn)品和服務(wù)。訪問 https://www.goodrain.com 了解更多