CATEGORÍA DE ANÁLISIS PROFUNDO
Tecnología sin servidor
Introducción
La tecnología sin servidor: el análisis profundo presenta conceptos básicos, arquitecturas de referencia, prácticas recomendadas y actividades prácticas que le ayudarán a comenzar a crear aplicaciones sin servidor. Es el lugar ideal para comenzar si es nuevo en la tecnología sin servidor. Para los creadores con experiencia en la tecnología sin servidor, tenemos recursos y enlaces a temas más avanzados.
¿A qué se refiere sin servidor?
Gracias a la informática sin servidor, puede crear y ejecutar aplicaciones y servicios sin tener que preocuparse por los servidores. Permite eliminar las tareas de administración de infraestructura, como el aprovisionamiento de servidores o clústeres, los parches, el mantenimiento del sistema operativo y la capacidad de aprovisionamiento. Puede crearlas para prácticamente cualquier tipo de aplicación o servicio de backend. Además, administra todo lo necesario para ejecutar y escalar la aplicación con alta disponibilidad.
Las aplicaciones sin servidor son aplicaciones impulsadas por eventos y de estructura flexible a través de API o mensajería con la mejor tecnología. Se ejecuta un código impulsado por eventos en respuesta a un evento, tal como un cambio de estado o una solicitud de punto de enlace. Las arquitecturas impulsadas por eventos desacoplan el código del estado. La integración entre los componentes de estructura flexible generalmente se lleva a cabo de manera asíncrona, por mensajería.
AWS Lambda es un servicio de informático sin servidor que viene integrado a arquitecturas impulsadas por eventos. Las funciones de Lambda se desencadenan mediante eventos a través de fuentes de eventos integradas como Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) y Amazon Kinesis que se pueden utilizar para crear integraciones asincrónicas. Las funciones Lambda consumen y producen eventos que luego otros servicios pueden consumir.
Los patrones de arquitectura sin servidor utilizan Lambda con otros servicios administrados que tampoco tienen servidor. Además de los servicios de mensajería y streaming, las arquitecturas sin servidor usan servicios administrados como Amazon API Gateway para la gestión de API, Amazon DynamoDB para el almacenamiento de datos y AWS Step Functions para la organización. La plataforma sin servidor también incluye un conjunto de herramientas de desarrollador que incluye el Serverless Application Model, o SAM, que ayuda a simplificar el desarrollo y las pruebas de sus funciones Lambda y aplicaciones sin servidor.
¿Por qué debería utilizar informática sin servidor?
Sin administración de servidor: no hay necesidad de aprovisionar ni mantener ningún servidor. No hay que instalar, mantener ni administrar software o tiempo de ejecución.
Escalación flexible: la aplicación se puede escalar automáticamente o con el ajuste de la capacidad mediante la alternancia de las unidades de consumo (p. ej.: rendimiento y memoria), en lugar de que se realice con las unidades de servidores individuales.
Pague por el valor: pague por rendimiento uniforme o duración de ejecución en lugar de hacerlo por unidad de servidor.
Alta disponibilidad automatizada: con la informática sin servidor se proporcionan disponibilidad prediseñada y tolerancia a errores. No tiene que diseñar estas capacidades, ya que en los servicios que ejecutan la aplicación, se las proporciona de forma predeterminada.
Servicios sin servidor central
Las aplicaciones sin servidor generalmente se crean utilizando servicios completamente administrados como bloques entre las capas de informática, datos, mensajería e integración, streaming, y administración e identificación de usuarios. Algunos servicios como AWS Lambda, API Gateway, SQS, SNS, EventBridge o Step Functions están al centro de la mayoría de las aplicaciones, respaldados por servicios como DynamoDB, S3 o Kinesis.
| Categoría |
Servicio |
Descripción |
|---|---|---|
| Informática | AWS Lambda | AWS Lambda le permite ejecutar aplicaciones sin servidor sin estado en una plataforma administrada que admite arquitecturas de microservicios, implementación y administración de ejecución a nivel de la función. |
| Proxy de la API | API Gateway | Amazon API Gateway es un servicio completamente administrado que hace que sea más fácil para los desarrolladores crear, publicar, mantener, monitorizar y proteger API a cualquier escala. Ofrece una plataforma integral para la administración de API. API Gateway le permite procesar cientos de miles de llamadas API simultáneas y maneja la administración de tráfico, la autorización y el control de acceso, la monitorización y la administración de la versión de API. |
| Mensajería e integración | SNS | Amazon SNS es un servicio de mensajería de publicación/suscripción completamente administrado que facilita el desacople y el ajuste de la escala de microservicios, los sistemas distribuidos y las aplicaciones sin servidor. |
| SQS | Amazon SQS es un servicio de colas completamente administrado que facilita el desacople y el ajuste de la escala de microservicios, los sistemas distribuidos y las aplicaciones sin servidor. |
|
| EventBridge | Amazon EventBridge es un bus de evento sin servidor que facilita la conexión de aplicaciones entre sí utilizando datos de sus propias aplicaciones, aplicaciones de software como servicio (SaaS) y servicios de AWS. |
|
| Organización | Step Functions |
AWS Step Functions facilita la coordinación de componentes de aplicaciones distribuidas y microservicios utilizando flujos de trabajo visuales. |
¡Vamos a diseñar!
A continuación, le presentamos algunos recursos que le ayudarán a comenzar con sus servicios sin servidor central.
Cree una función Lambda Hola, Mundo con la consola de AWS Lambda y conozca los aspectos básicos de ejecutar un código sin aprovisionar ni administrar servidores..
Cree una función Lambda invocada por Amazon S3 cada vez que se cargue un archivo de imagen en un bucket S3 y cree una miniatura en forma automática de esa imagen.
Use la consola Lambda para crear una función Lambda y un punto de enlace Amazon API Gateway para desencadenar esa función.
Aprenda a utilizar AWS Step Functions para diseñar y ejecutar un flujo de trabajo sin servidor que coordine múltiples funciones de AWS Lambda.
Aspectos fundamentales
En esta sección, aprenderá sobre el diseño impulsado por eventos, el principio central detrás de las aplicaciones sin servidor escalables.
Una arquitectura impulsada por eventos utiliza eventos para activar y establecer comunicación entre servicios desacoplados. Un evento es un cambio de estado, o una actualización, como un elemento que se coloca en un carro de compras de un sitio web de comercio electrónico. Los eventos pueden llevar el estado (por ejemplo, el elemento comprado, su precio y una dirección de entrega) o pueden ser identificadores (por ejemplo, una notificación de que se envió una orden).
Las arquitecturas impulsadas por eventos tienen tres componentes clave: procedimientos de eventos, enrutadores de eventos y consumidores de eventos. Un productor publica un evento para el enrutador, que filtra y envía los eventos a los consumidores. Los servicios del productor y los servicios del consumidor se desacoplan, lo que les permite escalarse, actualizarse e implementarse de manera independiente.
Para comprender por qué se desea una arquitectura impulsada por eventos, veamos la llamada de la API sincrónica.
Los clientes aprovechan sus microservicios realizando llamadas API HTTP. Amazon API Gateway aloja solicitudes de RESTful HTTP y responde a sus clientes. AWS Lambda contiene la lógica comercial para procesar llamadas de API entrantes y aprovecha DynamoDB como un almacenamiento persistente.
Cuando se invocan de manera sincrónica, API Gateway espera una respuesta inmediata y tiene un tiempo de espera de 30 segundos. Con las fuentes de eventos sincrónicos, si la respuesta de Lambda requiere más de 30 segundos, usted es responsable de escribir cualquier código de reintento y manejo de errores. Debido a esto, los errores o problemas de escalado que pudiera haber con algún componente posterior del cliente, como las unidades con capacidad de Lectura/Escritura en DynamoDB, se volverán a enviar al cliente para que maneje el código de front-end. Al usar patrones asincrónicos y desacoplar estos componentes, puede crear un sistema más sólido y altamente escalable.
Aprenda a implementar un escenario de mensajería de distribución donde los mensajes se envían mediante notificaciones push a varios suscriptores, lo que evita tener que verificar u obtener periódicamente actualizaciones y permite que los suscriptores procesen el mensaje de manera asíncrona y en paralelo.
Aprenda cómo crear un productor y consumidor de eventos en AWS Lambda y cree una regla para dirigir los eventos.
Las funciones de Lambda se disparan por medio de eventos. Luego ejecutan un código en respuesta al disparador y también pueden generar sus propios eventos. Existen muchas opciones para disparar una función Lambda, y cuenta con gran flexibilidad para crear fuentes de eventos personalizados que se adapten a sus necesidades específicas.
Los principales tipos de fuentes de evento son:
- Los depósitos de datos, como Amazon S3, Amazon DynamoDB o Amazon Kinesis, pueden disparar funciones de Lambda. Si almacena datos de los que usted desea rastrear cambios, potencialmente podría usarlo como una fuente de evento.
- Los puntos de enlace que emiten eventos pueden invocar Lambda. Por ejemplo, cuando le pide a Alexa que haga algo, ella emite un evento que dispara una función de Lambda.
- Los servicios de mensajería, como Amazon SQS o Amazon SNS, también pueden ser fuentes de eventos. Por ejemplo, cuando envía algo a un tema SNS, podría disparar una función de Lambda.
- Cuando ocurren ciertas acciones dentro de un repositorio, como cuando se confirma un código a su repositorio AWS CodeCommit, puede disparar una función de Lambda, por ejemplo, para iniciar su proceso de creación de CI/CD.
Aprenda cómo invocar funciones AWS Lambda con nuestra guía del desarrollador.
En esta sección, encontrará un conjunto de arquitecturas de referencia que cubren casos de uso comunes de aplicaciones sin servidor.
-
Microservicios RESTful
Las tecnologías sin servidor se crean sobre una infraestructura altamente disponible y tolerante a las fallas, lo que le permite crear servicios confiables para sus cargas de trabajo críticas para la misión. Los servicios centrales de AWS Serverless se integran perfectamente con docenas de otros servicios de AWS y aprovechan el enriquecido ecosistema de AWS y las herramientas de socios externos. Este ecosistema le permite simplificar el proceso de creación, automatizar tareas, organizar servicios y dependencias, y supervisar sus microservicios. Con los servicios de AWS Serverless, solo paga por lo que usa. Esto le permite aumentar el uso a medida que su negocio crece y mantener los costos al mínimo cuando el uso es bajo. Todas estas funciones hacen que las tecnologías sin servidor sean ideales para crear microservicios resilientes.
Ejemplo de arquitectura de microservicio RESTful
Los clientes aprovechan sus microservicios realizando llamadas API HTTP. Idealmente, sus consumidores deberían tener un contrato de servicio estrechamente vinculado a su API para lograr expectativas consistentes de niveles de servicio y control de cambio.
Amazon API Gateway aloja solicitudes de RESTful HTTP y responde a sus clientes. En este escenario, API Gateway proporciona autorización integrada, limitación controlada, seguridad, tolerancia a las fallas, asignación de solicitud/respuesta, y optimizaciones de rendimiento.
AWS Lambda contiene la lógica comercial para procesar llamadas de API entrantes y aprovecha DynamoDB como un almacenamiento persistente.
Amazon DynamoDB almacena de manera persistente datos de microservicios y escala en función de la demanda. Dado que los microservicios suelen diseñarse para hacer una cosa bien, generalmente se incorpora un almacenamiento de datos NoSQL sin esquema.
-
Procesamiento de imágenes
El procesamiento de imágenes es una carga de trabajo común que puede impulsarse por eventos y requiere ampliación y reducción dinámicas, tareas que las tecnologías sin servidor desempeñan muy bien. Por lo general, las imágenes se guardan en Amazon S3, que puede disparar funciones de Lambda para procesamiento. Después de procesar, la función de Lambda pueden volver la versión modificada a otro bucket de S3 o API Gateway.
En el siguiente esquema se muestra la arquitectura de Serverless Image Handler que se puede implementar en minutos utilizando la guía de implementación de la solución y la plantilla de AWS CloudFormation correspondiente.
AWS Lambda recupera imágenes de su bucket de Amazon Simple Storage Service (Amazon S3) y utiliza Sharp para devolver una versión modificada de la imagen a Amazon API Gateway. La solución genera un nombre de dominio de Amazon CloudFront que brinda acceso a la caché para la API del gestor de imágenes.
Además, la solución implementa una interfaz de usuario de demostración opcional donde puede interactuar directamente con el punto de enlace de la API del gestor de imágenes mediante archivos de imágenes que ya existen en su cuenta. La interfaz de usuario de demostración está implementada en un bucket de Amazon S3 para que los clientes puedan empezar a manipular imágenes de inmediato a través de una interfaz web sencilla. CloudFront se utiliza para restringir el acceso al contenido del bucket del sitio web de la solución.
Implementar solución >>
-
Procesamiento de transmisiones
Es posible usar AWS Lambda y Amazon Kinesis para procesar datos de streaming en tiempo real con el objetivo de realizar seguimientos de actividades de las aplicaciones, procesamientos de órdenes de transacciones, análisis de transmisiones de clics, limpieza de datos, generación de métricas, filtrado de registros, indexación, análisis en redes sociales y mediciones y telemetría de datos de dispositivos compatibles con IoT.
Ejemplo de arquitectura de procesamiento de transmisiones
La arquitectura que se describe en este diagrama se puede crear con una plantilla de AWS CloudFormation. La plantilla hará lo siguiente:
- Crea una secuencia de Kinesis
- Crea una tabla DynamoDB denominada -EventData
- Crea la función Lambda 1 (-DDBEventProcessor) que recibe registros de Kinesis y escribe informes a la tabla DynamoDB
- Crea una política y rol de IAM para permitir que la función Lambda que procesa el evento lea desde la secuencia Kinesis y escriba en la tabla DynamoDB
- Crea un usuario IAM con permiso para poner eventos en la secuencia de Kinesis juntos con las credenciales para que el usuario los use en un cliente de API
-
Aplicación web
Al usar la informática sin servidor en AWS, puede implementar toda la pila de aplicación Web sin tener que manejar servidores, aprovisionar capacidad o pagar por recursos que no se usan. Además, no debe comprometerse con la seguridad, la confiabilidad o el rendimiento. Las aplicaciones Web creadas con tecnologías sin servidor proporcionan una alta disponibilidad y pueden escalar globalmente según la demanda.
- Los consumidores de esta aplicación Web pueden estar geográficamente concentrados o distribuidos por todo el mundo. Al aprovechar Amazon CloudFront no solo obtiene una mejor experiencia de rendimiento para estos consumidores mediante el almacenamiento en caché y la dirección óptima original, sino que también limita las llamadas redundantes a su backend.
- Amazon S3 aloja activos estáticos de aplicación Web y los entrega de manera segura a través de CloudFront.
- Un conjunto de usuarios de Amazon Cognito proporciona las funciones de proveedor de gestión e identificación de usuarios para su aplicación Web.
- En muchos escenarios, dado que el consumidor descarga contenido estático de Amazon S3, su aplicación debe enviar o recibir contenido dinámico. Por ejemplo, cuando un usuario envía datos con un formulario, Amazon API Gateway entrega un punto de enlace seguro para realizar estas llamadas y regresar las respuestas que se muestran en su aplicación Web.
- Una función de AWS Lambda proporciona operaciones para crear, leer, actualizar y eliminar (CRUD) por sobre DynamoDB para su aplicación Web.
- Amazon DynamoDB puede proporcionar el almacén de datos NoSQL back-end para escalar de manera elástica con el tráfico de su aplicación Web.
- Los consumidores de esta aplicación Web pueden estar geográficamente concentrados o distribuidos por todo el mundo. Al aprovechar Amazon CloudFront no solo obtiene una mejor experiencia de rendimiento para estos consumidores mediante el almacenamiento en caché y la dirección óptima original, sino que también limita las llamadas redundantes a su backend.
Una práctica recomendada para las implementaciones en una arquitectura de microservicios es garantizar que un cambio no interrumpa el contrato de servicio del cliente. Si el propietario de la API realiza un cambio que interrumpe el contrato de servicio y el consumidor no está preparado para eso, se produce un fallo.
Para comprender el impacto de la implementación de cambios, debe conocer qué consumidores están usando su API. Puede recopilar los metadatos sobre el uso utilizando claves API, y estas también pueden actuar como forma de contrato en caso de realizarse algún cambio en una API que provoque una interrupción.
Cuando los clientes desea suavizar el impacto de los cambios de interrupción a una API, pueden clonar la API y dirigir a los clientes a diferentes subdominios (por ejemplo, v2.my-service.com) a fin de garantizar que no se afecta a los consumidores existentes. Este enfoque permite que los clientes implementen únicamente nuevos cambios al nuevo contrato de servicio de API, pero viene con compensaciones. Los clientes que toman este enfoque deben mantener dos versiones de la API, y deberán lidiar con gastos generales por el manejo y el aprovisionamiento de la infraestructura.
| Implementación |
Impacto al cliente |
Restauración | Factores del modelo de evento |
Velocidad de implementación |
|---|---|---|---|---|
| Todo de una vez | Todo de una vez | Reimplementación de versión anterior | Cualquier modelo de evento con baja tasa de simultaneidad | Inmediato |
| Azul/verde | Todo de una vez con cierto nivel de prueba del entorno de producción de antemano | Inversión del tráfico al entorno anterior | Mejor para modelos de eventos asincrónicos y sincrónicos con cargas de trabajo de simultaneidad media | Minutos a horas de validación y luego inmediato para los clientes |
| Canary/lineal | 1–10 % de cambio de tráfico típico inicial, luego la fase aumenta o se hace todo de una vez | Invertir el 100 % del tráfico a la implementación anterior | Mejor para cargas de trabajo de simultaneidad alta | Minutos a horas |
-
Implementaciones todas de una vez
Las implementaciones todas de una vez incluyen la realización de cambios sobre la configuración existente. Una ventaja de este estilo de implementación es que los cambios de back-end cambian a almacenamiento de datos, como una base de datos relacional, requiere un nivel de esfuerzo mucho menor para conciliar las transacciones durante el ciclo de cambio. Si bien este tipo de estilo de implementación es de bajo esfuerzo y se puede realizar con poco impacto en los modelos de baja simultaneidad, agrega riesgo en lo que respecta a restaurar y generalmente produce tiempo de inactividad. Un escenario de ejemplo para usar este modelo de implementación es para entornos de implementación donde el impacto al usuario es mínimo.
-
Implementaciones Blue-Green (azul-verde)
Con el patrón de implementación azul/verde, los clientes cambian una sección de tráfico al nuevo entorno en vivo (verde) a la vez que mantiene el entorno anterior (azul) a mano, en caso de que el sistema deba hacer una restauración. Cuando se usa este patrón, es mejor mantener cambios pequeños para que se puedan realizar restauraciones de manera rápida y fácil. Las implementaciones azul/verde están diseñadas para reducir el tiempo de inactividad y muchos clientes las están utilizando para implementar la producción. API Gateway le permite definir con facilidad qué porcentaje de tráfico se cambia al nuevo entorno verde, lo que la convierte en una herramienta eficaz para este patrón de implementación.
Este estilo de implementación es particularmente apto para las arquitecturas sin servidor, que son sin estado y se desacoplan de la infraestructura subyacente.
Necesita tener los indicadores correctos para saber si se requiere una restauración. Como práctica recomendada, recomendamos que los clientes usen métricas de CloudWatch de alta resolución, que pueden monitorearse en intervalos de 1 segundo, y pueden captar tendencias posteriores más rápidamente. Con las alarmas CloudWatch, puede permitir una restauración acelerada. Las métricas de CloudWatch se pueden captar en API Gateway, Step Functions, Lambda (incluidas las métricas personalizadas) y DynamoDB.
-
Implementaciones Canary
Las implementaciones Canary son un modo cada vez más popular de aprovechar la nueva versión de un software en un entorno controlado y de permitir ciclos de implementación rápidos. Las implementaciones Canary incluyen implementar una pequeña cantidad de solicitudes al nuevo cambio para analizar el impacto de una pequeña cantidad de sus usuarios.
Con las implementaciones Canary en API Gateway, puede implementar un cambio en su punto de enlace backend (por ejemplo, Lambda) mientras sigue manteniendo el mismo punto de enlace API Gateway HTTP para los consumidores. Además, también puede controlar qué porcentaje de tráfico se dirige a la nueva implementación y para una interrupción controlada del tráfico. Un escenario práctico para una implementación Canary podría ser un nuevo sitio web. Puede supervisar las tasas de clics en una pequeña cantidad de usuarios finales antes de cambiar todo el tráfico a la nueva implementación.
Cómo llevar a cabo implementaciones Canary de las funciones de AWS Lambda con un movimiento de tráfico de aliasAprenda cómo llevar a cabo implementaciones Canary de las funciones de AWS Lambda.
Implementación gradual de aplicaciones sin servidorAWS SAM proporciona implementaciones graduales Lambda para su aplicación sin servidor.