概述
最近看了很多關於雲原生的文章，大體意思是機器學習服務這個行業將迎來一次巨大的變革。從13年我剛入行以來，機器學習在15年左右經歷了模型深度的變革，從淺層學習逐步發展到了深度學習。到了20年這個節點，機器學習的整體服務架構會開始變革，逐漸會從Apache Yarn體系向Docker+Kubeflow這種雲原生體系變革。
為什麼會出現這種遷移？許多技術同學都在網上發表了他們的看法，我認為比較好的文章是：https://www.jiqizhixin.com/articles/2019-01-31-14
遺憾的是，發表這些文章的都是技術同學，更多地是從技術視角去看待這個問題，今天我嘗試通過產品經理的視角，也就是使用者具體應用的視角解釋下雲原生的好處。
什麼是雲原生？可能有的同學不清楚什麼是雲原生，Docker+Kubeflow就是機器學習的雲原生方案。首先給大家解釋下Docker和VM（虛擬機器）的區別。
VM是目前所有“雲”業務的根源，VM的誕生使得傳統的物理機可以向外提供標準化的計算服務。這種服務需要使用者把應用App、依賴Bins/Libs以及作業系統Guest OS打包成VM映象，然後發到物理機上即可執行。
VM的一個問題就是因為VM映象包含了Guest OS，所以VM是比較重的，可能每個VM映象在10G左右，如果想同時拉起上千個任務，這個拉起時間成本非常高。
再來看看Docker，Docker的一個好處是不包含Guest OS。使用者只需要把應用App和Libs打包成一個Docker Image就可以部署到伺服器上，而且一樣具備VM所具有的資源隔離、網路隔離等優勢，這就靈活了許多。看下Docker的架構圖：
舉個例子，比如做一個簡單的模型服務，只需要把模型+Flask+python環境打包好即可，如果模型不大的話，這種Docker image只有幾百兆，可以秒級拉起。所以雲原生給到使用者的是彈性的計算環境，只要使用者把自己要計算的業務封裝成Docker image，傳上來就能跑。
雲原生究竟有哪些優勢雲原生有資源排程更靈活，記憶體、網路隔離更完善等優點，這些都是技術優勢，我今天重點介紹兩個使用者使用端的優勢。分別是“更靈活的配置性”以及“業務模組的一致性”。
1.更靈活的配置性
傳統的機器學習平臺的架構是如下圖這種模式：
在使用者層只給客戶開放了APP的上傳通道，而計算框架和依賴包需要平臺層提前在叢集配置好，而且不易更改。這會造成很大的麻煩，比如使用者上傳了一個python的程式碼包，這個包依賴於numpy這個python庫，如果平臺層沒有內建numpy，使用者是無法執行的，因為平臺並沒有給使用者開放安裝依賴包的口子。基於傳統的Yarn排程的模式，在技術可行性方面也比較難實現使用者自己在叢集層面安裝依賴。
反過來看雲原生的平臺，使用者可以在使用者層自己指定依賴的lib包，設定可以安裝計算框架。從使用者開發環境的角度比較，雲原生的機器學習平臺一定是更user friendly。
2.業務模組的一致性
我們知道，傳統的Apache Yarn，設定整個Hadoop生態是基於大資料開發為業務背景去設計的。相比於機器學習建模，大資料開發場景相對會更單純。因為大資料開發環境的輸入和輸出都是表。而機器學習場景輸入的是資料，輸出的是模型，模型還要部署成服務才可以使用。基於這樣的體系，會產生以下這種機器學習架構，
大部分玩演算法的人會把模型計算引擎和模型服務引擎解耦，甚至時間長了，覺得這兩個部分就應該是不同的模組。基於這樣很割裂的架構，會衍生出模型傳遞網路效能問題、引擎間模型格式不相容等一系列問題。
有了雲原生方式，會打破了Apache傳統的以大資料方式建模的束縛。所有的建模相關的服務都可以做出Docker Image，部署到一個叢集中，通過kubeflow的pipline去編排相互執行順序。
這樣就解決了上述提到的問題，讓整個業務都可以集中在一個叢集，同時相互之間又有資源隔離機制，使得業務模組一致性更強。
總結經過這幾天研究雲原生機器學習業務的調研，我覺得kubeflow未來可期，需要所有從業的產品經理和開發人員重新更新自己的技術棧。
有一個問題需要時間驗證，機器學習PaaS層產品是否是偽命題？
目前百度、阿里、騰訊都有PaaS層的機器學習產品，這些產品在雲原生時代是否還有價值。因為雲原生階段會大大推動開源生態各種模型部署、演算法框架的演進，使用者完全可以利用這些開源的工具配合Docker在虛擬機器上拉起來構建一個機器學習PaaS層服務，這樣的話Yarn那一套有點落伍。
未來可能在機器學習領域，只存在SaaS業務層和IaaS計算資源層，PaaS的比重會下降。這是我的一個猜測，作為PaaS層機器學習產品經理，==！好擔心自己會失業。