application配信が職人の作業場ではなく工場のようになるべき理由
昔は…
クラウド以前の時代では、applicationの配信は現在とは大きく異なっていました。 なぜなら、applicationsが実行されるサーバーを IT 部門が調達してプロビジョニングする速度よりも速いものはなかったからです。 新しいapplicationsや主要なapplicationの更新の計画には、数か月から数年かかりました。 同時に、エンタープライズapplicationsはますます複雑になり、追跡や管理が困難な相互依存関係のリストが増大しました。 システム全体を数日間停止させたり、キャリアに終止符を打つデータ漏洩につながる可能性のあるセキュリティの脅威が発生しました。 外部の悪意ある行為者がいない場合でも、ネットワーク (およびそれがサポートするapplications) の機能を停止させる変更を実施するリスクは、複雑性指数とともに増加し続けました。
これらのリスクを管理し、管理下にあるすべてのapplicationの安全性と信頼性を確保するために、ネットワーク チームとセキュリティ チームは、手動によるレビューを多用し、通常は各applicationの固有のニーズを満たすように設計された手作業によるポリシーを伴うプロセスとポリシーを開発しました。 これらの手順は面倒ではあったものの、必ずしもボトルネックになるわけではありませんでした。 彼らは調達プロセスのペースを決めることがよくありました。
晴れ渡った青空から…
そしてクラウドが起こりました。 突然、展開プロセスが、それまで高速に動いていたシステムの足手まといになり始めました。 同じ頃、GitHub やその他のソーシャル コーディング プラットフォームにより、同じチーム内であっても、オープン ソース プロジェクトであっても、開発者がコード上で共同作業を行うことが容易になりました。 新しいapplicationアーキテクチャにより、applicationの一部で行われた作業が他の部分と競合する機会が減り、開発者の効率が大幅に向上しました。競合は、労力、やり直し、遅延の主な原因でした。 マイクロサービスとサービス メッシュ アーキテクチャは、application自体の各部分間の依存関係を軽減し、コンテナーとサーバーレスは基盤となるインフラストラクチャへの依存関係を軽減して、個々の開発者とapplicationチームが独自のペースで作業できるようにします。 開発者は数か月ではなく数分でapplicationsを展開できるようになりました。 当初、このような展開は開発およびテスト プロジェクトに限定されていましたが、実稼働システムへのより高速なアクセスに対する需要が急速に高まりました。
デジタル トランスフォーメーション: 進行中の作業
ネットワーク管理者とセキュリティ エンジニアは、開発者とは異なり、ワークフローの最適化よりもビジネスの安全維持に専門的な経験が集中していたため、対応に苦労していました。 開発者にとって、プロセスの自動化、システムの合理化、システム間の依存関係の削減、可能な場合は再利用可能なプロセスとコードの活用など、DevOps 運動として知られるようになったものの背後にある中核概念の多くは、すでに第二の性質となっていました。 対照的に、ネットワーク管理者とセキュリティ エンジニアは職人として訓練されました。 彼らの仕事は極めて重要なため、すべてのapplicationを手動でレビューし、変更レビュー委員会で維持し、変化する状況に応じて (手動で) 更新できる手作りのポリシーを通じて管理する必要がありました。
良いニュースとしては、導入の自動化プロセスの理解という点では開発者からかなり遅れてレースが始まったにもかかわらず、ネットワーク チームとセキュリティ チームが追いつきつつあることです。
applicationファクトリー: application配信にシステムマインドセットを適用する
移行について考える良い方法は、applicationファクトリーを想像することです。 ネットワークおよびセキュリティの専門家は、手作りのポリシーと手動のレビュー プロセスの代わりに、再利用可能なポリシーを定義し、それを開発者にプッシュして、導入の自動化パイプラインの一部としてapplicationsとともに展開する必要があります。
確かに、言うのは簡単ですが、実行するのは難しいです。 手作り品から工場生産品への移行が、単に重機を購入し、労働者を新しい役割に再配置するだけの問題ではなかったのと同様に、システムアプローチへの移行は、ツールやプロセスだけでなく、考え方や文化に関するものでもあります。 変更レビュー委員会やセキュリティ チームが、考えられるすべてのセキュリティ脅威ベクトルとパフォーマンス リスクを苦労して調査する代わりに、適切に設計された自動application配信システムは、障害ドメインを小さく保って影響を最小限に抑え、効果的なフィードバック ループを組み込んで早期検出と対応を可能にします。 ツールとパイプラインの決定では、開発者の自由度と一貫したサービスの効率性の価値のバランスを取る必要があります。 理想的なシステムでは、機能開発に影響を与えるツールに関する決定を開発者が行う最大限の自由が与えられ、同時に、マルチクラウド対応のインフラストラクチャとセキュリティ サービスの一貫したセットが提供されます。 application配信パイプラインの中核に一貫したサービスを組み込むことで、技術的負債が軽減され、運用とコンプライアンスの効率が向上します。 その結果、開発者はビジネスにさらなる革新的な価値を提供することに集中できるようになります。
(下の画像をクリックすると、F5 Application Factory の完全なインフォグラフィックが表示されます。)
