DevOps 実践者はなぜアプリごとのアーキテクチャを気にする必要があるのでしょうか?
その質問には、そうすべきだという結論が暗示されています。
私たちは数十年にわたり、生産パイプラインの大部分を構成するアプリケーション サービスを共有プラットフォーム上に展開してきました。 負荷分散、アプリケーション パフォーマンス サービス、WAF、フェデレーション ID などのアプリケーション サービスは、多くの場合、アプリケーション配信コントローラ (ADC) の形式で共有インフラストラクチャ上の NetOps によって提供されます。
しかし、時間と需要、そしてマイクロサービスなどの新しいアプリケーション アーキテクチャによって、そのパイプラインに変化が迫られています。 これらの変更は、NetOps と DevOps の両方にとって良いことです。なぜなら、コードとしてのインフラストラクチャなどの展開スケジュールや運用プラクティスとより密接に連携するモデルに移行しているからです。
共有インフラストラクチャ上にしっかりと定着したままになっているアプリケーション サービスもいくつかあります。 。 ボリューム型 DDoS 攻撃に対する防御。 ネットワーク ファイアウォール。 これらのサービスは本質的に企業向けサービスです。 つまり、ビジネスを保護し、防御し、貢献するように設計されています。 これらのサービスが失敗したらどうなりますか? 企業全体の生産性や利益はゼロです。
しかし、他のアプリケーション サービスはアプリケーションとの親和性が非常に高く、その構成、API、サービスは単一のアプリケーションをサポートするように特別に構成されていることがよくあります。 単一のアーキテクチャではなく、単一のアプリケーションです。
これらのサービスの責任は、アプリケーション運用 (DevOps) へと移行し、アプリケーションを提供する開発者の関与が進んでいます。 共有モデルは、必要な配信およびセキュリティ アプリケーション サービスの提供に依然として機能しますが (多くの場合は機能します)、多くのサービスでは、いくつかの理由からアプリごとのモデルが望ましいです。
まず、アプリごとのモデルにより、展開スケジュールの競合が適切に解決されます。 企業組織は、サポートするアプリケーション サービスの構成と展開に関して、共有インフラストラクチャの競合によって制約を受けることがよくあります。 共有インフラストラクチャは共有リソースを意味し、必然的に構成の衝突の可能性が高まります。 その可能性を排除することで、より頻繁な展開や予定外の展開に対する抵抗を軽減できます。 結局のところ、アプリケーション サービスが自分のアプリケーション専用であり、独自のリソースを持つ独自のプラットフォームで実行されている場合、競合はうまく解決されます。 私のアプリ、私のリスク。
2 番目に、アプリごとのモデルは、インフラストラクチャをコードとして実行するなどの方法論の実践を含む、新たな自動化の取り組みをサポートします。 リソースとプラットフォームを単一のアプリケーション専用にすることで、構成にはそのアプリケーションのみが含まれます。 不変性を強制し、エントロピーのリスクを回避できます。 実際、私は、アプリごとのアーキテクチャがなければ不変のインフラストラクチャを適切に構築することはできないと主張します (最近そう主張しました)。 このアプローチにより、アプリケーション インフラストラクチャを超えて「ネットワーク」にまで拡張される継続的なデプロイメント パイプラインへの組み込みが可能になります。 この機能を提供するということは、構成と継続的な管理の責任を NetOps から DevOps に移行することを意味します。 良いニュースとしては、責任が大きくなると制御も大きくなり、DevOps がアプリケーション サービスの「所有者」となり、独自の条件とスケジュールでアップグレード、パッチ適用、再展開する権限が与えられることです。
最後に、アプリごとのモデルは、より移植性が高くなります。 共有プラットフォームに縛られることなく、デプロイメント アーティファクト (構成とテンプレート) にほぼ独占的に依存することなく、運用パイプラインの大部分を、はるかに少ない摩擦と労力でクラウドからクラウドへ、オンプレミスからオンプレミスへ移行できるようになります。 この自由により、組織は移行に関連するコストに制約されることなく、対象のアプリケーションに最適なクラウドと場所を選択できるようになります。
DevOps は、オンプレミスとパブリック クラウドの両方で、アプリケーション サービスに対するアプリごとのアーキテクチャの採用を促進することで大きなメリットを得ることができます。 NetOps は他の運用ドメインに対してより優れた制御と可視性を提供するようプレッシャーを受けています。今こそ、ピザとビールを手に、NetOps の担当者と次世代のアプリケーション中心のアプリごとのアーキテクチャのサポートへの移行について話し合う良い機会です。