ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
小規模なプロバイダー1社に頼ることからわかるベンダーリスク
単一のAPIへの依存は、長いあいだ静かに動き続けるからこそ見落とされがちです。2年間毎日正しい結果を返してきたジオコーディングの呼び出しは、リスクには感じられません。解決済みの問題のように感じられます。リスクが目に見えるようになるのは、エンドポイントの提供終了、料金体系の再編、企業の買収、あるいは単なるサービス障害など、プロバイダー側で何かが変わった日だけです。そしてその時点では、代替手段を用意していなかったことのコストを、計画的な移行ではなく慌ただしい対応という形で、すでに支払い始めています。
小規模なプロバイダーは、大規模なプロバイダーよりもこのリスクをより強く抱えています。日々の信頼性が低いからではなく、一般的に自社の運用における冗長性が少なく、大口顧客1社の離脱や資金調達の変化に対して、ビジネスモデルがより敏感だからです。これは特定の小規模プロバイダーへの批判ではありません。他の点では優れた多くのサービスにも当てはまる、企業規模に関する構造的な事実です。
実践的な教訓は、必ずしも小規模なプロバイダーを避けることではありません。規模にかかわらず、どのプロバイダーも永続的だとは想定しないアーキテクチャを構築することです。いくつかの具体的な習慣が役立ちます。
- プロバイダー固有のロジックは自社のコード内の内部インターフェースの背後に置き、解析関数が、コードベース全体に散らばった特定のプロバイダーのフィールド名から直接読み取るのではなく、自社で正規化したデータ構造から読み取るようにする
- 近いうちに移行する予定がなくても、連携が実際に移行できることを定期的にテストする。テストされていない移植性の想定は、本当の移植性と同じではないため
- 完全な移行にエンジニアリングの時間でどれだけのコストがかかるかを、危機のときに初めて計算するものではなく、組織の常設の知識として把握しておく
互換性に基づくアプローチは、移行コストのうち自社の解析コードに含まれる部分を減らすため、この計算をいくらか変えます。My Geocodeは、Google Maps Platform、Mapbox、HERE、ipstackなどの主要プロバイダーのリクエストとレスポンスの形をそのまま再現する17の互換ホストを運用しており、/compatibility/で説明しています。つまり、離れようとしているプロバイダーに対応する互換ホストがたまたますでに利用可能であれば、強制的な移行で最もリスクの高い部分、つまり時間に追われながら解析ロジックを書き直す作業は、多くの場合避けられるということです。
とはいえ、ベンダーリスクについてのより深い教訓は、このプラットフォームを含め、どのプロバイダーやプラットフォームを使うかにかかわらず当てはまります。最も健全なのは、乗り換えが理論上の選択肢ではなく、実際にテスト済みの選択肢になっている状態です。必要になる前に、たとえトラフィックのごく一部であっても、代替プロバイダーに対して小規模な試行を実施しておけば、ベンダーリスクは抽象的な不安から、具体的でリハーサル済みの能力に変わります。テストにかかるコストは比較的小さく、その見返りは実際に必要になった日にだけ現れます。