アプリケーション サービスに対するアプリごとのアプローチが重要な理由
私は人の心を読むことはできません (私の子供たちは反対するでしょうが、それはここでは関係ありません) が、アプリケーション配信の状況に関する調査への回答を読むことはできます。 そして、自称アプリ開発者の視点からそれらを読んでいくと、非常に興味深い図が浮かび上がってきます。
開発者は速度を重視します。 そしてセキュリティ。 そして規模。 必ずしもその順序ではありませんが、彼らは3つすべてを気にしています。 彼らは関心を持っているだけでなく、これら 3 つすべてを達成するのに役立つアプリケーション サービスの価値を認識しています。
つまり、開発者は漠然とした「加速」アプリケーション サービスだけでなく、TCP の最適化とキャッシュを提供する具体的なサービスも求めています。 彼らは、 Web アプリケーション ファイアウォールと、それに加えて負荷分散も必要としています。
問題は、これらのアプリケーション サービスのほとんどが共有インフラストラクチャ モデルで提供されることです。 各アプリケーションは独自の「仮想表現」を取得しますが、物理的には共有ソフトウェアまたはハードウェア上に存在します。
これは実際に問題を引き起こす可能性があり、IT 部門とアプリ開発部門の間に残る摩擦の原因の一部にもなります。 システムのこの共通性により、変更ウィンドウやレビュー ボード、土曜の夜のデプロイ (気を紛らわすためにピザを食べながら) など、開発を遅らせ、関係者全員にとってデプロイをフラストレーションのたまる体験にするプロセスが生まれました。
モノリシックなモンスター アプリを展開することはもうありません。 たとえ、熱狂的なマイクロサービスに移行してアプリを何百もの小さなサービスに分解していなくても、より頻繁なデプロイメント スケジュールに従うアプリはまだたくさんあります。 1 年間のプロジェクトではなく、1 週間のスプリントで開発され、より迅速かつ頻繁に更新をプッシュする必要があるアプリ。
結局のところ、それが（パブリック）クラウドがこれほど成功した理由なのです。 それは私のアプリであり、私のインフラストラクチャなので、更新をプッシュする前に Bob や Alice や John を待つ必要はありません。 なぜなら、それはすべて私のものであり、何か問題が起きればすべて私の責任になるからです。
同じアプローチはオンプレミスでも可能です (そして、好ましいと思います)。 必要なのは、アプリケーションの配信チェーンを構成するすべての部分が、クラウドによって望ましいものとなったのと同じ種類のアプリごとのアプローチをサポートすることです。
基本的に、必要なネットワークおよびアプリケーション サービスを提供するアプリごとのアプローチは、アプリケーション専用のサブネット、つまりアプリ配信 VLAN に似ています。 重要なのは、専用のサービスを備えた 1 つのアプリです。
こうした分離は、展開スケジュールに適しているだけでなく、他のすべての人にとっても良いことです。 失敗は起こるものであり、その場合、爆発半径を可能な限り制限する必要があります。 アプリごとのアーキテクチャは、障害の影響が厳しく制限されることを意味します。そのため、「念のため」オンコールの担当者は、その電話を受けなくて済むので安心です。 月に一度リリースおよびデプロイするアプリに干渉することなく、毎週リリースおよびデプロイできます。 私のアプリ、私のサービス、私の展開スケジュール。
アプリごとのアーキテクチャにより、運用中に発生する問題のトラブルシューティングも容易になります。 そして、彼らは頻繁にそうします。 実際、 2017 年の Atlassian の調査では、開発者の 50% がコードリリース後に本番環境で問題が発生したと報告しています。 他の誰かがアプリケーションに影響を与えるような変更を加える可能性はありません。 どのシステムが関係しているかを調べるのに貴重な時間を費やすのではなく、関係するシステムに直接アクセスできます。
アプリごとのアーキテクチャは、モデルによって想定されているため、パブリックかプライベートかに関係なく、クラウドに自然に適合します。 各アプリには、拡張、高速化、セキュリティ保護のための専用のアプリケーション サービス セットがあります。
現実には、アプリごとのアーキテクチャは避けられませんでした。 私がそう言ったのはこれが初めてではありません。 アプリケーションの重要性は無視できないほど大きく、アプリケーションを安全に保つためにアプリケーション固有のセキュリティがますます必要になったため、遅かれ早かれアプリごとのアプローチが導入されることになったのです。
これは良いことです。なぜなら、開発者が求めるアプリケーション サービスは、多くの場合、アプリケーション固有のものだからです。 一方に有効なものが、必ずしももう一方に有効であるとは限りません。実際はマイナスになる可能性もあります。 アプリケーション配信にアプリごとのアーキテクチャ アプローチを採用することで、開発者がアプリの拡張、セキュリティ保護、高速化に必要なものを得られるだけでなく、オンプレミスかオフプレミスかを問わずクラウドに期待されるセルフサービス モデルをより適切にサポートできるようになります。