2020年のDevOpsクラウドソリューションの現状

今やどの会社もリモートで作業する開発者を強力にサポートするクラウド/ハイブリッドDevOpsプラットフォームを持っていると主張しています。ようやく混沌とした状況が整理され始めました。

 

今日のデジタル時代ではソフトウェアこそがビジネスのイノベーションを牽引しています。ソフトウェア・デリバリー・プロセスの成熟度、スピード、品質、セキュリティは、このソフトウェア主導の経済において重要な差別化要因です。そしてCOVID-19の現実がリモート開発者のITへのアクセスする必要性をさらに加速させています。その結果、ソフトウェアベンダーはクラウドのDevOpsソリューションを提供し、拡大するためにしのぎを削るっています。 チームはエンドツーエンドのDevOpsプラットフォームやツールを採用し、複数のベンダーへの依存度やインフラの所有を減らすケースが増えています。しかし企業はクラウド DevOps ツールに何を求め、どのような差別化要因を考慮すべきなのでしょうか。

ここでは、現在利用可能なクラウド DevOps プラットフォーム・ソリューションのハイレベルな概要とクラウド DevOps の実現に向けてベンダーに期待すべきことについて説明します。

^**この情報は、JFrogが行った調査に基づいており、2020年4月時点で市場で利用可能なソリューションを反映しています。

エンタープライズクラウドのDevOpsトランスフォーメーションのために考えるべき6つのこと

 

JFrogは、これらのニーズに対応するソリューションとしてクラウドを提供していますが（世界中の20以上の地域でパブリッククラウドプロバイダーに対応）ここではクラウド上でDevOpsデジタルトランスフォーメーションを行うために個々のベンダーに関して考慮すべき6つのことを以下にご紹介します。

 

—-エンドツーエンド—-

ポイントソリューションは1つまたは２つの特定の処理をこなすものです。しかしクラウド上のエンドツーエンドのDevOpsプラットフォームなら単一の戦略でランタイムまでサポートします。レガシーなDevOpsシステムを独自に統合し続ければ、やがてCI/CDまでもスパゲッティように複雑なソリューションを生み出すだけです。もっとシンプルでスピーディーなエンドツーエンドのソリューションにすべきです。重要なのは、ここにDevSecOps 機能の”セキュリティ”も含まれるということです。

 

今日の開発者はE2Eソリューションと「オールインワン」のユーザーエクスペリエンスを求めています。しかしこれは「ベストオブブリード」（最適）のアプローチを諦めることを意味するものではありません。従って真のDevOpsプラットフォームのプロバイダーは開発者が望む選択の自由を尊重しながら、非常に強力なエコシステムの統合やプラグインだけではなく、開発者の仕事を効率化するために必要となるクラスAのツールをプラットフォームの一部として提供する必要があります。

 

本当に使えるE2Eプラットフォームには単に統合されたツールをバンドルするのではなく、真の意味での「ワンブラウザ」ソリューションを可能にしようとするベンダーのコミットが必要です。これがあって初めてすべてのサービスを統合した「シングルUI」の価値をユーザーが享受することができるのです。

 

—-ユニバーサルパッケージ管理—-

みなさんが使う無数のテクノロジーに関わるメタデータと依存関係は、そのすべてがサポートされていなければなりません。Docker, npm, Maven, PyPi, Golang, NuGet, Conanに加えて、その他20以上の開発技術「すべて」です。単一または限定されたテクノロジーにしか対応していないポイントソリューションは、開発チームを苛立たせるだけでなく、やがては組織内でソリューションやリポジトリを複雑にします。大企業には無数のテクノロジーが使われ、多くのミッションクリティカルなアプリケーションの資産があるのです。そうしたもの全てをサポートできるローカル、リモート、バーチャルリポジトリこそが今必要なのです。

 

現代のDevOpsチームは組織全体をサポートし、より多くの人や物（有機的にも非有機的にも）を柔軟に受け入れ、すべてのバイナリタイプを扱える環境で作業できる必要があります。

 

—- 完全なハイブリッド: 完全に同じものが至る所に—-

これはクラウドソリューションがあるかどうかの問題ではありません。クラウドソリューションを提供している多くの企業は対応するオンプレミスセルフホスティングのオプションを持っていません。両方を提供しているとしても、完全に別個のソリューションで異なる機能や使い方を提供しており、クラウド版とオンプレミス版が互いにデータのやり取りができないため、結局は新しい製品やユーザー・エクスペリエンス、ユーザー・インターフェースの習得が必要になります。クラウド環境にスムーズに移行するには、クラウドとオンプレミスの両方が「完全に同じ」に動かなければなりません。例えばクラウド移行を行いながら現行のビジネスを止めないためには、クラウドとオンプレミス両方で同じツールや機能が必要です。これは想像以上に複雑で、同じコードベース、同じQAプロセス、同じアーキテクチャなどがクラウドとオンプレミスの環境間で必要となります。またアクセス可能な真のハイブリッドソリューションを実現するためには、複数のリージョンやクラウドをサポートしているプロバイダーが必要なのです。

 

—-マルチクラウド—-

JFrogの顧客のほとんどは、プロバイダの選択に関しては非常に明確なポリシーを持っています。それはDevOps環境とリモートIT ワークスペースを１つのクラウドだけにホスティングするリスクを取らないということです。多くの人は「１つのクラウドで十分」と思われるかもしれません。しかし選ぶべきなのは、すべての主要なクラウド間でサービスを提供しているベンダーです。１つのクラウドベンダーのロックイン（囲い込まれる事）を避け、もしもの時の回復力が担保できれば、選択肢が広がり安心感を保つことができます。この「DevOpsデモクラシー」アプローチこそ、真のDRセットアップを実現するために拡張可能な柔軟性のある環境を組織に提供することにもなるのです。

 

—-セキュリティ—-

DevSecOpsは単なる流行語ではありません。必須の要件なのです。すべてのパッケージタイプをサポートするパイプラインの統合された一部としてのセキュリティは今や多くの企業の「必須」項目となっています。シフトレフトはDevOps全体に影響するため、シンプルなツールの検討が必要です。例えばクラウドの DevSecOps ツールでは脆弱性を含むアーティファクトのダウンロードをブロックする（またはビルドを中断する）ことが可能であり、リポジトリに至るまでの完全な統合が必要ですセキュリティポリシーは、リポジトリ全体で簡単に定義・管理できるものでなければなりません。また、どのクラウドセキュリティ・ソリューションでもDevOpsパイプラインを通して脆弱性の影響を容易に特定できなければなりません。

 

DevSecOps で見過ごされがちなカテゴリーの 1 つに、オープンソース・ライセンスのコンプライアンスの問題があります。パッケージに脆弱性が含まれているだけでなく、ライセンスが検出できない問題が含まれている可能性もあります。ソリューションとしては両方のポリシーの検出と修正を提供する必要があります。

 

効率性と安心感を最大限に得る為に、これらのニーズをすべて満たし、IDEを含めた完全な可視性を備えたものである必要があります。

 

コンテナの世界はまた、課題をもたらします。DevSecOpsツールはあらゆるコンテナを「展開」してレイヤーのスキャンを行い、すべてのパッケージの脆弱性を含む依存関係を検出できなければなりません。これはバイナリリポジトリやアーティファクト管理ツールとの強力な統合によってのみ実現できます。

 

スキャニングソリューションは、その原動力となる脆弱性データと同程度の性能しか持ち合わせていません。クラウドでもセルフホスティングでも世の中で一般的に報告されている情報しか含まれていないデータベースでは十分ではありません。DevOpsプラットフォームは常にハッカーの先を行く努力をし、ビルドから本番環境までのパイプライン上にあるすべてのソフトウェアパッケージは安全である必要があります。

 

—-クラウド対応CI/CD—-

すべてのプロセスを一元化して合理化できる「スケーラブルなツール」は現代の必需品となっています。プロジェクトごとに管理したり、DevOpsパイプラインの数だけ自動化プロセスを作成するとチームは非効率化し、フラストレーションがたまるだけです。

 

従来、アプリケーション開発チームは自動化のために独自のCI/CDを作成する必要がありました。このアプローチは個々のチームには短期的な利益をもたらしますが、企業はCI/CD実装全体でスケールメリットを得ることができないため長期的には制約となってしまいます。

 

企業が異機種混在の最新アーキテクチャに向かい、より小さなデプロイメントユニットで迅速なリリースサイクルを実践し、マルチクラウド・トポロジへと移行するにつれてこの課題はより深刻なものとなります。現状、すべてのデプロイのために付け焼き刃的なカスタムスクリプトのパイプラインを構築し続けることは、スケーラブルなアプローチとは言えず、作成と維持にコストがかかる自動化処理を増やすだけで、結局は改善する際の障壁となってしまいます。

 

CI/CDプロバイダはあらゆる一般的な技術やアーキテクチャにまたがる企業全体のワークフロー（別名「ソフトウェア・サプライチェーン」）をサポートし、技術的な進化に対応する必要があります。パイプラインをゼロから開発するのではなく、あらかじめパッケージ化されたビルディング・ブロック（レゴのようなもの）からパイプラインを組み立てる方法を提供しなければなりません。これらのパイプラインはテンプレート化され、ライブラリとして組織全体で共有することができ、それにより拡張可能で、改善できるナレッジを構築することができます。言い換えれば、CI/CDプロバイダーはクラウド上での時間的なスケールメリットを提供し、コードをより速く提供できる手助けになるはずです。

 

クラウドベースのエンドツーエンドDevOpsソリューションの比較

今日我々が利用できるツールは無数にあります。それゆえ何が最適なのかを選択するのは試行錯誤の連続で時間とエネルギーを必要とするでしょう。 JFrogは現在、AWS、AzureおよびGCP上でクラウド版を提供していますので、開発者はエンドツーエンドのDevOpsパイプラインを柔軟に構築することができます。「特定のソリューションだけ」利用すると結局目標が達成できず失敗に終わる可能性があること、逆に完全に統合されたクラウドアプローチがお客様のニーズを完全に満たす可能性があることについて以下に具体的に説明しています。

 

ここでは現在の市場で利用可能な最も人気のある、あるいは身近なオプションをJFrogのソリューションと比較してみましょう。更には今後数週間のうちに、これらのソリューションを個別に掘り下げていきます。

 

—-JFrogとGitHubの比較—-

MicrosoftのGitHubはソースコード、（一部の）パッケージ管理、CI/CDパイプライン（GitHub Actionsと呼ばれる）を含むエンドツーエンドのソリューションを提供しています。GitHubはセルフホスティング型（GitHub Enterprise）よりもSaaSが強力です。セルフホストランナーのサポートは別として、GitHub PackagesとGitHub Actionsは自動セキュリティ更新機能と同様に、現在はSaaSのみ提供されています。しかしActionsとPackagesは基本的なAPIサポートしか提供しておらず、CLIはまだベータ版です。

リポジトリ管理では、Githubは普遍的なソリューションではなく、６つのパッケージタイプしかサポートしておらず（JFrog Platformは２５以上をサポート）、グローバル検索機能やバーチャル/リモートリポジトリのサポートもありません。セキュリティ機能はまだ未熟でアーティファクトやコンテナイメージの脆弱性を再帰的にスキャンしたり、ライセンスのコンプライアンス問題に対処したり、異なるアクションを引き起こすセキュリティポリシーを設定したりすることもできません。

最後に、GitHubのCI/CDソリューションはパイプラインの可視化をサポートしておらず、ソースコードリポジトリとパイプライン構成の間の緊密な結合は企業内でのスケーリングやパイプラインのチーム間/アプリ間のコラボレーションや共有を困難にしています。Docker層のキャッシングやCIノードのオートスケーリングの欠如はクラウドネイティブなデリバリーをさらに遅く、より面倒なものにしています。

GitHubはソースコード管理、OSSチームのコラボレーション、小規模なチームに最も強いと思われますが、エンタープライズでのデリバリーをカバーする機能はまだ提供されていません。

—-JFrogとAzure DevOpsの違い—-

同じくマイクロソフトのAzure DevOpsスイートはソースコード（Azure Repos）からアーティファクト管理（Azure Artifacts）、CI/CD（Azure Pipelines）まで、エンドツーエンドのソリューションを提供しています。また、チーム内での作業を計画してトラッキングするためのAzure BoardsやテストソリューションであるAzure Test Plansも利用可能です。

アーティファクト管理の観点から見ると、Azure DevOpsは4種類のバイナリやパッケージしかサポートしておらず、ソフトウェアの脆弱性やライセンスコンプライアンス違反をスキャンするための継続的なセキュリティソリューションは提供されていません。

Azure DevOpsはすべてのAzureサブスクリプションで無料で提供されるか、10個までのOSSプロジェクトの並列ジョブに対して提供されています。Azure PipelinesがAzureクラウドだけを標準化しているマイクロソフトのショップにとっては当然の選択かもしれませんが、ベンダーロックインを懸念している組織や将来のマルチクラウドやハイブリッド環境をサポートするための準備をしている（当然のことながら）組織にとっては大きな課題となるでしょう。

マイクロソフトのハイブリッド環境のサポートは不足しており、オンプレミス・セルフマネージド版にはSaaS版のコア機能の多くが欠落しています。セルフマネージド版は目立ったメンテナンスが行われておらず、頻繁にメンテナンスが行われていないのが現状です。

 —- JFrog vs AWS & JFrog vs GCP —-

AWSやGCPは質の高いインフラストラクチャやマーケットプレイスのプロバイダーとして認識されており、DevOps関連のサービスやツールを提供してはいるものの、それらのソリューションは統合された完全なDevOpsプラットフォームを提供することを目的としているわけではありません。AWSやGCPはデプロイ前の「最終段階」でのみ提供しており、DevOpsサイクルを横断するサービスの提供は念頭に置いていません。シンプルなコンテナレジストリや非常に基本的なCI/CDツールのようなポイントソリューションは用意されていますが、ハイブリッドオプションの欠如（または限定）、ソフトウェアパッケージのサポートの欠如、単一プロバイダーのロックインの可能性、エンタープライズ品質のビルトインDevSecOpsやセキュリティソリューションの欠如、拡張メタデータの欠如、ソフトウェア配布ソリューションの欠如など、フルスコープのDevOpsプロバイダーを探す企業は戸惑いを禁じ得ないでしょう。

 

特筆すべきはAWSもGCPもユニバーサルパッケージのサポートはおろか、開発者向けのパッケージマネージャをも提供していないことです（どちらも現在はシンプルなコンテナレジストリーのみを提供しており、HelmやGeneric、バーチャルリポジトリ、リモートリポジトリの機能はサポートしていません）。高度なレプリケーション機能とグローバルなディストリビューション機能を備えたユニバーサル、ハイブリッド、エコシステム統合型パッケージマネージャは今日のDevOpsを実践する企業、コンテナ、Kubernetes、アーティファクトライフサイクル全体の管理に注目している企業にとって必要不可欠です。そう考えればAWSもGCPも多くの点で不十分であることが分かります。

 

主要なクラウドプロバイダーの提供するDevOpsソリューションはつまるところ自社のクラウドサービスをより多く利用してもらうことが目的であり、汎用的なサービス（メッセージング、データベース、APIゲートウェイ、ストレージなど）との統合に重点を置いているのです。そのため、コードから本番までの真のエンドツーエンドのパイプラインを実現するためには多くのタスク（ワークフロー、メタデータ、可視性などに関して）はユーザーに依然として負担しています。こうした理由がクラウドプロバイダーから提供されているDevOpsツールの成熟度や品質にも影響を与え、結果として非常に基本的なレベルに留まっているのです。

 

結論から言えばAWSもGCPも本当に使えるエンドツーエンドのDevOpsソリューションやオーケストレーション、パイプライン管理ツールを提供していません。このため多くの企業はサードパーティに依存したりツールのギャップを自社で埋めたりすることになり、結果的にスケーラブルからは程遠いソリューションとなってしまいます。

 

クラウドマーケットプレイスを介してエンドツーエンドのソリューションを提供するJFrogのような企業とクラウドプロバイダー間のパートナーシップを多くの企業は活用しています。

 —- JFrogとGitLabの比較 —-

主にGITソリューションとして知られるGitLabはDevOpsプラットフォームではなく、単一リージョンの単一プロバイダ（GCP）のみに限定されたSaaSサービスです。そのため、技術的には利用できるものの企業はこのような限定されたものを採用するのは難しいと感じるでしょう。またSLAの保証も明言されておらず、企業にとっては安心感に欠けるものとなっています。GitLab のセキュリティサービスはまだまだ黎明期にあり（改善されつつありますが）、ミッションクリティカルなワークロードのための堅牢なソリューションを探している企業にとっては疑問符がつきます。さらに、複数のSCMツールを持つことは非常に一般的なことであるにも関わらず、ソース管理ツールが異なる企業にとってGitLabはその自由を制限している可能性があります。GitLabソリューションがクラウドに移行し、複数のテナントが単一のデータベースリソースを共有するようになると問題はさらに深刻になり、スケーリングやパフォーマンスの問題が発生してきます。

GitLabの強みは主にオンプレミスにあり、クラウドの選択肢は非常に限られています。堅実なプラットフォームではありますが、エンタープライズクラウドのスケーラビリティ、ハイブリッド機能、SLAの保証、SCMの互換性などの面では物足りなさを感じます。

さらに、開発者が必要とする多くのパッケージタイプはGitLabではサポートされていないため、さまざまなプロジェクトをサポートするためのツールが必要になります。これは決して小さな問題ではなく、企業の最も重要なニーズの一つである、無数の言語、システム、パートナー、テクノロジーの種類を同時に大規模にサポートしなければならないという条件を満たしていません。GitLabのデモを見ると「初歩的な」パッケージマネージャを提供する一方で、パッケージ管理の分野ではJFrogがリーダーであることを認めています。JFrog Artifactoryのようなパッケージ/バイナリマネージャはDevOpsパイプラインの心臓部として企業がエンタープライズレベルでスケールすることを可能にし、カスタマイズと自動化を行い最も要求の厳しいSLAを効果的に満たすことを可能にする極めて重要な技術です。グローバルな多くの企業は効率的なレプリケーション、複数のキャッシングオプション、複数のリポジトリタイプ（ローカル、バーチャル、リモート）、リッチで検索可能なメタデータなどをサポートするハイブリッドなマルチクラウドツールを必要としています。

また、GitLabのプラットフォーム強化戦略は主要な機能の追加でさえ外部からのリソースに頼っているようです。その結果、コアチームの外から追加された機能が長期的なプラットフォームのロードマップやビジョン、エンタープライズ対応を困難にしているのです。

GitLab製品のアーキテクチャ自体、単一のサーバーに依存しています。このサーバーはI/Oやデータベースの負荷、リクエストのキャッシングとスループット、処理能力、可用性など、システム要件が大きく異なるDevOpsツールをサポートしなければなりません。

I/O集約的でリクエスト率が高く、ダウンタイムゼロのサービス（エンタープライズ・バイナリマネージャのようなもの）とレポート/データ表示に焦点を当てたサービス（課題管理、wiki、コードレビュー、リクエスト追跡など）を混在させると、これらのサービスが同じリソース上で競合するため、複雑なスケールとパフォーマンスの問題が発生することがよくあります。

最後に、SaaSにマルチクラウド機能がないことはクラウド間でのスケールアップやプロバイダのロックインを避けたいと考えている企業にとっては懸念材料になるかもしれません。

 

結局まとめると？

JFrogが信じる真のDevOpsクラウドソリューションとは全てを兼ね備え、全てのクラウド上にあり、全ての開発者の環境に適用可能であるべきだと考えています。開発者がどこにいても開発できるようにするには、このような高いレベルの柔軟性と堅牢性こそが求められます。しかしこれはあくまでもJFrogのブログで当社独自の調査と解釈に基づいています。このトピックに関する皆さんのコメントやご意見をお待ちしています。