DevOps

Leyendo el futuro de AWS a 3 años desde los anuncios de re:Invent - El ciclo de vida de los servicios y las leyes de la discontinuación

Enfrentamos el hecho de que los servicios de AWS también tienen vida útil, como la suspensión de nuevas inscripciones de CodeCommit y el fin de facto de SimpleDB, proporcionando una perspectiva de selección tecnológica para analizar el ciclo de vida de los servicios e identificar los servicios que no desaparecerán.

約 5 分で読めます

Los servicios de AWS también tienen vida útil

AWS se ha sostenido sobre la confianza implícita de que "los servicios una vez lanzados no se discontinúan". Sin embargo, la situación cambió en julio de 2024. AWS anunció la suspensión de nuevas inscripciones para múltiples servicios incluyendo CodeCommit, Cloud9, S3 Select, CloudSearch y SimpleDB. Los clientes existentes pueden seguir utilizándolos, pero la política es no agregar nuevas funciones. OpsWorks también anunció el fin de su vida útil. Estos anuncios obligaron a la industria a reconocer que los servicios de AWS no son eternos y que la selección tecnológica debe considerar el ciclo de vida del servicio.

Patrones comunes de los servicios que desaparecieron

Los servicios discontinuados o reducidos comparten patrones comunes. SimpleDB fue lanzado en 2007 como la primera base de datos NoSQL de AWS, pero perdió rápidamente su presencia cuando DynamoDB fue lanzado en 2012. Desapareció de la lista de servicios de AWS y el acceso desde la consola se hizo imposible, pero la API se mantuvo durante muchos años. Finalmente en 2024 se suspendieron las nuevas inscripciones. CodeCommit fue superado por GitHub y GitLab, y Cloud9 fue superado por VS Code y los IDEs en la nube. El patrón común es: un servicio que fue superado por una alternativa superior (interna o externa) y cuya base de usuarios se redujo gradualmente.

Las 4 etapas del ciclo de vida de un servicio

El ciclo de vida de los servicios de AWS se divide en 4 etapas. La primera etapa es Preview. Se anuncia en eventos como re:Invent y se ofrece como preview limitado. En esta etapa no hay SLA, la API puede cambiar y no es adecuado para cargas de trabajo de producción. Hay que tener en cuenta que existen servicios que permanecen en Preview sin llegar a GA. La segunda etapa es GA (disponibilidad general). Se proporciona SLA, la API se estabiliza y es adecuado para uso en producción. La tercera etapa es Madurez. Las nuevas funciones disminuyen pero la estabilidad es alta, y la base de usuarios es grande. La cuarta etapa es Declive. Las nuevas funciones se detienen, la documentación se actualiza con menos frecuencia y aparecen servicios sucesores.

Condiciones de los servicios que no desaparecen

Los servicios que perduran a largo plazo comparten características comunes. Primero, ser la base de otros servicios. S3 es utilizado como almacén de datos por numerosos servicios de AWS, y discontinuar S3 es prácticamente imposible. EC2 es la base de ejecución de ECS, EKS, RDS, Redshift y muchos otros servicios. IAM es la base de autenticación y autorización de todos los servicios. Estos servicios base tienen un costo de discontinuación prohibitivo debido a la profundidad de sus dependencias. Segundo, ser un pilar de ingresos. Los servicios con grandes ingresos tienen baja probabilidad de discontinuación. Tercero, estar vinculado a estándares de la industria. Los servicios basados en estándares abiertos (Kubernetes, SQL, HTTP) tienen alta portabilidad y baja probabilidad de discontinuación. Para profundizar en selección tecnológica, los libros relacionados (Amazon) también son una buena referencia.

Framework práctico de selección tecnológica

Al juzgar la adopción de un nuevo servicio de AWS, el siguiente framework es efectivo. Primero, verificar cuánto tiempo ha pasado desde GA. Los servicios con más de 2 años desde GA y adición continua de funciones probablemente han entrado en la etapa de madurez y son una opción estable. Segundo, verificar si el servicio es la base de otros servicios de AWS. Los servicios que aparecen frecuentemente en la documentación y guías de arquitectura de AWS tienen alta probabilidad de continuidad. Tercero, verificar si existe un servicio sucesor. Si AWS ha lanzado un servicio con funcionalidad superpuesta, el servicio anterior puede estar en declive. Cuarto, siempre tener una estrategia de salida. Diseñar para poder migrar a un servicio alternativo si el servicio actual se discontinúa.

Resumen

Los servicios de AWS tienen un ciclo de vida y no son existencias permanentes. La suspensión de nuevas inscripciones de CodeCommit, Cloud9 y SimpleDB en 2024 demostró claramente este hecho. Las condiciones de los servicios que no desaparecen son: ser la base de otros servicios, ser un pilar de ingresos y estar vinculado a estándares de la industria. En la selección tecnológica, siempre mantener la pregunta "¿qué haría si este servicio no existiera en 3 años?" y diseñar con una estrategia de salida es la clave para una arquitectura cloud sostenible.

Servicios relacionados

Amazon S3Servicio de almacenamiento de objetos escalableAmazon EC2Un servicio de cómputo que proporciona servidores virtuales en la nubeAWS LambdaServicio de computación serverless que ejecuta código sin gestión de servidoresAmazon DynamoDBUna base de datos NoSQL completamente administrada que ofrece latencia de milisegundos de un solo dígito

Artículos relacionados

Por qué AWS no integra sus servicios - La filosofía de diseño de Two-Pizza Team y la separación de serviciosExplicamos por qué AWS continúa ofreciendo más de 200 servicios individualmente, desde las perspectivas del API Mandate de Bezos, el principio organizacional de Two-Pizza Team y la Ley de Conway, y analizamos las ventajas y costos de la separación de servicios.La esencia del Undifferentiated Heavy Lifting - La línea divisoria entre los problemas que AWS resuelve y los que noProfundizamos en el verdadero significado de la frase Undifferentiated Heavy Lifting que AWS usa repetidamente, y explicamos los límites de responsabilidad de los servicios gestionados, la realidad del modelo de responsabilidad compartida, y la ilusión y realidad del fully managed.El 90% de AWS nace de la voz del cliente - Working Backwards y la innovación centrada en el clienteExplicamos cómo el proceso Working Backwards y el principio Customer Obsession moldean el desarrollo de servicios de AWS. Presentamos el mecanismo de innovación que comienza con el documento PR/FAQ y el proceso de incorporación del feedback de los clientes.IaC con lenguajes de programación usando AWS CDK - Diseño de Constructs y StacksAprenda sobre la definición de infraestructura con TypeScript/Python usando CDK, la elección entre constructs L1/L2/L3 y técnicas de pruebas.

Más sobre este tema

Ingeniería del caos en la práctica - Verificación de tolerancia a fallos con AWS Fault Injection SimulatorAprenda sobre la práctica de ingeniería del caos con AWS Fault Injection Simulator (FIS). Cubre el diseño de escenarios de inyección de fallos, la inyección de fallos en EC2, ECS y RDS, y la realización de experimentos seguros.Automatización de pipelines CI/CD - Entrega continua con AWS CodePipelineAprenda sobre la automatización de pipelines CI/CD usando AWS CodePipeline y CodeBuild.Hasta dónde ve la detección de drift de CloudFormation - Cómo rastrea cambios manuales y sus limitacionesAprenda cómo la detección de drift de CloudFormation compara internamente el estado actual de los recursos con el estado esperado definido en las plantillas, el límite entre cambios detectables y no detectables, y estrategias para la remediación de drift.Qué sucede durante una actualización de stack de CloudFormation - Detrás de change sets, rollbacks y reemplazosAprenda sobre el flujo de procesamiento interno cuando CloudFormation actualiza un stack, incluyendo cómo los change sets detectan diferencias, la lógica detrás de las decisiones de actualización, reemplazo y eliminación de recursos, y cómo funcionan los rollbacks.Estrategias de despliegue de AWS CodeDeploy - Despliegue blue/green en EC2, ECS y LambdaGestione estrategias de despliegue de forma unificada para las 3 plataformas EC2, ECS y Lambda. Presentamos el despliegue blue/green en ECS y el rollback automático vinculado con alarmas de CloudWatch.Despliegue EC2/On-Premises de AWS CodeDeploy - Diseño de AppSpec y hooks de ciclo de vidaDefina declarativamente las rutas de destino de despliegue y los hooks de ciclo de vida con el archivo AppSpec. Presentamos la gestión de flotas con grupos de despliegue basados en etiquetas e integración con Auto Scaling.Pipeline CI/CD con AWS CodePipeline - Automatización desde el código fuente hasta el despliegueAutomatice desde la detección de cambios en el código fuente hasta la compilación, pruebas y despliegue. Presentamos filtros de trigger V2, acciones de aprobación manual y diseño de despliegue entre cuentas.Automatización de despliegue de aplicaciones con Elastic Beanstalk - Desde la configuración del entorno hasta el despliegue rollingAutomatiza desde la configuración del entorno hasta el despliegue rolling. Presentamos los criterios de selección de políticas de despliegue y técnicas de personalización con .ebextensions.

Artículos y servicios similares

La velocidad de innovación vista en re:Invent - La aceleración evolutiva que muestra el ritmo de lanzamientos anuales de AWSComparamos el número de anuncios de nuevos servicios y funciones en AWS re:Invent y el ritmo de lanzamientos a lo largo del año con Azure y GCP, analizando el significado práctico que la diferencia en velocidad de innovación aporta a los usuarios.Compatibilidad retroactiva y estabilidad de las API de AWS - La confianza que genera la política de no deprecar APIs publicadasExplicamos 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.Ventaja del primer movedor y economías de escala de AWS - Lo que significan 18 años de acumulación desde 2006Comparamos la ventaja del primer movedor que AWS ha construido desde que creó el mercado de nube pública en 2006, desde las perspectivas de número de servicios, estabilidad de APIs y profundidad del ecosistema, frente a Azure y GCP.AWS CodeCommitServicio de repositorio Git completamente administrado proporcionado por AWS con autenticación/autorización mediante IAM y encriptación automática en reposo, cuyo acceso para nuevos usuarios fue suspendido en julio de 2024Entorno de desarrollo IDE en la nube - Construcción de una plataforma de desarrollo en equipo con AWS Cloud9Aprenda cómo construir un entorno de desarrollo integrado basado en la nube con AWS Cloud9. Este artículo cubre desarrollo full-stack desde el navegador, programación en pareja en tiempo real, integración con CodeCommit, pruebas locales de Lambda y otras técnicas prácticas para acelerar el desarrollo en equipo.