BLOG

アプリケーションデリバリが(職人の工房ではなく)工場のようであるべき理由

Teri Patrick サムネール
Teri Patrick
Published December 11, 2019
  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share via AddThis

昔は…

クラウドより前の時代では、アプリケーションデリバリは現在とは大きく異なり、その速度は、アプリケーションが稼働するサーバをITがどれだけ速く調達およびプロビジョンできるかで決まっていました。新しいアプリケーションまたはアプリケーションのメジャーアップデートの計画には、数か月または数年かかっていました。同時に、追跡と管理が難しい相互依存関係のリストが増え、エンタープライズアプリケーションはますます複雑になりました。数時間に及ぶシステム全体のシャットダウンや取り返しのつかないデータ漏洩につながる可能性があるセキュリティ脅威が出現しました。外部の攻撃者がいなくても、ネットワーク(およびそれがサポートするアプリケーション)を弱体化させる変更を実装するリスクは、複雑さの指標とともに上昇を続けました。

これらのリスクを管理し、その管理対象のすべてのアプリケーションの安全性と信頼性を確保するために、ネットワークおよびセキュリティチームは、手作業のレビューに重きを置き、一般的に各アプリケーション固有のニーズを満たすよう設計された手作りのポリシーを含むプロセスおよびポリシーを開発しました。面倒ではありましたが、これらの手順は必ずしもボトルネックになったわけではなく、調達プロセスが一定の速度で進むことがよくありました。

なんの前触れもなく…

その後、クラウドが誕生しました。突然導入プロセスが、それ以外は高速に動くシステムの重荷となり始めました。同時期に、GitHubとその他のソーシャルコーディングプラットフォームにより、開発者にとっては、同じチーム内でもオープンソースプロジェクトでも、コードでの共同作業が簡単になりました。新しいアプリケーションアーキテクチャは、アプリケーションのある部分で行われた作業と他の部分での作業が競合する機会を減少するため、開発者の効率性を劇的に向上させました。マイクロサービスおよびサービスメッシュアーキテクチャにより、アプリケーション自体の各部分間の依存関係が減り、コンテナおよびサーバーレスにより基盤となるインフラストラクチャへの依存関係が減ることで、個々の開発者およびアプリケーションチームは自分のペースで動いていくことができます。現在、開発者は、数か月ではなく数分でアプリケーションを導入できるようになりました。最初は、このような導入は開発およびテストプロジェクトに限定されていましたが、実稼働システムへの高速なアクセスを求める需要は急速に高まりました。

デジタル変革:取り組み中の業務

ネットワーク管理者およびセキュリティエンジニアはその速さに追い付くことに苦労していました。その1つの理由として、彼らの専門的な経験の中心は開発者のそれとは異なり、ワークフローの最適化ではなく、ビジネスの安全の確保であるためです。開発者にとって、プロセスの自動化、システムの合理化、システム間の依存関係の軽減、および可能な限り再利用可能なプロセスやコードの活用といったDevOpsムーブメントとして知られるようになったものの背後にある主要な考えの多くは、すでに、自然と行われるよう組み込まれたものとなりました。対照的に、ネットワーク管理者およびセキュリティエンジニアは、手を動かす職人として訓練されました。これらの業務上の重大な特質により求められたことは、すべてのアプリケーションを手動レビューで処理し、変更審査委員会で保守して、状況の変化に応じて(手動で)更新できる手作りのポリシーで管理することでした。

幸いなことに、自動化された導入プロセスを理解するという点では開発者に遅れ取っていたネットワークチームおよびセキュリティチームは、その遅れを取り戻しつつあります。

アプリケーションの工場:システムマインドセットをアプリケーションデリバリに適用

移行について考えるときのお勧めの方法は、アプリケーションの工場を想像することです。ネットワークおよびセキュリティの専門家は、手作りのポリシーと手動レビューのプロセスではなく、再利用可能なポリシーを定義し、それらを開発者にプッシュして、自動化された導入パイプラインの一部としてアプリケーションとともに導入する必要があります。

これは言うほど簡単なことでないことは確かですが、手作り品から工場生産品への移行が、単に重機を購入して労働者を新しい役割に再配属するだけの問題ではなかったように、システムアプローチへの移行は、ツールとプロセスだけでなく考え方と文化が重要です。変更レビュー委員会やセキュリティチームが起こり得るすべてのセキュリティ上の脅威やパフォーマンスリスクを入念に調査するのではなく、適切に設計された自動化されたアプリケーションデリバリシステムを利用することで、障害ドメインを小さくし、影響を最小限に抑え、効果的なフィードバックループを構築して、早期の検知および対応を可能にできます。ツールおよびパイプラインに関する意志決定は、開発者の自由と一貫したサービスの効率性の価値のバランスを考慮して行う必要があります。理想的なシステムは、機能開発には影響するものの、マルチクラウド対応のインフラストラクチャおよびセキュリティサービスの一貫したセットを提供するツールに関する意志決定を行うという、最大限の自由を開発者に提供します。一貫したサービスをアプリケーションデリバリパイプラインの核に組み込むことで、技術的負債を減らし、運用およびコンプライアンスの効率性を改善します。これにより、開発者はビジネスにより多くの革新の価値を提供することに集中できます。

(F5 Application Factoryのインフォグラフィックについては、以下の画像をクリックしてご覧ください。)

Connect with F5

F5 Labs

The latest in application threat intelligence.

DevCentral

The F5 community for discussion forums and expert articles.

F5 Newsroom

News, F5 blogs, and more.