通過上篇文章咱們對Kubernetes以及Kubernetes解決了哪些問題有了完整的認(rèn)知，不過為了將企業(yè)的核心應(yīng)用部署到Kubernetes平臺上，我們離目標(biāo)還很遠(yuǎn)。筆者過去幾年的從業(yè)經(jīng)驗(yàn)顯示，凡是能成功落地Kubernetes并將大部分核心企業(yè)遷移到Kunernetes平臺上的企業(yè)，都采用了應(yīng)用程序平臺（Application platform）這樣的組件，來彌合Kubernetes的復(fù)雜性和應(yīng)用程序部署需要提供的易用性之間的矛盾。阿里云提供的EDAS就是這樣的一種應(yīng)用程序管理平臺，極大的降低了基于ACK的應(yīng)用程序部署和管理，運(yùn)維工作的復(fù)雜性。
EDAS或者說應(yīng)用程序平臺本質(zhì)上解決的問題是提供一種應(yīng)用的，對用戶友好的平臺來部署，監(jiān)控和管理容器化部署的應(yīng)用程序。由于每家企業(yè)實(shí)際面對的部署場景會非常不一樣，不過EDAS這樣的應(yīng)用程序平臺總是能夠在提升開發(fā)人員的效率，降低運(yùn)維費(fèi)用，以及加速應(yīng)用程序部署頻率等方面為企業(yè)帶來價(jià)值。應(yīng)用程序平臺是基礎(chǔ)設(shè)施和應(yīng)用程序交匯的領(lǐng)域，因此這個領(lǐng)域?qū)﹂_發(fā)和運(yùn)維人員來說最重要，應(yīng)用程序平臺要解決的核心問題就是如果抽象底層的基礎(chǔ)設(shè)施和Kubernetes平臺，來為開發(fā)和運(yùn)維人員提供一套易用的應(yīng)用程序發(fā)布，部署，監(jiān)控和管理平臺。
注：企業(yè)級分布式應(yīng)用服務(wù) EDAS（Enterprise Distributed Application Service）是應(yīng)用全生命周期管理和監(jiān)控的一站式PaaS平臺，支持部署于 Kubernetes/ECS，無侵入支持Java/Go/Python/PHP/.NetCore 等多語言應(yīng)用的發(fā)布運(yùn)行和服務(wù)治理，Java支持Spring Cloud、Apache Dubbo近五年所有版本，多語言應(yīng)用一鍵開啟Service Mesh。關(guān)于EDAS的詳細(xì)信息可以參考阿里云官方文檔。
應(yīng)用程序平臺有很多不同的形態(tài)，大體都是對底層的IAAS或者PAAS層的抽象，比如在Kubernetes出現(xiàn)之前，大家應(yīng)該都聽說過Heroku和Cloud Foundry，這些平臺不光為我們提供了一鍵式的應(yīng)用程序打包和部署服務(wù)，也提供了應(yīng)用程序高可用保障，以及靈活的擴(kuò)縮容服務(wù)。從開發(fā)人員的角度看，Heroku是否使用Kubernetes根本不重要，底層到底是企業(yè)自己的IDC基礎(chǔ)設(shè)施還是阿里云的IAAS服務(wù)，也不重要。重要的是將應(yīng)用程序部署，運(yùn)維，監(jiān)控代理給Heroku平臺后，開發(fā)人員可以將寶貴的時間用在價(jià)值更高的工作上，例如新功能開發(fā)，代碼重構(gòu)等。
RedHat的OpenShift是另外一個很好的例子，對于OpenShift來說，Kubernetes更多的是實(shí)現(xiàn)層面的細(xì)節(jié)，開發(fā)運(yùn)維人員的日常工作基于OpenShift提供的這層應(yīng)用程序平臺抽象，這層抽象充分考慮了易用性和簡潔性，極大的屏蔽了底層平臺的復(fù)雜性和多樣性，讓用戶能夠有一致的使用體驗(yàn)。
如果Cloud Foundry，OpenShift以及Heroku已經(jīng)為我們解決了應(yīng)用程序部署，擴(kuò)縮容，管理和監(jiān)控的問題，故事不是應(yīng)該大解決了嗎？為啥會出現(xiàn)Kubernetes這樣的平臺呢？如果沒有經(jīng)歷過Cloud Foundry那個時代的同學(xué)可能不會有直接的體感，我們在享受Cloud Foundry這樣應(yīng)用程序平臺帶來的好處的同時，同時也伴隨著和所選擇的應(yīng)用程序平臺綁定。比如我們在Cloud Foundry上部署了自己的核心應(yīng)用系統(tǒng)，那么我們就必須使用Cloud Foundry提供的服務(wù)發(fā)現(xiàn)機(jī)制，秘鑰管理機(jī)制，雖然說Cloud Foundry提供的這些輔助應(yīng)用程序運(yùn)行的機(jī)制可能和企業(yè)的規(guī)范和最佳實(shí)踐不符，但是我們除了接受改造自己的應(yīng)用之外，也別無選擇。
前文描述的場景就是大家熟悉的vendor lock-in，由于應(yīng)用程序平臺深度影響了應(yīng)用程序從架構(gòu)設(shè)計(jì)，開發(fā)到打包部署和運(yùn)行的各個環(huán)節(jié)，雖然說可以降低應(yīng)用程序開發(fā)部署的投入，但是同時也約束了應(yīng)用程序待多個平臺之間移動，特別是跨云部署已經(jīng)成為很多企業(yè)為了規(guī)避運(yùn)維風(fēng)險(xiǎn)的必選項(xiàng)。從Cloud Foundry遷移到阿里云對比阿里云在友商云之間遷移，很明顯后者會更加絲滑，雖然筆者堅(jiān)信在國內(nèi)阿里云是標(biāo)準(zhǔn)答案。
不過上文關(guān)于這幾個平臺的對比略顯粗略和業(yè)務(wù)，我們都知道能說服人的對比方式是找到核心的維度，把這些應(yīng)用程序平臺放到這個維度體系中進(jìn)行對比，來識別對于特定企業(yè)場景，孰優(yōu)孰劣。筆者在過往幾年的從業(yè)經(jīng)驗(yàn)中，總結(jié)出了如下圖所示的成熟度評估模型：
咱們來稍微解釋一下上邊這張圖，首先是兩個維度，工作量和生產(chǎn)成熟度，可以看到阿里云上的EDAS這樣的平臺無論是生成成熟度，還是企業(yè)需要付出的額外工作量（圖中并未直接體現(xiàn)這一點(diǎn)，因?yàn)槭前⒗镌频腜ASS服務(wù)，因此企業(yè)基本是開箱即用），都是最佳的選擇。
除了EDAS這樣的平臺之外，企業(yè)也可以自建Kubernetes集群，但是需要的開發(fā)和運(yùn)維工作會非常大，考慮到Kubernetes本身的復(fù)雜度以及涉及到的基礎(chǔ)設(shè)施，安全，存儲，網(wǎng)絡(luò)等功能。當(dāng)然企業(yè)也可以選擇阿里云ACK這樣的托管服務(wù)，阿里云的專業(yè)團(tuán)隊(duì)會幫助企業(yè)運(yùn)維管理節(jié)點(diǎn)（control panel），讓企業(yè)把有限的開發(fā)和運(yùn)維資源投入到如何在托管的環(huán)境中通過YAML文件或者腳本來部署應(yīng)用上，這種模式比起來自建Kubernetes集群來說，會節(jié)省巨量的系統(tǒng)搭建，運(yùn)維和升級的工作量。
不過在上圖中，筆者把自建Kubernets和使用托管的ACK服務(wù)歸為生產(chǎn)不ready象限，主要原因其實(shí)不難理解，Kubernetes非常復(fù)雜，具備生產(chǎn)能力的自建Kubernetes集群，即便是使用托管的ACK這樣的服務(wù)，都需要企業(yè)有相當(dāng)規(guī)模的開發(fā)運(yùn)維團(tuán)隊(duì)和技能儲備。
Cloud Foundry是一個非常成熟的應(yīng)用程序平臺，提供完整的應(yīng)用程序管理，監(jiān)控，運(yùn)維等能力，很多時候我們在CF上運(yùn)行程序其實(shí)更多的是如何讓開發(fā)的應(yīng)用程序符合CF定義的“規(guī)則”。OpenShift比起來自建Kubernetes集群更加的Production ready，但是使用OpenShift需要大量的配置和調(diào)優(yōu)，靈活性高的同時需要大量的運(yùn)維工作量，因此這種靈活性是好是壞，必須逐一而論。
基于上邊的分析，構(gòu)建于Kubernetes之上的應(yīng)用程序平臺對于企業(yè)來說會是更好的選擇，如果考慮自己搭建，會需要比較多的開發(fā)工作量，但是帶來的價(jià)值是和企業(yè)的企業(yè)高度匹配，兼容企業(yè)的基礎(chǔ)設(shè)施，安全規(guī)范，以及極強(qiáng)的靈活性和擴(kuò)展性。不過很少有企業(yè)能夠承擔(dān)這么重的開發(fā)工作量，因此比較實(shí)用的做法依然是使用阿里云提供的EDAS+ACK服務(wù)，在充分享用Kubernetes提供的現(xiàn)代化基礎(chǔ)設(shè)施能力之上，EDAS為開發(fā)和運(yùn)維人員提供了成本和復(fù)雜度的平衡。
因此嚴(yán)格意義上來說，圖1.1缺少了一個維度，也就是這些應(yīng)用程序開發(fā)平臺和企業(yè)的訴求之間的匹配程度的維度，如果咱們把這第三個維度給加上，結(jié)果就是下圖1.2所示的成熟度：
做過軟件開發(fā)的同學(xué)應(yīng)該都深有體會，定制化開發(fā)是最能滿足業(yè)務(wù)需求的一種方式，對于應(yīng)用程序平臺類似，從頭開始構(gòu)建一套應(yīng)用程序平臺是最能滿足企業(yè)的當(dāng)前以及長期訴求的方式，因?yàn)闃?gòu)建出來的東西是基于真實(shí)的訴求，或者企業(yè)真實(shí)的發(fā)展規(guī)劃來設(shè)計(jì)的。但是如果企業(yè)選擇基于Kubernetes來重新實(shí)現(xiàn)一遍EDAS應(yīng)用，雖然說技術(shù)上可行，但是為止付出的成本以及所承擔(dān)的風(fēng)險(xiǎn)，結(jié)果可能是得不償失。因?yàn)槲覀円紤]的東西太多了，并不是簡單的將應(yīng)用程序部署到Kubernetes集群上：
- 如何在企業(yè)的IDC基礎(chǔ)設(shè)施上運(yùn)行這個應(yīng)用程序平臺的同時，遵守公司和行業(yè)的各種規(guī)范
- 需要支持異構(gòu)的基礎(chǔ)設(shè)施，比如物理服務(wù)器，VSphere虛擬化平臺等
- 如何提供靈活性，來不光滿足當(dāng)前的應(yīng)用程序打包部署需求，也能夠滿足長遠(yuǎn)的部署需求
- 平臺需要提供較強(qiáng)的自動化機(jī)制，比如自動擴(kuò)展基礎(chǔ)資源等
- 平臺需要符合業(yè)界的規(guī)范，為跨云部署的未來場景做好技術(shù)支持準(zhǔn)備
- 如果應(yīng)用程序平臺部署在阿里云這樣的主流云平臺上，那么需要考慮和云平臺的集成度，盡量通過cloud provider提供的標(biāo)準(zhǔn)接口來實(shí)現(xiàn)資源的擴(kuò)縮容
上邊這些需求本質(zhì)上來自于企業(yè)的開發(fā)和運(yùn)維團(tuán)隊(duì)，無論我們打算構(gòu)建什么樣的應(yīng)用程序平臺，傾聽開發(fā)和運(yùn)維人員的聲音，特別是關(guān)于如何構(gòu)建，運(yùn)維和監(jiān)控應(yīng)用程序方面的訴求，是我們設(shè)計(jì)這個平臺以及選型的重要依據(jù)。另外我們也需要考慮企業(yè)開發(fā)和運(yùn)維的成熟度（你也可以稱作是Devops成熟度)，看菜吃飯是確保我們構(gòu)建出來的平臺能夠被接受的有效準(zhǔn)則。
通過上邊的描述，大家是不是對應(yīng)用程序平臺有了清晰的認(rèn)知？當(dāng)然沒有，因?yàn)橹杏袀€單詞叫tangile應(yīng)該很多同學(xué)都遇到過，就是要能得著，我們上邊的描述頂多是從2000米高空為應(yīng)用程序平臺做了一下畫像而已，具體這個平臺長啥樣對很多同學(xué)來說應(yīng)該還是模糊的。那么如何解決這個問題呢？我們有兩個選項(xiàng)，讀者如果想馬上有東西可以用，明天就要給老板匯報(bào)如何基于Kubernetes來承載企業(yè)的核心業(yè)務(wù)系統(tǒng)，筆者建議大家直接在阿里云上開通EDAS+ACK服務(wù)，因?yàn)檫@是到目前為止最可靠和強(qiáng)大的容器化部署和運(yùn)維應(yīng)用程序管理平臺。
讀者如果想先了解一下這個應(yīng)用程序平臺具體應(yīng)該包含哪些內(nèi)容，涉及到哪些組件，以及如何基于Kubernetes來從零開始構(gòu)建（當(dāng)然也不必是完全要從0開始，我們能高效使用一個工具的前提是，必須對這個工具有深入的了解），那么可以繼續(xù)閱讀筆者后續(xù)的文章。咱們后邊會從Kubernetes擴(kuò)展和定制化開發(fā)的角度，來看看構(gòu)建這樣的一個類似于阿里云EDAS的平臺，具體需要考慮哪些事情，筆者特別想扭轉(zhuǎn)的現(xiàn)狀是：把大家從我如何部署一套Kubernetes平臺的思路牽引到從開發(fā)者的角度看，企業(yè)的開發(fā)流程，工具，痛點(diǎn)和運(yùn)維層面訴求具體是什么？
通過將關(guān)注點(diǎn)移動到具體的問題，我們就可以有足夠的信息來從邏輯上支持我們到底是選擇阿里云的EDAS+ACK還是自己基于Kubernetes來構(gòu)建輕量級的PAAS平臺。因?yàn)閷τ谄髽I(yè)來說，無論哪種選擇，都需要解決基礎(chǔ)設(shè)施，安全，合規(guī)性以及擴(kuò)展性等方面的實(shí)際需求，確保整個平臺的最終用戶（B端或者C端，業(yè)務(wù)線），以及直接用戶（開發(fā)和運(yùn)維）的需求能夠得到滿足。我們需要極力避免的是構(gòu)建一套強(qiáng)大的的平臺，而不是合適的平臺。咱們整個生產(chǎn)化之路的第二篇文章通過下圖來收尾：
如上圖所示的漫畫，開發(fā)人員需要良好的端到端應(yīng)用部署和運(yùn)維監(jiān)控體驗(yàn)，如果只解決了部署這一個問題，開發(fā)人員需要考慮高可靠，微服務(wù)治理，監(jiān)控等諸多需求。就如同汽車一樣，雖然說汽車由1萬多個零件組成，我們都可以在市場上買到，但是我相信給你一個汽車引擎和結(jié)果輪子，你應(yīng)該不會自己很快能弄出一個可以開的汽車，并且在80公里的時候不散架：）。
好了，今天這篇文章就這么多了，咱們下篇文章會基于EDAS的具體實(shí)現(xiàn)方式，來詳細(xì)介紹一下如果我們要自己實(shí)現(xiàn)一套基于Kubernetes的應(yīng)用程序管理平臺，我們應(yīng)該大體上怎么做，目的當(dāng)然不是鼓勵大家自己開發(fā)EDAS這樣的產(chǎn)品，而是通過這些原理層面的介紹，讓大家有足夠的技術(shù)深度，來掌握EDAS的使用，通過EDAS+ACK為企業(yè)數(shù)字化轉(zhuǎn)型堅(jiān)定堅(jiān)實(shí)的PAAS基礎(chǔ)。
