クラウドネイティブコンピューティングは技術的負債を排除できますか?

[[415169]]

[51CTO.com クイック翻訳]クラウドネイティブコンピューティングは、業界主導の設計、GitOps、その他の最新のソフトウェアのベストプラクティスを統合することができ、企業が適切に実装すれば技術的負債を削減できます。

クラウドネイティブコンピューティングは、アプリケーション開発からソフトウェアアーキテクチャ、そしてすべての稼働を維持する基盤となるインフラストラクチャまで、現代のテクノロジーのあらゆる側面に関係するエンタープライズ IT の新しいパラダイムです。

クラウドネイティブは、企業に技術的負債を解消する機会を提供します。たとえば、Kubernetes のような「ほうき」を使用すると、既存のテクノロジーのほこりっぽい隅々まで掃除することができます。したがって、クラウドネイティブによって、長年にわたって蓄積された技術的負債が最終的に解消されると考えるのは理にかなっています。

これは論理的かもしれませんが、現実的ではありません。技術的負債は長期間にわたって存続することがよく知られています。さらに、どの CIO も、前任者が残した混乱を一掃するために IT 予算を無駄にするよりも、新しいテクノロジーや新しいものに IT 予算を費やしたいと考えています。

しかし、クラウドネイティブに期待できる理由もあります。クラウドネイティブは魔法のほうきではありませんが、その中核となるプラクティスは、企業が技術的負債を削減し、少なくとも以前ほど負債を増やすことなく新しいソフトウェア機能を提供するのに役立ちます。

新たな負債が発生しないようにビジネスで技術的負債を解消することは確かにパズルの一部ですが、より差し迫った問題は、既存のレガシー技術的負債をどのように返済するかということです。

長年にわたり、私たちのインフラストラクチャには、便利なショートカット、扱いにくいコーディング、さまざまなインターフェースが絡み合った混乱が形成されてきました。この困難な問題に対しては、「迅速かつ断固とした」対策を講じる必要があるかもしれない。

クラウドネイティブコンピューティングは、ドメイン駆動設計に基づくアーキテクチャの再構築という、非常に鋭いナイフです。ドメイン駆動設計では、複雑なエンタープライズソフトウェアの課題を、それぞれが「境界付けられたコンテキスト」を持つ個別のビジネスドメインに分割する必要があります。

境界付けられたコンテキストは、ビジネスニーズに基づいて「顧客」や「請求書」などのビジネス上の問題を解決するためにコンテキストを制限できます。たとえば、大企業の異なる部門では、顧客の概念が異なっている（重複している可能性もある）場合があります。それぞれが別個の境界付けられたコンテキストを表します。

マイクロサービスアーキテクチャの初期の調査により、相互接続されたマイクロサービスが急増しましたが、その複雑さがスケーラビリティの制限としてすぐに明らかになりました。境界付けられたコンテキストを通じてそれらを整理することが、この複雑さを管理し、マイクロサービスベースのソリューションを大規模に提供するための鍵となります。

したがって、ドメイン駆動設計はクラウドネイティブコンピューティングの一部となり、さらに、この新しいパラダイムに従ってレガシー資産をどのように最新化する必要があるかを示します。

技術的負債の多いレガシーソフトウェアの課題に対処するための最初のステップは、アーキテクチャのリファクタリングを適用して、レガシーアーキテクチャを境界付けられたコンテキストを持つモジュール要素に変換することです。言い換えれば、企業は技術的負債を削減するための道筋を導くために、ビジネス主導の境界付けられたコンテキストに従ってモジュール性を導入する必要があります。

そして、悪魔は細部に潜んでいます。組織が直面しているビジネスニーズと従来の課題に応じて、この再構築をいくつかの方法で活用できます。

境界付けられたコンテキスト内の既存のコードが、現在の要件を満たしていないことに気付く場合があります。この場合、コードをマイクロサービスとして書き直すことができます。
従来のビジネスロジックにまだ価値がある場合は、それをマイクロサービスに移行します。
レガシーモジュールは、既に便利な API を備えているか、レガシーコードが更新されて API 経由で公開されるため、API として公開できます。
ロボティックプロセスオートメーション (RPA) プログラムを使用して、レガシーモジュールと対話するスクリプトを作成できます。

レガシーソフトウェアは以前に再編成され、境界付けられたコンテキストにモジュール化されているため、上記の 4 つのアプローチはそれぞれ他のアプローチよりもシンプルであることに注意することが重要です。

さらに、技術的負債を分割する「分割統治」アプローチにより、必要に応じて将来のリファクタリングがより簡単になります。たとえば、企業にとっては、1 つの大きな技術的負債を返済するよりも、4 つの小さな技術的負債を時間をかけて返済する方が簡単な場合があります。

このアプローチは、RPA の脆弱性を軽減する最良の方法の 1 つでもあります。境界付けられたコンテキストに基づくアーキテクチャのリファクタリングがなければ、アプリケーション環境のどこかで何かが変更されると、そのようなボットは機能しなくなります。適切に区分化することで、このような障害はより管理しやすくなり、修正も容易になります。

新たな技術的負債の防止

新たな技術的負債を防ぐことは、部屋をきれいに保つように頼むようなものです。しばらくはきれいな状態を保てるかもしれませんが、最終的には乱雑になってしまいます。

必要なのは、さらなる構造ですよね？少なくともクラウドネイティブの場合には、その構造は役立ちます。

クラウドネイティブコンピューティングは、ソフトウェアの構築、インフラストラクチャの構成、アプリケーションの作成と展開、運用環境におけるすべての管理を最適に行う方法を説明する幅広いベストプラクティスを提供します。

もちろん、このアドバイスをすべて実行すれば、新たな技術的負債が発生する可能性は低くなります。少なくとも、発生する速度は遅くなります。

「Infrastructure as Code」(IaC) の原則が重要な例です。 IaC の原則では、作業者は運用中のサーバーを操作してはならないと規定されています。 IaC の原則は、運用上の問題を解決するための積極的なアプローチを提供するため、運用における追加の技術的負債を確実に制限できます。ただ 1 つ問題があります。それは、IaC だけでは不十分だということです。

IaC の問題は、さまざまなプログラムを記述する必要があることです。これらのプログラムは、他のプログラムと同様にテスト、管理、バージョン管理する必要があります。つまり、他のソフトウェアと同様に技術的負債が発生する可能性があります。

幸いなことに、クラウドネイティブコンピューティングは IaC を超えて進化しており、各ステップで前のステップよりも改善されています。

最初のステップは、宣言的な構成を通じてインフラストラクチャを表現することです。宣言的な構成では、インフラストラクチャを構成する方法を指定しますが、その構成を実現する方法を指定しません。

IaC と比較すると、宣言型アプローチではショートカットの余地が少ないため技術的負債が軽減されますが、これらの表現 (通常は YAML ファイルまたはその他の JSON ベースの形式) は、特に複雑で動的なインフラストラクチャ構成の場合、依然としてコードと非常によく似ています。

ステップ 2: GitOps。 GitOps は、Git 中心のプラクティスとプロセスをソフトウェアのリリースと管理に導入します。

GitOps はソフトウェアのデプロイメントに宣言的なアプローチを採用しているため、インフラストラクチャ構成に対する宣言的なアプローチをさまざまな方法で補完します。 GitOps は、プロセスにさらなる構造を提供することでさらに一歩進んでおり、構造が強化されるほど、技術的負債が発生する可能性が低くなります。