實現雲原生應用程式可移植的夢想

將一個應用程式從一個地方移動到另一個地方聽起來很簡單：把它拉起來，運送過來，然後解壓。這有什麼難的?

這種簡單的想法可能描述了虛擬機器(VM)時代的應用程式可移植性，當時對整個卷的成像捕獲了移動應用程式所需的一切。

然而，在雲原生世界中，並不是那麼簡單。

組織希望從雲原生應用程式的可移植性中獲得什麼?為什麼它這麼難?最重要的是，你如何做對?

為什麼我們要雲原生應用程式的可移植性?

想要移動雲原生應用程式有幾個原因：

——熱備份。一個組織可能希望在兩個不同的雲中執行一個雲原生應用程式的實時副本，或者在內部和雲中執行，以便在發生故障時能夠快速地將流量從一個切換到另一個。

——多雲負載均衡。如果一個組織要執行熱備份，它還可以在應用程式例項之間劃分實時流量。這種方法還避免了“所有雞蛋放在一個籃子裡”的問題，只要應用程式例項在單獨的雲中執行。

——部署到新環境。在某些情況下，生產部署遵循GitOps實踐，基本上是在不斷、零碎的基礎上進行更新。在其他情況下，一個組織可能希望將整個應用程式作為一個單元從開發遷移到staging或staging到生產(或者可能遷移到其他環境，如金絲雀或a/B測試部署)。

——出於業務原因切換雲。許多組織從一個雲轉移到另一個雲以節省資金，或者可能是因為與提供商發生衝突。其他則從雲轉移到內部部署，因為在某種程度上，內部部署更具成本效益。

為什麼雲原生應用程式的可移植性如此困難?

仔細看看雲原生應用程式意味著什麼，就會明白許多挑戰很快就會出現：

——在Kubernetes上執行的應用程式不是單體的。它們包括短暫的微服務以及配置和資料。此外，這些元素可能不都駐留在同一個VM上。移動它們就像用叉子移動沙子。

——微服務通常是無狀態的，而Kubernetes以抽象的方式處理持久化資料。與資料庫連線是顯式的三層應用程式不同，雲原生應用程式透過抽象連線的operator訪問持久資料和其他狀態資訊。瞭解特定時間哪些資料與哪個應用程式一起使用可能很棘手。

——快照通常是短暫的。建立卷級快照是加快卷級遷移的一種通用方法。雖然Kubernetes支援這樣的快照，但它們通常是短暫的，因此不能保證應用程式的一致性。

如何實現雲原生應用程式的可移植性?

幸運的是，Kasten by Veeam等供應商提供的現代資料保護解決了上述挑戰。Kasten是這樣做的：

——自動發現和遷移所有Kubernetes元件、配置和資料。與其採用以卷為中心的方法，不如採用以應用程式為中心的方式來解決Kubernetes的分散式和短暫性。

——支援跨名稱空間、叢集、區域、雲和Kubernetes發行版的可移植性。理論上，Kubernetes在一個位置和另一個位置的執行方式相同。然而，在實踐中，雲提供商和Kubernetes發行版之間存在許多細微的差異。抽象和解決這些差異至關重要。

——強調大規模資料的可移植性。對於應用程式一致的雲原生可移植性，恢復、克隆和升級資料以及將資料從一個位置遷移到另一個位置至關重要。此外，大規模處理這些複雜問題很重要。

——雲原生應用程式可移植性功能應該是其資料保護專業知識的延伸。應用程式和資料的備份和恢復是資料保護的核心。因此，可以將計劃內的應用程式移動性視為在突發和意外故障後應用程式恢復這一更為困難的問題的特例。

業務連續性是成功實現應用程式可移植性的關鍵，正如應用程式備份和恢復一樣。在某些情況下，在移動應用程式之前關閉它當然是有意義的。在其他情況下，應用程式在遷移完成之前不會收到實時流量。

但在更一般的情況下，組織需要在應用程式執行時移動應用程式的能力，而活動工作負載當前正在處理事務，底層資料也在不斷變化。

在這種情況下，應用程式的可移植性就像在開啟電源的情況下重新佈線一樣——一個錯誤的動作就會導致死亡。

市場上大多數雲原生應用程式可移植性方法本質上都是Day Zero技術——在實現任何功能之前處理應用程式遷移。

另一方面，Kasten構建了其技術來處理正在執行的應用程式的備份和恢復，其中跟蹤正在進行的事務狀態非常重要。

這一功能對於大多數雲原生應用程式可移植性場景來說是必不可少的，因為組織希望其雲原生應用始終處於執行狀態——不僅僅是在一個虛擬機器上，而是跨虛擬機器和雲，並根據需要進行上下擴充套件。

換句話說，雲原生應用程式的可移植性可以在第2天(完全生產)實現，而不會有觸電的風險。