Amazonは先頃OpenSearch 1.0の一般提供を発表した。これは、ElasticがElasticsearchのライセンスを変更した後に作成されたApache 2.0ライセンスのフォークだ。
OpenSearchは、派生元のバージョンであるElasticsearch 7.10.2との互換性を提供する。GAバージョンでは、ARM64アーキテクチャのサポート、OpenSearchとOpenSearchダッシュボードを既存の製品やサービスに埋め込むためのアーティファクト、OpenSearchダッシュボードのデータストリームサポートなどのベータ以降のいくつかの機能強化が追加されている。
Amazonはフォークを開始して保守しているが、プロジェクトに参加している企業は同社だけではない。GAの発表に伴い、AWSのシニア開発者アドボケイトであるKyle Davis氏がTwitterでスレッドを開始した。このスレッドでは、Bitergia、Logz、Bonsaiなどのプロジェクトに参加した企業からのプレスリリースとコメントが含まれている。
MontyCloudのエンジニアリングのディレクターのSumant Dubey氏は追記している:
OpenSearch - ElasticSearchから派生したAWSが主導するコミュニティ駆動の検索および分析ソリューションが今GAです。重要なことをチームは述べています。 -「プロプライエタリなコードや参照がないことを確信して、OpenSearchを使用できるようになりました」
「OpenSearchとは」のページで、Elasticは、AWSマネージドサービスであるAmazon ElasticsearchはElasticsearchの現在または将来のリリースを提供せず、移行がより困難になるだろうと主張している:
Amazon Elasticsearch Serviceは、Elasticsearchの古いバージョンに基づいています (...) Amazonのサービスを継続することを選択した顧客は、ElasticsearchとKibanaに提供されるパッチとパフォーマンス強化の恩恵を受けなくなります。さらに、顧客のプレミスおよび他のクラウドでのElasticsearchのデプロイメントは、Amazonのサービスと同じではなくなります。
オープンソースのOpenSearchプロジェクトとAmazonマネージドサービスに大きな違いがあることも、Elasticは強調する:
現在、Amazonサービスには、オープンソースでは利用できない独自の機能がいくつか含まれています。これには、AWS UltraWarmやAuto-Tuneなどの最近の発表が含まれます。これらは、フォークされたオープンソースプロジェクトでは利用できないプロプライエタリな機能です。これは今後も当てはまると予想され、AmazonサービスはOpenSearchプロジェクトと同じではなくなるでしょう。
別の記事で、OpenSearchプロジェクトの背後のAmazonの開発者は、クライアントと一緒にフォークした理由を説明している:
アプリケーションでElasticsearchとOpenSearchを使用する多くの開発者は、Elasticが保守するオープンソースのクライアントライブラリも利用しています (...) 過去数週間にわたって、ElasticはこれらのクライアントのいくつかにOpenSearchクラスタやElasticsearch 7のオープンソースディストリビューションを実行しているクラスタへの接続を拒否する新しいロジックを追加しました。これにはElastic自体が提供するものも含まれます。
ユーザのBuckwhal氏は、Redditで新しいプロジェクトを成功させるには、新機能よりも安定性の方が重要であると示唆している:
私が知りたいのは、多くの安定性とパフォーマンスの修正です。パッチを簡単にしてください。最初に「退屈で安定している」とマークされたフォークが私が使用するものになります。このように考えてください。Postgresが2つのフォークに分割され、1つはジャンク機能の追加を開始し、もう1つは信頼性と成熟度に重点を置いた場合、どちらを選択しますか? 開発のペースは、機能クリープ以上のものを意味しなければなりません - それは成熟を意味しなければなりません。
OpenSearchのオープンソースの視覚化ダッシュボードであるOpenSearchとOpenSearch-Dashboardsの両方が、プロジェクトのロードマップを含めてGitHubで利用可能だ。GAパッケージは、OpenSearchサイトからダウンロードできる。