ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
位置データのベンダーを比較するためのシンプルなコストモデル
位置データのベンダーを、公表されているリクエストあたりの価格だけで比較するのはよくある単純化ですが、それでは実際のコストの多くを見落としてしまいます。そのため、現在のプロバイダーを使い続けるにせよ、新しいプロバイダーに移行するにせよ、決定を下す前に、もう少し完全なモデルを作っておく価値があります。
より完全なコストモデルには、それぞれ個別に見積もるべき要素が少なくとも4つあります:
リクエストの直接コスト。ベンダー比較の多くは、この数字から始まり、この数字で終わります。リクエストあたりの料金、月額サブスクリプションのプラン、あるいは無料割り当ての上限です。重要ではありますが、全体の一部にすぎません。
連携と保守にかかるエンジニアリングの時間。かなりの量の独自の解析コードが必要なレスポンス形式のプロバイダーは、コードがすでに理解している形式のプロバイダーよりも、エンジニアリングの工数が多くかかります。そしてそのコストは、導入時の1回だけでなく、連携の保守が必要になるたびに繰り返し発生します。互換性に基づくアプローチは、まさにこの要素を減らします。なじみのある形式に合わせたホストであれば、連携の期間全体を通じて構築し保守しなければならない独自の解析作業が少なくて済むからです。
移行のコスト(実際のものと潜在的なものの両方)。ベンダーのレスポンス形式が独自で一般的でない場合、後からそこを離れるときには、自らの選択であれ、ベンダーが条件を変更したためであれ、標準的な形式や互換ホストがすでに再現している形式のベンダーから移行する場合よりも、解析ロジックの書き直しに多くのコストがかかります。現時点で移行の予定がなくても、これは実際のコストです。将来の交渉や、やむを得ない変更の際の立場に影響するからです。
運用のオーバーヘッド。割り当ての監視、レート制限エラーへの対応、リトライのロジックの構築に費やす時間は、すべてエンジニアリングの時間を消費します。また、プロバイダーによって、この情報を(たとえばレスポンスヘッダーを通じて)直接公開しているか、それとも把握するために追加のポーリングやアカウントのダッシュボードの確認が必要かが異なります。
このモデルを具体的にMy Geocodeに当てはめてみます。リクエストの直接コストは一律でシンプルです。キーなしで1日あたり2,500件の無料リクエスト、さらにキーごとに1日あたり2,500件の無料リクエスト(ネットワーク単位でカウント)があり、その後は1リクエストあたり€0.0001のプリペイドクレジット、または月額€50のUnlimitedキーとなります。どのエンドポイントを呼び出しても料金はすべて同じです。エンジニアリングと移行のコストには、/compatibility/に一覧がある17個の互換ホストが直接対応します。これらは、解析コードを新たに覚えて保守しなければならない新しい形式を持ち込むのではなく、なじみのあるプロバイダーの形式を正確に再現します。運用のオーバーヘッドは、割り当ての情報がすべてのレスポンスにヘッダーとして直接含まれていること(X-Quota-Limit、X-Quota-Used、X-Credits-Remainingなど、/docs/rate-limits/で説明しています)によって減り、別途ダッシュボードを確認する必要がありません。
この4つの要素からなるモデルを、分かっている部分は実際の数字で、分からない部分は正直な見積もりで、大まかにでも作ってみると、目立つリクエストあたりの料金だけを比較するよりも、意味のある形でより良い判断ができます。エンジニアリングの時間と将来の柔軟性を正直に計算に入れると、書面上で最も安い料金が、常に最も安い連携になるとは限りません。