ここ数年、開発チームはより少ないリソースでより多くのことを行うよう求められてきました。 パンデミックと特にチップ製造の不足によって引き起こされた世界的なサプライチェーンの混乱は、テクノロジー業界に影響を与えました。 これらの要因により、開発者のワークロードはクラウドに移行し、より非同期でリモートの労働力が生まれ、最新のアプリケーションに対する需要が高まっています。
これらの変化にはすべて、独自の一連の課題が伴います。 最近のウェビナーでは、 2022年に注目すべきAppDev の課題とトレンド(オンデマンドで視聴可能)BoxBoat(IBM傘下)のDockerキャプテン兼ソリューションアーキテクトであるBrandon Mitchellが、コンテナ化の旅を通じて企業を支援してきた彼の仕事から見てきた重要な課題と傾向についての洞察を共有しました。 ウェビナー全体を通して、Brandon は、開発チームが安全で組織のポリシーに準拠した最新の革新的なソリューションを構築し続けることができる貴重な機会を特定しました。
ウェビナーの要約と、新しい市場レポート「 2022年以降のアプリケーション開発の現状」の詳細については、引き続きお読みください。
今日のアプリケーション開発の課題
Brandon は、ソフトウェア開発分野で直面している主な課題として、次のような課題を特定しました。
- レガシーシステムの更新
- ソフトウェア配信パイプラインを中断することなくコンポーネントを最新化
- クラウドネイティブアプリの需要に対応
これらの課題に対処するために、多くの業界リーダーがアプリケーションをコンテナに移行しました。
トレンド#1:標準としてのコンテナ化
Brandon氏によると、「コンテナ化の旅をまだ始めていない場合は、おそらくすでに業界の同業他社に遅れをとっているので、今がそれに飛びつく時です。 昨日はその時でしたが、今のような時間はありません。」 組織は、より効率的なソフトウェア配信パイプラインを標準化するために、レガシーアプリケーションを含むコンテナ内のすべてを移行しています。
この傾向の良い点の1つは、開発者が複数のワークフロー(古いレガシーモデルを管理する開発者用と新しいシステムのさまざまなマイクロサービスすべてを管理するワークフロー)を管理する必要がなくなることです。 複数のワークフローを管理すると、本番環境と開発環境の両方で摩擦が生じます。
トレンド#2:ソフトウェアの構成要素としてのCI / CD
CI/CD は、開発者コードのチェックインから本番環境へのデプロイまで、すべてが CI/CD を通過するため、誰もが依存するコア環境になる傾向があります。 Brandon 氏は、ドメイン固有の言語から宣言型環境への移行が進んでいると述べました。 開発者は一時的なコンテナをスピンアップしています - 新しいバージョンを持っているとき、彼らは新しいコンテナをスピンアップします。 組織が運用環境にデプロイする方法の新しい設計は、すべてのデータがボリューム単位でマップされたクリーンな状態にリセットされるクリーンな環境です。
アプリケーション スタックを最新化するには、CI/CD パイプラインを最新化する必要があります。 これに向けた最初のステップは、物事をマイクロサービスに分割することです。 Brandon が組織が直面する課題の 1 つは、チームが開発でテストするサービスの組み合わせが、本番環境で実行するサービスの組み合わせと必ずしも一致しないことです。
ブランドンはまた、セキュリティチェックにシフトが残っているのを見たと説明しました。 セキュリティ ツールは、フィードバックを高速化するために CI/CD パイプラインの早い段階で移行しています。理想的には、これは開発者のデスクトップで発生しています。 Docker Scan は、開発者がマシン上の脆弱性をスキャンして、Gitリポジトリにコミットする前にコードをテストできる優れたツールです。 このプロセスにより、開発者がコードをコミットするときにセキュリティ認識の権利が与えられ、プロアクティブになるために必要なツールが提供されます。
トレンド#3:DevSecOpsによる安全なソフトウェアサプライチェーン
Brandon は、セキュリティの左翼化について見てきた傾向について、さらに詳しく説明しました。 この大きな変化は、政府の規制(ホワイトハウス大統領令など)と、SolarWinds攻撃、Heartbleed、OpenSSLの脆弱性などの最近の攻撃の組み合わせによって推進されています。
攻撃者はサプライチェーンを追跡し、上流またはインフラストラクチャの構築の脆弱性を探しています。 潜在的に悪意のある開発者は、コードをアップストリームビルドにプッシュする方法を見つけており、そのコードは環境にプルされ、依存関係がチェックされていないため、信頼できるコードであるかのようにアプリケーションにデプロイされます。 このコードは、開発者環境で 1 つのコマンドでプルされ、運用環境にデプロイされます。 ブランドンが提案したこれに対するいくつかの解決策は次のとおりです。
- ビルド環境の強化
- ソフトウェア部品表 (SBOM) の生成
- 署名の追加
- 再現可能なビルドを探しています
- ワークフローの早い段階でスキャンをシフトする
SBOMは、チームがコンパイルされたすべてのアプリケーションにあるものを追跡できる成分リストと考えることができます。 開発チームはSBOMを使用して、デプロイしたものに脆弱性があるかどうかを特定し、脆弱性がある場合は、コード内のこの脆弱性が本番環境でデプロイされているすべての領域を簡単に追跡できます。 もう 1 つの重要な解決策は、イメージの署名と、それに加えて、チームが信頼され検証されたイメージのみに署名するようにすることです。
Brandon は、再現可能なビルドは効果的であるが、本番環境での実装が難しいため、再現可能なビルドを「聖杯」と呼んでいます。 組織の通常のビルド インフラストラクチャでビルドした後、再現可能なビルドでは、まったく新しい別の環境でそのビルドを実行する必要があります。 ビルドがバイト単位で一致しない場合、組織は何かがうまくいかなかったことを認識しており、調査する必要があります。 その何かは単に奇妙な構成である可能性がありますが、攻撃者が侵入して、本番環境に移行する前に停止する必要がある悪意のあるコードを挿入したことを示している可能性もあります。
2022年以降のアプリケーション開発の状況
ウェビナー中、Brandon は上記の各トピックについて詳しく説明し、Docker 製品マーケティングマネージャの Cat Siemer とライブディスカッションを行いました。 彼はまた、ウェビナー参加者からのライブQ&Aにも対処したので、これらの追加の洞察を得るために完全な ウェビナーの記録を必ずチェック してください。
このトピックについて詳しく知りたい場合は、公開したばかりの新しい市場レポート「2022年以降の アプリケーション開発の状況」で、2022 年の開発チームと開発者中心の組織の成功の鍵となると予測される6つのトレンドに焦点を当てています。 このレポートでは、開発チームが Docker Business やその他の サブスクリプション オファリングを使用してアプリケーションを構築、共有、実行する方法を最新化することで、競争力を維持する方法について説明しています。
