Close
Una de las mejores prácticas para las implementaciones en una arquitectura de microservicio es garantizar que un cambio no interrumpa el contrato de servicio del consumidor. Si el propietario de la API realiza un cambio que rompe el contrato de servicio y el consumidor no está preparado para ello, pueden ocurrir fallas.
Ser consciente de qué consumidores están utilizando sus API es el primer paso para garantizar que los despliegues sean seguros.
AWS Serverless Applications Lens
La recopilación de metadatos sobre los consumidores y su uso permite tomar decisiones basadas en datos sobre el impacto de los cambios. Las API Keys son una forma eficaz de capturar metadatos sobre los consumidores / clientes de la API y, a menudo, se utilizan como una forma de contacto si se realiza un cambio importante en una API.
Algunos clientes que desean adoptar un enfoque adverso al riesgo para romper los cambios pueden optar por clonar la API y enrutar a los clientes a un subdominio diferente (por ejemplo, v2.miservicio.com) para asegurarse de que los consumidores existentes no se vean afectados. Si bien este enfoque permite nuevas implementaciones con un nuevo contrato de servicio, la compensación es que la sobrecarga de mantener API duales (y la infraestructura de backend) requiere una sobrecarga adicional.
La siguiente tabla muestra las diferentes estrategias de despliegue para aplicaciones serverless:
Los despliegues all-at-once implican realizar cambios sobre toda la configuración existente. Una ventaja de este estilo de despliegue es que los cambios de backend en los almacenes de datos, como una base de datos relacional, requieren un nivel de esfuerzo mucho menor para conciliar las transacciones durante el ciclo de cambio. Si bien este tipo de estilo de implementación requiere poco esfuerzo y se puede realizar con poco impacto en modelos de baja concurrencia, agrega riesgo cuando se trata de reversión y generalmente causa tiempo de inactividad. Un escenario práctico para utilizar este modelo de despliegue es para entornos de desarrollo donde el impacto del usuario es mínimo.
Otro patrón de cambio de tráfico es la habilitación de despliegues blue/green. Esta estrategia con tiempo de inactividad casi nulo permite que el tráfico cambie al nuevo entorno ‘en vivo’ (verde) mientras mantiene en espera el antiguo entorno de producción (azul) en caso de que sea necesario revertir el despliegue. Dado que API Gateway permite definir qué porcentaje de tráfico se traslada a un entorno en particular; este estilo de despliegue puede ser una técnica eficaz. Dado que los despliegues blue/green están diseñadas para reducir el tiempo de inactividad, muchos clientes adoptan este patrón para los cambios de producción.
Las arquitecturas sin servidor que siguen las mejores prácticas de statelessness e idempotency se adaptan a este estilo de implementación porque no hay dependencia con la infraestructura subyacente. Debe orientar estos despliegues hacia cambios incrementales más pequeños para que pueda volver fácilmente a un entorno que funcione si es necesario.
Se necesita los indicadores correctos en su lugar para saber si se requiere una reversión. Como buena práctica, recomendamos utilizar métricas de alta resolución de CloudWatch, que pueden monitorear en intervalos de 1 segundo y capturar rápidamente tendencias a la baja. Si se usa con las alarmas de CloudWatch, puede permitir que se produzca una reversión acelerada. Las métricas de CloudWatch se pueden capturar en API Gateway, Step Functions, Lambda (incluidas métricas personalizadas) y DynamoDB.
Los despliegues Canary son una forma cada vez mayor de aprovechar la nueva versión de un software en un entorno controlado y permitir ciclos de implementación rápidos. Los despliegues Canary implican implementar una pequeña cantidad de solicitudes al nuevo cambio para analizar el impacto en una pequeña cantidad de sus usuarios. Dado que ya no necesita preocuparse por el aprovisionamiento y el escalado de la infraestructura subyacente de la nueva implementación, la nube de AWS ha ayudado a facilitar esta adopción.
Con los despliegues Canary en API Gateway, se puede implementar un cambio en su endpoint backend (por ejemplo, Lambda) mientras mantiene el mismo enpoint HTTP de API Gateway para los consumidores. Además, también puede controlar qué porcentaje de tráfico se enruta a una nueva implementación para una transición de tráfico controlada. Un escenario práctico para un despliegue Canary podría ser un nuevo sitio web. Puede monitorear las tasas de clics en una pequeña cantidad de usuarios finales antes de cambiar todo el tráfico a la nueva implementación.
En este contexto, controlar las versiones de los Lambdas es muy importantes. Como todo software, mantener el control de versiones permite la visibilidad rápida del código que funcionaba anteriormente, así como la capacidad de volver a una versión anterior si una nueva implementación no tiene éxito. Lambda permite publicar una o más versiones inmutables para funciones individuales de Lambda; de modo que las versiones anteriores no se puedan cambiar. Cada versión de la función Lambda tiene un Amazon Resource Name (ARN) único y los cambios de la nueva versión son auditables a medida que se registran en CloudTrail. Como práctica recomendada en producción, los clientes deben habilitar el control de versiones para aprovechar mejor una arquitectura confiable.
Para simplificar las operaciones de despliegue y reducir el riesgo de error, los Lambda Aliases permiten diferentes variaciones de su función Lambda en su flujo de trabajo de desarrollo, como desarrollo, beta y producción. Un ejemplo de esto es cuando una integración de API Gateway con Lambda apunta al ARN de un alias de producción. El alias de producción apuntará a una versión de Lambda. El valor de esta técnica es que permite una implementación segura cuando se promueve una nueva versión en el entorno en vivo porque el Lambda Alias dentro de la configuración de la persona que llama permanece estático, por lo que hay menos cambios que realizar. Finalmente es muy importante tener en cuenta las buenas prácticas en el desarrollo con Lambdas.
¿Te gustó este artículo?
Podemos contactarnos pronto y de manera muy directa a través de las siguientes opciones:
