これら 4 つのコンテナ展開方法のうちどれが最適ですか?

[[353760]]

コンテナは、実現技術として、企業の IT 計画において重要な役割を果たします。その理由は明白で、企業が急速な発展を遂げるのに役立つからです。結局のところ、デジタルビジネスにおいてはスピードがお金なのです。ビジネスの俊敏性を実現するために、IT リーダーは、予算の 80% がメンテナンスに費やされ、イノベーションには 20% しか投資されないという従来の 80/20 モデルを覆したいと考えています。今日、CIO は、ビジネスの俊敏性と感度を高めるために、より多くの予算を活用したいと考えています。

コンテナ、DevOps、マイクロサービスなどの要素を組み合わせることで、CIO はこの目標を達成できます。

つまり、コンテナはアプリケーションを、それが実行されるホスト システムから分離された単一のパッケージにカプセル化します。開発者は開発プロセス中にこれらのパッケージを簡単に移動できます。これは DevOps コンセプトの基本要件でもあります。コンテナ テクノロジーは、開発環境から本番環境への迅速な移行にも役立ちます。

テクノロジーだけでは問題を解決することはできません。 CIO は、複数の部門横断的な DevOps チームと連携し、プロセスとビジネスの境界を再考する際に、文化的な課題にも直面する必要があります。テクノロジーであれ文化であれ、CIO は同僚から多くのことを学ぶことができます。本稿では、企業がコンテナを導入する代表的な4つの方法を紹介し、それぞれの導入で注意すべき点を列挙します。

もちろん、特定の企業にコンテナを導入する完璧な方法は存在しません。あるパスから始めて、別のパスに切り替えることができます。さらに、企業内のさまざまなチームが異なるコンテナ展開方法を採用することがよくあります。したがって、企業内には複数のコンテナ展開モードが共存することがよくあります。

コンテナプラットフォームの紹介

コンテナを使い始めてから、多くの企業はすぐにプラットフォームが必要であることに気付きました。通常、特定のグループ (DevOps グループなど) が、変更プロセス中に迅速な実験と展開を行うために、アジャイル テクノロジ プラットフォームを導入します。このプロセスでは、コンテナが理想的なソリューションとなり、コンテナを採用し、最終的には企業運営の一部として定着させるようリーダーを説得しようと努めます。重要な質問は、企業がコンテナを展開および管理するためにどのプラットフォームを使用すべきかということです。市場には多数のオープンソース コンテナ ツールがありますが、エンタープライズ レベルのコンテナ プラットフォームには通常、Kubernetes オーケストレーション、セキュリティ、ネットワーク、管理、自動ビルド、継続的インテグレーション/デプロイメント機能など、数十のオープンソース プロジェクトが含まれています。全体として、このようなプラットフォームは、多くの管理、ガバナンス、セキュリティの問題に対処するのに役立ちます。

この方法では、企業は簡単に達成できる目標から始めることができます。多くの場合、Web サーバーとアプリケーション サーバーは、コンテナ化されたワークロードの最も簡単なターゲットであり、データベースとステートフル システムがそれに続きます。また、既存のビルドおよびデプロイメント ツール/プロセスとの統合を注意深く監視し、進捗状況を確認します。

さらに、コンテナのセキュリティ問題も考慮する必要があります。コンテナにはシステム固有のライブラリと依存関係が含まれているため、隠れたセキュリティの脆弱性が発見される可能性は低くなります。信頼できるレジストリ、イメージ スキャン、および管理ツールは、コンテナー イメージを自動的に識別して修復できます。

クラウドネイティブアプリケーションコンテナの構築

一部の企業では、新規プロジェクトや既存アプリケーションの変更など、アプリケーション開発チームによって構築されたクラウドネイティブ アプリケーション コンテナーを使用することを好みます。これらのアプリケーションは、多くの場合、マイクロサービス アーキテクチャに基づいており、アプリケーションを複数の基盤サービスに分割して、チームが個々のコンポーネントに基づいてアプリケーションを更新できるようにすることを目的としています。 IT チームは柔軟な API を使用してこれらの目標を達成することもできます。

このモデルを採用する場合、企業は安全で十分に理解されている API セットを使用して、アプリケーション内の他の自社またはサードパーティのアプリケーション、システム、およびデータと対話する必要があります。また、既存のシステムとどのように統合するかについても十分に検討する必要があります。このことから、コンテナ、マイクロサービス、API を組み合わせることで、開発チームがクラウドネイティブ アプリケーションをより簡単に開発、共同作業、展開できるようになることがわかります。

新しいランタイムを検討する場合、従来導入されたモノリシック アプリケーション サーバーは、イベント駆動型設計、応答性、サーバーレスなどの新しいテクノロジを使用する次世代アプリケーションを実行するために導入することが困難です。コンテナ プラットフォームは、既存のクラウド ネイティブのランタイムとフレームワークを幅広くサポートできる必要があります。同時に、開発者ツールにも注意を払う必要があります。ランタイムが進化し続けるにつれて、クラウドベースの開発ツールは、自己学習テクノロジーと自動化されたワークフローによってもたらされるますます複雑化する作業環境を効率的に管理し、開発者が高品質の製品コードをより迅速に構築できるようにすることも期待されています。

クラウド管理を実現するための技術的および文化的要因

この一般的なモデルでは、通常、運用チームや多数のアプリケーションを管理するその他のチームがパブリック クラウドの利点を認識しており、その弾力性、速度、パフォーマンスを運用環境に取り入れたいと考えています。ただし、歴史的、規制的、またはセキュリティ上の考慮事項により、チームは特定のアプリケーションをオンプレミス環境で実行する必要がある場合があります。さらに、チームは、従来のベアメタル サーバーや仮想化環境、さらには一部のプライベート クラウドを処理する必要があることもよくあります。数多くの考慮事項に直面すると、クラウド管理が重要なリンクになります。

ここでの重要な質問は、抽象化レイヤーをどのように確立するかということです。あらゆる環境で適切に実行できるプラットフォームですか?運用チームがすべてのアプリケーションをシームレスに管理できるようにしますか?さまざまな種類のインフラストラクチャを隠し、開発者に統一されたデプロイメント環境を提供するにはどうすればよいでしょうか。この利便性は、開発者の作業速度を向上させるための重要な前提条件になります。

別の観点から見ると、文化的な要因によりデジタル変革を始めることが困難になる可能性があります。大規模な変革を主導した銀行の最高情報責任者（CIO）は、従業員が考え方や行動パターンの変化に真に適応できなければ、すべての変革は無駄になるだろうと語った。文化的な変化を推進する IT リーダーには、上級管理職と最前線のチーム マネージャーの両方からのサポートが必要です。結局、行動する意志があるかどうか、どのように行動するかに関わらず、ビジネスのスピードの追求は決してなくなることはないでしょう。

ビジネスイノベーションを推進

このモデルでは、企業は特定のビジネス問題を解決するために小規模なチームを編成し、より現代的なプラクティスを導入し、従業員が変化の推進者となるよう指導する必要があります。同時に、IT チームは迅速にソリューションを作成し、反復し、IT 部門がその後ソリューションを拡張できるようにする必要があります。これらのチームには通常、新しい技術ツールとそれらを使用するためのアクセス権が与えられ、さまざまなルールに基づいて探索的な試験を実施します。

当社の IT スタッフは新しい要求に適応できるスキルを持っていますか?新しい従業員を採用する必要がありますか?本来のスキル投資をどうしたらいいのでしょうか？ ...スキルに関するこうした議論は徐々に表面化してきています。企業は、新しい従業員を採用するだけでなく、社内のクロストレーニングと外部の専門家を組み合わせて、現状を評価し、目標達成に役立つ計画を立てる必要があります。

企業は失敗を恐れてはいけないということに注目すべきである。企業が IT チームに大胆な試みをさせようとしない場合、必然的に優秀な人材が流出し始めるでしょう。オーストラリアのマッコーリー銀行を例に挙げましょう。同社の CIO は、画期的な新しい顧客体験を構築するために優秀な人材を採用したいと考えていました。マッコーリー銀行が質の高い新鮮な人材を引き付けることに成功したのは、まさにこの完全な権限委譲と創造性の尊重という姿勢によるものです。

要約する

すべてのデジタル変革は独自のものであり、2 つの DevOps パスがまったく同じということはありません。上記の 4 つのモデルと同様に、他の企業や競合他社がコンテナーを使用する方法を必ずしもコピーする必要はありません。しかし、それらから学び、コンテナの導入を促進するための次の基本的な考え方を参考にすることができます。

成熟した企業はクラウドネイティブ企業よりも大きな課題に直面しており、成熟した企業の多くの CIO は依然として COBOL アプリケーションをサポートする必要があります。

サイズの問題を気にする必要はありません。規模の観点からだけ見ても、Facebook に匹敵する企業は世界中にほとんどありません。しかし、ビジネスに大きな変化をもたらすために、Facebook の膨大なリソースやスキルセットは必要ありません。小さく始めて、成功を収めるにつれてチームとテクノロジーを拡大してください。

最後に、IT チームが外部とのコミュニケーションに積極的に参加するように促します。チームメンバーが社外の同僚と交流し、技術的および文化的な課題について話し合うことを奨励します。