Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Lo que depender de un solo proveedor pequeño enseña sobre el riesgo de proveedor
Una única dependencia de API es fácil de pasar por alto precisamente porque funciona sin hacer ruido durante mucho tiempo. Una llamada de geocodificación que ha devuelto resultados correctos todos los días durante dos años no parece un riesgo; parece un problema resuelto. El riesgo solo se hace visible el día en que algo cambia por parte del proveedor, un endpoint descatalogado, una reestructuración de precios, la adquisición de la empresa o simplemente una caída del servicio, y para entonces el coste de no tener una alternativa preparada ya se está pagando con prisas en lugar de con una migración planificada.
Los proveedores pequeños conllevan este riesgo de forma más aguda que los grandes, no porque sean menos fiables en el día a día, sino porque normalmente tienen menos redundancia en sus propias operaciones y un modelo de negocio más sensible a la marcha de cualquier cliente grande o a cualquier cambio de financiación. No es una crítica a ningún proveedor pequeño en concreto; es un hecho estructural del tamaño de la empresa que se aplica a muchos servicios por lo demás excelentes.
La lección práctica no es necesariamente evitar a los proveedores pequeños. Es construir una arquitectura que no dé por hecho que ningún proveedor es permanente, sea cual sea su tamaño. Algunos hábitos concretos ayudan:
- Mantén la lógica específica del proveedor detrás de una interfaz interna en tu propio código, de modo que una función de análisis lea de tu propia estructura de datos normalizada y no directamente de los nombres de campo de un proveedor concreto repartidos por todo el código
- Comprueba periódicamente que tu integración podría moverse de verdad, aunque no tengas previsto moverla pronto, ya que una suposición de portabilidad sin probar no es lo mismo que una portabilidad real
- Lleva la cuenta de lo que costaría una migración completa en tiempo de ingeniería como un conocimiento institucional permanente, no como algo que se calcula por primera vez en plena crisis
Un enfoque basado en la compatibilidad cambia algo este cálculo, porque reduce la parte del coste de migración que reside en tu propio código de análisis. My Geocode ofrece 17 hosts compatibles que reproducen exactamente la forma de las solicitudes y respuestas de los principales proveedores, como Google Maps Platform, Mapbox, HERE, ipstack y otros, documentados en /compatibility/, lo que significa que la parte más arriesgada de una migración forzada, reescribir la lógica de análisis con prisas, a menudo se puede evitar si el proveedor que dejas ya tiene disponible un host compatible equivalente.
Dicho esto, la lección de fondo sobre el riesgo de proveedor se mantiene sea cual sea el proveedor o la plataforma que uses, incluida esta: la situación más sana es aquella en la que cambiar es una opción real y probada, no teórica. Hacer una pequeña prueba con un proveedor alternativo antes de necesitarlo, aunque sea con una fracción de tu tráfico, convierte el riesgo de proveedor de una preocupación abstracta en una capacidad concreta y ensayada. Probarlo cuesta relativamente poco, y el beneficio solo se ve el día en que realmente lo necesitas.