【51CTO.com快譯】云原生計算可以將行業領域驅動的設計、GitOps和其他現代軟件最佳實踐匯總起來，如果企業實施得當，可以減少技術債務。
云原生計算是企業IT的一種新范式，它涉及現代技術的方方面面，從應用程序開發到軟件架構，再到保持一切運轉的底層基礎設施。
云原生為企業提供了清理技術債務的機會。例如通過Kubernetes這樣的“掃帚”，掃除現有技術的一些積滿塵土的角落。因此，假設云原生最終會消除多年來累積的技術債務是合乎邏輯的。
這也許合乎邏輯，但并不現實。眾所周知，技術債務將長期存在。此外，對于任何一位首席信息官來說，寧愿將IT預算花在新技術和新事物上，也不愿將其浪費在清理前任留下的爛攤子上。
然而人們也有理由對云原生抱有希望。雖然云原生不是一把神奇的“掃帚”，但其核心實踐確實可以幫助企業減少技術債務，并提供新的軟件功能，而不會產生更多的債務，至少不會像以往那樣產生更多的債務。
讓企業清除技術債務以便永遠不會產生新債務，當然是難題的一部分，但更直接的問題是如何償還現有的遺留技術債務。
多年來，便利的快捷方式、笨拙的編碼，以及基礎設施中各種各樣的接口，已經形成了一團亂麻。而對于這個難以解決的問題，可能需要采用“快刀斬亂麻”的措施。
云原生計算就是這樣的一把快刀：基于領域驅動設計的架構重構。領域驅動設計要求將復雜的企業軟件挑戰分解為單獨的業務領域，每個領域都有一個“限界上下文”。
限界上下文可以根據業務需求限制上下文來解決諸如“客戶”或“發票”之類的業務。例如，大型企業的不同部門可能對客戶有不同(可能有所重疊)的概念。每一個都代表一個單獨的限界上下文。
早期對微服務架構的探索導致了互聯微服務的激增，其復雜性限制了其可擴展性，并且很快顯現出來。而通過限界上下文組織它們是管理這種復雜性以及大規模交付基于微服務的解決方案的關鍵。
因此，領域驅動設計已經成為云原生計算的一部分，此外，它告訴人們必須如何按照這種新范式來實現遺留資產的現代化。
解決具有高技術債務的遺留軟件挑戰的第一步是應用架構重構，從而將遺留架構轉換為具有限界上下文的模塊化元素。換句話說，企業必須遵循業務驅動的限界上下文引入模塊化，以便引導減少技術債務的路徑。
而魔鬼在細節中。根據企業面臨的業務需求和遺留挑戰，可以通過以下幾種方式來利用這種架構重構：
- 可能會發現限界上下文中的現有代碼根本不符合當今的要求。在這種情況下，可以將該代碼重寫為微服務。
- 遺留業務邏輯仍然具有價值，然后將其遷移到微服務。
- 可以將遺留模塊作為API公開，因為它們已經具有有用的API，或者因為更新了遺留代碼以通過API公開它。
- 可以使用機器人流程自動化(RPA)程序編寫與舊模塊交互的腳本。
需要注意的是，由于之前已將遺留軟件重新組織和模塊化為限界上下文，因此上述四種方法中的每一種都比其他方法更加簡單。
此外，如果有必要的話，未來的重構也會更加直接，因為采用了“分而治之”的方法來劃分技術債務。例如，隨著時間的推移，企業還清四筆較小的技術債務比一筆大的技術債務更加輕松。
這種方法也是減少機器人流程自動化(RPA)脆弱性的最佳方法之一。如果沒有限界上下文驅動的架構重構，那么應用程序環境中的任何地方發生任何變化，此類機器人程序就會崩潰。通過適當的劃分，此類故障將更易于管理且更易于修復。
防止新的技術債務
防止新的技術債務就像要求保持房間整潔一樣，雖然也許會保持一段時間，但到后來將會變得一團糟。
需要的是更多的結構，對嗎?至少在云原生的情況下，這種結構確實有幫助。
云原生計算提供了一系列廣泛的最佳實踐，描述了如何最好地構建軟件、配置基礎設施、創建和部署應用程序以及管理生產中的一切。
當然，如果遵循所有這些建議，就不太可能背負新的技術債務，或者至少不會那么快地出現技術債務。
“基礎設施即代碼”(IaC)原則就是一個關鍵示例。IaC原則指出，工作人員不應在生產中弄亂服務器。 IaC原則當然可以限制生產中的額外技術債務，因為它提供了一種解決生產問題的主動方法。那么只有一個問題：IaC做得還不夠。
IaC的問題在于必須編寫各種程序。然后，必須像任何其他程序一樣對這些程序進行測試、管理和版本控制——這意味著技術債務可能會像任何其他軟件一樣蔓延。
幸運的是，云原生計算已經超越了IaC，其中每一步都比之前的一步有所改進。
- 第一步：通過聲明性配置來表示基礎設施，它指定應該如何配置基礎設施，而不指定如何實現此類配置。
與IaC相比，聲明式方法減少了技術債務，因為沒有太多的空間來使用快捷方式，但這些表示(通常出現在YAML文件或其他基于JSON的格式中)仍然非常像代碼，尤其是對于復雜的動態基礎設施配置。
- 第二步：GitOps。GitOps為軟件發布和管理帶來了以Git為中心的實踐和流程。
GitOps在許多方面補充了基礎設施配置的聲明式方法，因為它采用聲明式方法進行軟件部署。GitOps通過為其流程提供更多結構而更進一步，而結構越多，技術債務蔓延的機會就越少。
- 第三步是當前最先進的技術：基于意圖的計算。
基于意圖的計算包含三個部分：
- 以技術策略的形式對相關軟件(基礎設施、應用程序代碼等)的聲明性表示。
- 這種技術策略的抽象，如表示底層配置的業務意圖的業務策略。
- 確保底層軟件符合這一業務意圖的一種機制，從而在策略應用中消除策略漂移。
換句話說，基于意圖的計算采用聲明式配置方法和GitOps，并添加額外的結構，從本質上確保整個云原生環境隨著時間的推移符合業務意圖。
這樣的合規性才是一把斬斷技術債務這團亂麻的最好的快刀。
文章標題：Can Cloud-Native Computing Eliminate Technical Debt?，作者：Jason Bloomberg
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
