Compatibilidad retroactiva y estabilidad de las API de AWS - La confianza que genera la política de no deprecar APIs publicadas
Explicamos el historial de AWS de mantener su política de no deprecar APIs una vez publicadas, comparándolo con los cambios de marca de Azure y los casos de discontinuación de servicios de GCP, y por qué la estabilidad de las API es importante para las empresas.
La estabilidad de las API es sinónimo de estabilidad de la infraestructura
Construir sistemas sobre servicios en la nube significa depender de las API de esa nube. Si las API cambian, todos los sistemas construidos sobre ellas se ven afectados. La deprecación o los cambios disruptivos en las API obligan a modificar aplicaciones, re-ejecutar pruebas y replanificar despliegues, lo que significa costos y riesgos inesperados para las empresas. AWS ha mantenido desde su fundación la política de no deprecar APIs una vez publicadas. Las API básicas de S3 publicadas en 2006 (PutObject, GetObject, DeleteObject) siguen funcionando exactamente igual en 2025. Las nuevas funcionalidades se añaden como nuevos endpoints o parámetros de API, y las API existentes no se modifican. Esta política se ha mantenido consistentemente incluso ahora que los servicios de AWS superan los 200.
El valor práctico que aporta mantener la compatibilidad retroactiva
El valor práctico de mantener la compatibilidad retroactiva de las API suele pasarse por alto, pero es extremadamente significativo. En primer lugar, se reducen los costos de mantenimiento de sistemas existentes. Si las API no cambian, no hay necesidad de modificar sistemas que están funcionando. El proveedor de nube garantiza la regla operativa de "no tocar lo que funciona". En segundo lugar, protege las inversiones a largo plazo. El código invertido en automatización de infraestructura cloud como plantillas de CloudFormation, código CDK, configuraciones de Terraform y pipelines CI/CD no corre el riesgo de quedar obsoleto por cambios en las API. En tercer lugar, se suprime la deuda técnica. El trabajo de modificación para seguir los cambios de API es un tipo de deuda técnica que no genera nuevo valor. La política de compatibilidad retroactiva de AWS previene estructuralmente la generación de este tipo de deuda. En cuarto lugar, permite actualizaciones planificadas. Aunque se añadan nuevas API o funciones, las API existentes siguen funcionando, por lo que el momento de la migración se decide según la conveniencia propia. No hay actualizaciones forzadas por conveniencia del proveedor.
Los cambios de marca de Azure y la evolución de sus API
Azure tiene una historia diferente a AWS en cuanto a estabilidad de API. En los inicios de Azure se usaba un sistema de API llamado Azure Service Management (ASM), pero en 2014 comenzó la migración a Azure Resource Manager (ARM), y ASM fue deprecado gradualmente. Esta migración requirió la reescritura de scripts y herramientas existentes, afectando a muchos usuarios. Los cambios de nombre de marca en Azure también son frecuentes. El cambio de Windows Azure a Microsoft Azure (2014), de Azure Active Directory a Microsoft Entra ID (2023), y el cambio de nombre desde Visual Studio Team Services, predecesor de Azure DevOps, entre otros, son cambios de nombre de servicio y marca que se han repetido. Los cambios de nombre de marca son diferentes de los cambios disruptivos de API, pero requieren actualizar documentación, materiales de formación y bases de conocimiento internas, causando confusión operativa. El versionado de API de Azure también es complejo. Las API de ARM se proporcionan con versiones, pero a veces se establecen fechas límite de soporte para versiones antiguas, requiriendo actualizaciones periódicas de versión.
La historia de discontinuación de servicios de GCP
La preocupación sobre la estabilidad de las API de GCP tiene sus raíces en la historia de "discontinuación de servicios" de Google en general. Google ha discontinuado numerosos servicios orientados al consumidor como Google Reader (2013), Google+ (2019) y Stadia (2023). Esta cultura de "discontinuar servicios que no se usan" también ha influido en GCP. En GCP, Cloud IoT Core fue discontinuado en 2023. Los clientes que usaban IoT Core se vieron obligados a migrar a servicios alternativos. Cloud Domains también anunció su discontinuación en 2024. GCP ha mejorado recientemente, clarificando su política de discontinuación y estableciendo períodos de notificación previos para ganar la confianza de clientes empresariales. Sin embargo, la percepción de que "Google discontinúa servicios" persiste y es un factor de preocupación cuando los tomadores de decisiones empresariales seleccionan plataformas cloud. En AWS, la discontinuación de servicios es extremadamente rara. Mantienen la política de preservar servicios con poco uso mientras existan clientes. Esta política tiene costos a corto plazo, pero a largo plazo construye la confianza de que "si eliges AWS, los servicios no desaparecerán repentinamente".
Ingeniería de diseño para mantener la compatibilidad retroactiva
Mantener la compatibilidad retroactiva de las API durante largos períodos no es técnicamente fácil. Detrás de la capacidad de AWS para lograrlo hay varias técnicas de diseño. En primer lugar, la cautela en la fase de diseño de API. Mediante el proceso Working Backwards, el diseño de API se realiza calculando hacia atrás desde los casos de uso del cliente. Al realizar una consideración suficiente antes del lanzamiento, se reduce la necesidad de cambiar la API porque "el diseño fue incorrecto". En segundo lugar, el diseño con extensibilidad como premisa. Se diseña para que los clientes existentes puedan ignorar nuevos campos añadidos a las respuestas de API. Los nuevos parámetros se añaden como opcionales con valores predeterminados. En tercer lugar, la estrategia de versionado. Cuando se necesitan cambios disruptivos, se proporcionan como nueva versión de API manteniendo la versión anterior en paralelo. Los clientes pueden migrar a la nueva versión a su propio ritmo. Estas técnicas son efectivas combinadas con la autonomía de los Two-Pizza Teams. Cada equipo tiene responsabilidad completa sobre la API de su servicio e internaliza el mantenimiento de la compatibilidad retroactiva como estándar de calidad propio. Para aprender las mejores prácticas de diseño de API, los libros relacionados (Amazon) también son una referencia útil.
Resumen
La política de compatibilidad retroactiva de AWS se ha mantenido consistentemente durante más de 18 años desde la API de S3 en 2006, proporcionando valor práctico como la reducción de costos de mantenimiento de sistemas existentes, la protección de inversiones a largo plazo y la supresión de deuda técnica. Azure tiene desafíos en la estabilidad de API debido a la migración de ASM a ARM y los frecuentes cambios de nombre de marca. GCP, influenciado por la cultura de "discontinuación de servicios" de Google, tiene casos que dañan la confianza empresarial como la discontinuación de IoT Core. En la selección de plataformas cloud, la estabilidad de las API y la compatibilidad retroactiva son factores que deben valorarse igual o más que la riqueza de funcionalidades.