Estimación del coste de la sustitución de una API de terceros

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 radica en que las peculiaridades de la API antigua 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» o «esto limita el ancho de banda de forma silenciosa». Un cambio limpio implica reproducir cada una de esas peculiaridades adaptándolas al comportamiento del nuevo proveedor, que difiere en aspectos que nadie ha documentado.

El presupuesto debe tener en cuenta el funcionamiento paralelo: el proveedor antiguo y el nuevo funcionando al mismo tiempo, con una 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 al día cada una».

Titular: «¿Qué ocurre con los datos históricos que tienen en nuestro poder?»

SRE: «¿Vamos a tener 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: «¿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 realizar una conversión?
• Período de funcionamiento simultáneo: ¿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 serán iguales o diferentes?
• ¿Es posible dar marcha atrás si resulta que el nuevo proveedor es peor?

Las llamadas básicas son sencillas; lo complicado es la demostración de equivalencia. Si tanto la ejecución dual como el traslado de datos son reales, eso supone más de una tarea: sepárelas y evalúe la verificación por separado de la implementación.

Prevea un presupuesto para la ejecución dual y la comprobación de equivalencia. La API, con un aspecto limpio, es la parte más económica.

Al igual que en la estimación de una migración de bases de datos, el código se desarrolla rápidamente y el trabajo reside en la implementación. Consulte los demás ejemplos de estimaciones resueltos o inicie una sesión gratuita de «planning poker» una vez esbozado el plan de ejecución dual.