對于許多組織來說，一個日益增長的趨勢是DevOps團隊支持業務目標和戰略。在這種軟件開發重點的轉變中，開發團隊在差異化服務產品甚至顛覆、最終改變行業方面發揮著關鍵作用。

因此，應用程序架構師不太關心封裝在單體應用程序中的大規模工作流。今天的問題通常圍繞著DevOps團隊必須做些什么來實現所需的敏捷級別（通過大規模使用云原生平臺有節奏地部署軟件）——這在不久前是聞所未聞的。

得益于敏捷實踐和全新的云原生基礎設施，開發團隊可以每天部署代碼幾次，而不是每幾個月（甚至更長時間）部署一次。

云本原生應用程序開發的好處

與使用傳統的、單體的應用程序開發實踐所開發的應用程序不同，云原生應用程序由于其多功能性，可以更小、更靈活，并且容易與其他應用程序和服務集成。許多開發人員還可以開發屬于更廣泛生態系統的應用程序或服務。

目標是使部署持續的快速和健壯。最終的測試是，這些敏捷部署是否能夠在規模上滿足最終用戶的需求，并且比競爭產品更好。在無狀態容器環境中快速一致地部署數據和網絡時，可能會出現無法預見的問題，因此，組織必須優先考慮在云原生世界中高效地管理和擴展數據和網絡。

管理容器中的持久存儲

筆者經常發現，組織在進行云原生遷移時面臨的一個主要障礙是如何在暫態的容器環境中管理有狀態應用程序的數據。

在為云原生架構開發和部署軟件時，開發人員必須始終了解他們創建和分發的代碼將如何在組織的運維中進行交互。容器和微服務為開發人員提供了難以置信的部署通用性。由于底層架構的無狀態性，它們可以立即擴展和減少代碼部署。然而，當涉及到數據放置時，維護數據持久性、穩定性和安全性可能會帶來挑戰，特別是當應用程序架構師使用可能存在于多個位置的代碼和微服務時。

在最初使用容器的新興DevOps環境中，一個簡單的策略可能是為其CI/CD管道、Git存儲庫或應用程序附加一個網絡文件系統（NFS）。盡管如此，正如我們將在下面看到的，數據可移植性、彈性和動態供應/取消供應可能會變得繁瑣和不合標準。使用不可共享且具有潛在故障點和數據安全威脅的專有云存儲基礎設施，可能會出現類似問題。

簡言之，在云原生之旅開始之前，擁有一個持久存儲層可以避免麻煩和回溯。

持久存儲應該如何工作

解決無狀態環境中應用程序開發和部署的持久存儲難題的一種方法是采用與容器平臺集成的存儲層。

當開發人員使用Kubernetes編排器使他們更容易為項目創建資源時，理想情況下持久存儲層應該由動態存儲平臺組成。開發人員應該有信心，存儲層也會符合應用程序部署的數據安全性和彈性要求。

通過一個可行的軟件定義的存儲平臺，開發團隊可以動態地定義和調整項目的數據需求，而不是使用NFS掛載手動完成此過程。而且，他們不需要依賴存儲管理員來提供存儲，他們可以根據需要更改存儲配置。

同樣，對于以塊協議（如SQL或NoSQL數據庫）存儲數據的應用程序，一些組織可能傾向于采用服務提供商的專有解決方案。但是，這樣會限制跨不同的多云或區域提供存儲可用性的能力，并且會將開發人員鎖定到單個提供商的解決方案中。

開源軟件定義的存儲允許跨許多不同類型的基礎設施（包括裸機、虛擬機以及公有云和私有云環境）進行持久和可移植的存儲。數據聯合可以跨混合和多云環境進行，因此開發人員可以根據需要放置敏感數據，并集成來自各種多云部署的應用程序和微服務。

對于人工智能（AI）和機器學習（ML）等大規模分析應用程序，數據科學家通常必須管理來自多個位置和設備的大量數據增量。另一個例子是來自邊緣設備和物聯網資源。必須在整個數據生命周期中無縫地提供從設備邊緣到遠程staging，再到核心系統的數據聚合和分發。通常，不同類型的事件需要不同的存儲協議，從對象到塊再到文件。持久存儲層功能必須可用，以處理這些非常動態和多樣化的存儲需求。

最終，開發團隊必須能夠依靠一個標準化的平臺，通過一個單獨的API，在經常是多樣的、要求很高的環境（包括多云、裸機和虛擬機）中自動化存儲管理。當開發人員需要根據需要縮減或重新部署時，存儲層還應提供顯著的故障轉移優勢。它還需要非常靈活，因此，開發人員可以通過提供幾乎零延遲來定義他們需要什么。

云原生持久存儲提供了這些功能，并為DevOps團隊帶來了顯著的靈活性和可移植性。它可以為云原生環境中的軟件部署提供靈活性，同時使開發人員能夠自由地管理自己的存儲需求。

責任編輯：ct