大資料實用DevOps/總結

本書的動機在於解決當今組織在開發大資料系統時面臨的問題。如今，大多陣列織面臨著巨大的市場壓力，其支援的 ICT 部門正在努力加速應用程式和服務的交付，同時保持生產和運營穩定。一方面，ICT 運營人員缺乏對應用程式內部結構的瞭解，包括系統架構和架構元件背後的設計決策。另一方面，開發團隊並不瞭解運營細節，包括基礎設施及其侷限性和優勢。對於大資料系統來說，這些問題甚至會被放大。對於這些系統，近年來，對使用資料密集型技術的興趣迅速增長，例如 Hadoop/MapReduce、NoSQL 和流處理。這些技術在許多應用領域中都很重要，從預測分析到環境監測，再到電子政務和智慧城市。但是，此類應用程式的上市時間和擁有成本相當高。

本書解釋了 DevOps 實踐如何解決開發和運維之間常見的隔離問題。我們說明了 DICE 方法，這是一種用於大資料系統軟體工程的實用方法，利用設計工件（如 UML 和 TOSCA 模型）可以發揮核心作用，在組織內組織架構和需求知識，並在 DevOps 工具鏈的設計時和執行時工具之間共享。與商業上提供的多數 DevOps 工具相反，這些工具將重點縮小到持續整合和持續交付，因此 DICE 實現了一種更雄心勃勃的 DevOps 形式，其中 Dev 和 Ops 的統一不限於交付階段，而是應用程式開發的整個生命週期，開發人員和運營人員都依賴於模型來執行其活動。透過擁有涵蓋整個應用程式生命週期的 DevOps 工具鏈，包括將生產監控資料反饋給設計師和開發人員，所提出的 DevOps 方法促進了由量化監控資料驅動的應用程式的迭代增強。

我們在定義 DICE 方法過程中學到的經驗之一是，不同的參與者對模型應該發揮的作用有截然不同的期望。設計師將模型視為其工作中的核心要素，因此他們會發現使用模型驅動工程工具是自然的。對於大多數運營人員來說，情況並非如此，他們使用更接近作業系統和系統管理思維方式的抽象概念。單獨來說，如果模型以文字形式呈現，例如在 TOSCA 編排和拓撲模型的情況下，運營人員往往會很輕鬆地使用它們。這種明顯的矛盾表明，儘管 DICE 之類的 методология 可以完全基於模型，但在幕後，重要的是工具鏈中不同參與者需要不同程度的模型暴露，以便他們能夠輕鬆地使用他們使用的工具。解決 Dev 和 Ops 之間的這種文化差異實際上是交付健全 DevOps 方法的主要挑戰之一。我們相信，本書中提出的 DICE 方法是開發資料密集型應用程式的方法的第一個例項之一，它試圖系統地解決這個問題。