Apache Mesos為什麼會失敗？（駭客新聞）

banq發表於2021-04-15
Apache

Apache Mesos因與K8s競爭失敗而將被Apache基金束之高閣，駭客新聞網友總結幾個失敗教訓：
1. k8s是吸取了Google十多年來在建立此類系統的所有經驗和知識。Mesos由研究學生髮起，後來他入職Twitter，但負責該專案的工程師（包括我本人）沒有建立叢集管理系統的經驗。（banq注：開源的大坑就是學生用它來學習的）
 
2. 大多數使用者只想執行服務，作業和Cron作業，但這不是Mesos的一部分，您必須從一系列的生態系統排程程式（例如Aurora，Marathon，Chronos，Singularity等）中進行選擇，或者自己建立一些東西。
 
3.  Mesosphere是一家由VC支援的創業公司，在Twitter之後推動了該專案的發展。作為風險投資支援的初創企業，您需要一種可以產生收入的業務模型。這導致與使用者和其他供應商的緊張關係和不信任感。與此相比，Google / k8s不需要直接從k8s產生收入，而是可以投入大量資金和強大的工程師，以提高谷歌的雲端計算業務。
 
4.如果您檢視原始論文，Mesos的兩級資源分配最初是為執行批處理工作負載（例如，spark，mpi等）而設計的。用它來執行長期執行的服務實際上是事後的想法。最終我們發現，鑑於第二級排程程式沒有群集的完整檢視並且第一級排程程式沒有足夠的資訊來做出正確的決策，我們必須對第一級排程演算法進行大量調整以確保公平性。k8s的排程模型是，排程程式能夠看到叢集的整個狀態，因此可以樂觀地制定最佳的排程決策，尤其是對於那些在實踐中非常挑剔的長期執行的作業。儘管預設情況下k8s僅執行預設的排程程式，但理論上您可以並行執行多個排程程式（omega模型）。
 
5.k8s成功的另一個原因可能是因為golang生態系統。在Mesos中，由於Mesos獨特的執行緒模型，我們花費了大量精力在C ++中構建基本的HTTP層。我希望我們可以將那些時間花在開發實際有用的功能上。
 
6.這不是關於Apache，而是關於Mesosphere的商業開源失敗的開放治理。Apache Spark，Apache Beam，HBase等並非如此。Mesos（以及伯克利AMPLab的許多其他工作）背後都有令人生畏的想法，並且它的實現優雅，其實現遠遠超出了Kubernetes的目標。Kubernetes應該是Mesos的排程程式，而Google對此進行了投資。雖然我不知道Kubernetes成為排程程式和資源管理器的確切原因，但我認為這也與Mesos專案的管理密切相關。
 
7.在體驗Kubernetes之前，我曾使用Mesos數年，我與許多Mesos專案成員和提交者一起工作，並與他們互動，儘管他們通常都是聰明的人，但他們的行業經驗令人驚訝地膚淺。根據我的經驗，Mesos經常更改，並且在生態系統邊緣存在足夠多的未知TBD成分，使其有些不穩定。在一年之內，Kubernetes處於領先地位，Mesos開始考慮轉向支援k8s。
 
8.我不認為它從一開始就註定要失敗。Mesos甚至在k8s發行之前的4年就已在Twitter上部署。Mesos的“問題”在於，它專注於從未成功的未來。Mesos的“殺手級應用”是Spark，他們專注於解決的問題是批處理作業的資源分配。Mesos被認為是YARN的替代品。甚至事實上的應用程式啟動程式Marathon也被認為是“元框架”。Marathon不是用於啟動服務，而是用於啟動自定義框架。當Mesosphere決定使Marathon儘可能具有專有性並將其完全整合到他們的商業解決方案中時，就停滯不前了。
 
9.我們一直在生產中使用Mesos，直到2020年（從2018年開始過渡到Kubernetes），此評論的準確性令人難以置信。Mesos是一個有趣的專案，但是預設值對於生產環境而言太幼稚了。
 
10.我更喜歡Mesos，而不是k8s。我認為它的核心體系結構（2級排程程式）是更好的基礎。在最長的時間裡，我覺得k8s實際上是一個雜草叢生的業餘愛好專案。
當Rails出現時，它也是一個業餘專案。當來自更成熟的企業Web框架時，Rails感覺像一個玩具。它不具備“適當”框架的功能，健壯性，安全性和可伸縮性。
Rails做了什麼？它很容易上手，並且隱藏了許多Web框架的無聊和痛苦的工作。
透過龐大的社群的意志力，Rails成長了起來，變得更像是最初的玩具。起初，我對Rails社群的看法非常傲慢，但是後來我多年來從事了多個Rails專案。
它仍然隱藏著很多東西，可以說仍然有更好的技術框架，很多人在不需要的時候不正確地使用它，並且沒有真正地瞭解基本原理，這意味著當他們遇到麻煩時，他們往往會陷入困境。突破極限或走出發展的黃金之路。
我對k8s也有同樣的感覺。我認為它開始時幾乎沒有類似框架的功能。它的伸縮性不好，模型過於簡單，實現起來過於複雜。但這比Mesos之類的方法要容易得多，並回答了“我為什麼要對所有內容進行容器化？”的問題，這為那些開始使用Docker的人們提供了一個目的。現在，它擁有巨大的支持者和支持者。
至此，我瞭解到流行的不一定是“正確”或“正確”的體系結構。程式設計趨勢（和流行趨勢）還遠遠不止這些。整個行業似乎都想每十年重新發明輪子，幾乎就像某種計劃過時的方法來證明我們的工作是合理的。然而，與潮流抗爭並不明智，而且當您有足夠的行業方向發展時，我們甚至可以將玩具變成真正的工具。
 
11.Mesos為分散式資源管理做出了許多新的貢獻。資源提供和應用程式整合可以提高群集利用率和效率。為應用程式提供參與資源分配和排程的機會類似於Exokernel設計，並導致了許​​多有趣的中介軟體體系結構。
Mesos還引入了“主導資源公平性”（Dominant Resource Fairness），用於將資源分配給競爭應用程式，這已成為CS中的一個重要概念，尤其是計算經濟學本身。
Mesos實現了將CS研究用於廣泛部署的作業系統的罕見組合。它的C ++程式碼很容易理解和破解，並且似乎是您可以/希望“在幾天之內”重新實現的那些專案之一。
令人遺憾的是它很快過時了。
 
12.公平地說，Kubernetes現在僅排程相對較小的叢集。但是事實證明，世界上大多數地區都不是Facebook或Google，而只需要相對較小的叢集。
 
13.我們使用Mesos作為我們的第一個容器編排堆疊。它可以正常工作，但是Kubernetes出現了，併為所有問題提供了一站式解決方案。在Mesos中，您必須將單獨的專案用於容器管理（Marathon），可發現性（Consul / HAPROXY）。它似乎更適合希望為此類任務執行自己的堆疊的人。對於中小型操作，很難解決這些問題，而實際上這是每個執行一堆容器的人都遇到的問題。這是在2014年，所以還早，但k8滿足我們需要的一切。
 
14.一個時代的結束...
除了Kubernetes和Nomad，還有其他可行的選擇嗎？
 
15.Mesospehere已重新命名，並已轉移到支援Kubernetes。https://d2iq.com/blog/mesosphere-is-now-d2iq

如何做出重大技術路線決策？

 

相關文章