Estimación del coste de la sustitución de una API de terceros
Cómo evaluar la sustitución de una API de terceros: lagunas semánticas, ejecución simultánea y los supuestos implícitos en las peculiaridades del antiguo proveedor. La nueva API solo parece idéntica.
La API del nuevo proveedor parece idéntica hasta que se empieza a migrar los datos.
El argumento para cambiar de proveedor es siempre el mismo: la nueva API es más limpia, más rápida y más económica. La trampa reside en que las peculiaridades de la antigua API son fundamentales para el funcionamiento del sistema. El código fuente acumula dos años de «esto es una cadena, pero en realidad es una fecha en su formato», «esto devuelve null cuando en realidad significa cero», «esto limita el caudal de forma silenciosa» — y un cambio limpio implica reproducir cada una de esas peculiaridades adaptándolas al comportamiento del nuevo proveedor, que es diferente en aspectos que nadie ha documentado.
El presupuesto debe tener en cuenta la fase de funcionamiento paralelo: el proveedor antiguo y el nuevo funcionando simultáneamente, con comparación de resultados, hasta que el equipo tenga la certeza de que el nuevo ofrece los mismos resultados. Esa fase suele ser más larga que la propia implementación. Los proyectos que no lo tienen en cuenta en su presupuesto implementan el nuevo proveedor y descubren las deficiencias la próxima vez que los datos de un cliente se enfrenten a un caso extremo.
Lo que se dice en la sala
Backend: «El nuevo SDK es mejor. Las llamadas básicas se realizan una vez al día cada una».
Entrada: «¿Y qué hay de los datos históricos que tienen almacenados para nosotros?»
SRE: «¿Vamos a mantener ambos proveedores en funcionamiento al mismo tiempo o vamos a realizar la transición?»
Backend: «Su formato de webhook es diferente. Lo mismo ocurre con la autenticación».
Pregunta de control de calidad: «¿Cómo verificamos la equivalencia? ¿Comparando las respuestas a lo largo de una semana?»
Preguntas que conviene plantearse antes de votar
- ¿Hay datos históricos en el antiguo proveedor que debamos conservar?
- Diferencias en la autenticación: ¿claves API, OAuth, solicitudes firmadas?
- Webhooks: ¿se asignan los eventos de forma clara o es necesario traducirlos?
- Período de funcionamiento paralelo: ¿cuánto tiempo dura y qué se considera «suficientemente bueno» para realizar la transición?
- ¿Los límites de tarifa y el modelo de precios del nuevo proveedor son iguales o diferentes?
- ¿Se puede dar marcha atrás si el nuevo proveedor resulta ser peor?
Las llamadas básicas son sencillas; lo complicado es la demostración de equivalencia. Si tanto la ejecución dual como el movimiento de datos son reales, eso ya es otra historia: divídalas y evalúe la verificación por separado de la implementación.
Presupueste la ejecución dual y la comprobación de equivalencia. La API de aspecto limpio es la parte más económica.
Al igual que la estimación de una migración de base de datos, el código se elabora rápidamente y lo que requiere esfuerzo es la puesta en marcha. Consulte los demás ejemplos prácticos de estimación, o inicie una sesión gratuita de Planning Poker una vez esbozado el plan de ejecución dual.