AWSは、Amazon AppFlowをAWSプラットフォームサービスとSalesforce、Zendesk、ServiceNowなど他の頻繁に使用されるサービスとしてのソフトウェア (SaaS) ベースのアプリケーションのデータと統合した「ノーコード」、「ローコード」サービスとして発表した。
エンタープライズデータは複数の「SaaSアイランド」に散在していることが多いのが現実であり、この分散型データは、包括的なレポートやその他の理由で一元化された場所に収集する必要がある。情報を手動で抽出してマージする、またはカスタムコネクタを作成することは、多くの場合、費用がかかり、保守が面倒である。
Amazon AppFlowは、AWSプラットフォームとさまざまなSaaSプラットフォーム間の双方向の統合である。これは、SaaSアプリケーション管理者、ビジネスアナリスト、BIスペシャリスト、およびその他の同様の役割が、数回のクリックでこれらの統合を実装できるようにし、コードを最小限に抑えてこれらのフローをスケジュールできるようにすることを目的としている。さらに、AWS PrivateLinkを活用することで、データを暗号化して移動させることができる。
Amazon AppFlowは、サービスとしての統合プラットフォーム (iPaaS) と呼ばれるツールと同じリーグに属し、他の多くのサービスの機能であるオーケストレーションやワークフローのない線形データ処理パイプラインを提供していることは注目に値する。
InfoQは、発表の詳細について、Amazon Web Services (AWS) のAWSプラットフォーム担当副社長であるKurt Kufeld氏に話を聞いた。
Kurt Kufeld氏は、統合サービスが、データを手動で収集したり、通常は高価でエラーが発生しやすいカスタムコネクタを作成したりすることの背景にある苦痛をどのように軽減することが期待されるかについて話した。彼は、サービスの対象者、主にローコード開発者とノーコード開発者を強調した。彼はまた、さまざまなSaaSプラットフォームをAWSと統合するための技術要件とデータ要件のいくつかにも触れた。
InfoQ: Amazon AppFlowとは何でしょうか ? これはどのような問題点を解決するのでしょうか ?
Kurt Kufeld氏: Amazon AppFlowは、 数回クリックするだけの、Salesforce、Marketo、Slack、ServiceNowなどのサービスとしてのソフトウェア (SaaS) アプリケーションと、Amazon S3やAmazon RedshiftなどのAWSサービス間でデータを安全に転送できるようにするフルマネージド統合サービスです。
多くの場合、顧客は数十のSaaSアプリケーションにデータを保存しているため、サイロが切断されます。組織はこれらのソースからのデータを組み合わせることができることを望んでいますが、そのためには、顧客はコードを記述してカスタムコネクタとデータ変換を構築し、さまざまなSaaSアプリケーション間で異なるデータ型と形式を変換する必要があります。
複数のSaaSアプリケーションを使用している顧客は、膨大な数のコネクタと複雑なコードを使用することになり、保守に時間と費用がかかります。さらに、カスタムコネクタは、大量のデータやほぼリアルタイムの転送に合わせて拡張することが難しい場合が多く、SaaSでデータが利用可能になってから他のシステムがデータにアクセスするまでに遅延が発生します。
大企業では、ビジネスユーザは、熟練した開発者がカスタムコネクタを構築するのを数か月待ちます。社内の開発者スキルが限られている企業では、ユーザはシステム間でデータを手動でアップロードおよびダウンロードすることに頼っています。これは面倒でエラーが発生しやすく、データ漏洩のリスクがあります。Amazon AppFlowは、これらの問題点に具体的に対処します。
InfoQ: このサービスは「ノーコード」または「ローコード」開発者を対象としていますか ? 従来の開発者/アーキテクトも興味を持つ必要があるのでしょうか ?
Kufeld氏: Amazon AppFlowには、基幹業務のユーザが独自の統合を非常に簡単に構築できるようにするノーコードインターフェースがあります。従来の開発者は、自動化と使いやすさの恩恵を受けることもできます。これにより、AppFlowが提供するすぐに使用できる統合機能を活用して生産性を向上させ、アプリケーションの構築に集中できます。同様に、アーキテクトはAppFlowを活用して、さまざまなアプリケーションやサービスを簡単に接続し、カスタムコネクタの構築に必要な差別化されていない手間のかかる作業を回避できます。
InfoQ: 他のSaaSアプリと統合できるようにするためのエンドポイントとデータの要件 (ある場合) は何でしょうか ? つまり、たとえば、JSON形式で利用できるようにRESTエンドポイントとデータが必要でしょうか ?
Kufeld氏: このコネクタは非常に柔軟です。現在サポートしているコネクタの大部分は、サポートしているアプリケーションとサービスのREST APIエンドポイントとインターフェイスします。ただし、JDBCコネクタを介してデータウェアハウス (Amazon RedshiftおよびSnowflake) に接続します。データのJSON形式とCSV形式の両方を処理でき、これらの機能を絶えず拡張しています。
InfoQ: 関連する質問ですが、パフォーマンス/しきい値の懸念の対象となる可能性があるため、統合に関する推奨事項/ベストプラクティスを作成するのでしょうか ?
Kufeld氏: AppFlowは、あらゆる規模のデータフローをサポートするように簡単に拡張できますが、ソースおよび宛先としてサポートするアプリケーションは、転送できる最大ボリュームに制限を課したり、API呼び出しにボリュームまたはレート制限を設定したりすることがよくあります。AppFlowデータ転送はこれらの制限にカウントされるため、AppFlowを使用して統合するアプリケーションによって課せられるデータ転送制限に注意することをお勧めします。通常、すべてのデータ転送が組織によって設定されたアクセスポリシーに準拠していることも確認する必要があります。
InfoQ: 箱から取り出してすぐに多くの統合があります。他の計画された統合とAmazon AppFlowのロードマップについて言えることはありますでしょうか ?
Kufeld氏: 現時点では、今後のロードマップ計画について話すことはできません。
要約すると、Kufeld氏は、Amazon AppFlowが解決することが期待される問題点、統合サービスの対象者、および統合の要件のいくつかについて話した。彼は特に、サービスのロードマップや計画されている将来の統合については触れなかった。サードパーティの開発者またはインテグレータが、AppFlowサービスの一部として他のSaaSプラットフォームへの統合を開発できるかどうかは不明である。
詳細はドキュメントにあり、関連するAWSブログの投稿では、スケジュールに従ってSlackからS3バケットへのデータフローを作成する例と、他のAWSサービスを活用してSlackチャネルデータのワードクラウドを生成する方法の例について説明している。