大資料實用DevOps/未來挑戰
儘管本書為軟體工程中的實用DevOps提出了具體解決方案，但不可避免地，本書無法詳細介紹DevOps和軟體系統開發中的一些新興主題。在本節中，我們將討論該領域中兩個新興的挑戰，這些挑戰可能會催生新的工業和學術研究工作。
在整本書中，我們都專注於開發依賴大資料處理技術的企業IT應用程式。然而，我們並沒有詳細介紹設計和維護大資料應用程式資料饋送管道的問題。這個問題通常屬於資料工程專家的職責範圍，涉及到大資料應用程式收集的資料的獲取、過濾、分析和儲存。特定的架構正在逐漸出現，例如資料湖的概念，它將組織的所有異構資料集整合到一個儲存位置，而資料工程師最近認識到需要採用DevOps風格的方法來發布和更新資料管道中涉及的程式碼。
舉個具體的例子，一組團隊合作開發業務分析管道，也需要測試、更新和釋出新的資料查詢和統計分析，就像軟體工程師釋出應用程式或其組成元素的新版本一樣。這種新興趨勢被稱為DataOps，它帶來了新的研究挑戰，例如決定DevOps中哪些方法可以應用到這個領域，或者確定DevOps和DataOps方法是否可以在同一方法中共存。質量驅動的工程方法在DataOps領域提出了嚴峻的挑戰，因為需要保證資料隱私和資料完整性，這需要專門的方法進行測試。
新興的行業趨勢，如微服務，正在提出將DevOps擴充套件到支援交付分解成細粒度且獨立部署的服務（稱為微服務）的雲應用程式的問題。微服務在許多方面不同於傳統的Web服務
- 微服務是精益的，這意味著傳統的Web服務可以公開許多API，而微服務通常只實現一個或很少幾個功能。此外，微服務通常基於輕量級的REST/JSON通訊，而不是Web服務中常見的SOAP/WS-*堆疊。
- 接下來，微服務旨在專門對映到單個開發團隊，以便每個團隊可以獨立於其他團隊釋出該服務的最新版本。這意味著，除其他事項外，每個團隊都可以以去中心化的方式管理自己的資料，從而使應用程式架構擺脫共享資料庫，從而促使定義新的架構範例以及新的方法來確保可用性、一致性和檢查點。微服務的另一個重要特性是
- 最後，也許是最重要的，微服務旨在利用容器化的優勢，例如，能夠自動擴充套件服務。這帶來的一個後果是，當微服務變得非常細粒度，以至於等效於應用程式程式碼中的單個函式呼叫（稱為奈米服務）時，實際上可以自動擴充套件應用程式程式碼的部分，以犧牲效能來降低擴充套件成本。
顯然，微服務的上述特性使它們與基本企業應用程式有很大不同，並且它們需要DevOps朝著去中心化實踐的方向發展，每個團隊都擁有用於在交付到生產環境之前推理應用程式更新的工具。開發用於微服務去中心化軟體工程的支援工具，並推理如何將應用程式架構分解成適當大小的服務，是未來幾年最緊迫的研究挑戰之一。