Qué es Serverless (AWS Lambda, Funciones de Azure, GCP Cloud Functions)
Funciones de Azure, GPC Cloud y AWS Lambda — En este artículo, utilizaremos AWS Lambda como ejemplo principal:
Si esto es lo que está buscando, entonces está viniendo al lugar correcto:
Ejecutar código en máquinas distribuidas, de forma aislada y segura
Consumir solo la memoria requerida por nuestro código
Pasar todo nuestro tiempo de CPU en nuestro código
Hacer que escalar entre regiones sea trivial
Comenzar a ejecutar el código rápidamente (tiempo de comercialización)
Implementación y actualizaciones rápidas
Sin VMS, sin contenedores
Alta disponibilidad implícita
Lo que viene con Lambda:
API Gateway (No el 100% del tiempo, puede personalizar para usar ALB en lugar de API Gateway, pero no es tan común). Entonces, ¿qué es API Gateway?
- Actúa como la “puerta de entrada” a la aplicación
- Maneja la autorización y el control de acceso.
- Expone las funciones de Lambda a su código de aplicación front-end
- Facturado por llamadas API
Diferencias entre API Gateway y ALB
API GATEWAY | ALB |
---|---|
Puede implementar limitación de velocidad, explosión para API | Sin límite de velocidad, capacidad de explosión |
Integración con AWS WAF para protección | Integración con AWS WAF para protección |
No es posible obtener una dirección IP estática para el punto final | Es posible obtener una dirección IP estática para el punto final |
Capaz de hacer validación de solicitudes, mapeo de solicitudes/respuestas | No se puede realizar la validación de solicitudes, el mapeo de solicitud/respuesta |
Capaz de integrarse con Lambda de una región diferente, incluso de una cuenta de AWS diferente | ALB es un servicio regional |
Capaz de exportar/importar API entre plataformas de API usando swagger, Open API Spec 3.0 | Sin método directo para importar/exportar reglas para plataformas cruzadas |
Capaz de manejar tráfico puntiagudo (tasa predeterminada de 10k rps, tasa de ráfaga de 5k) | Retraso durante tráfico con picos, preasignar LCU para evitar retrasos (con cargo adicional) |
Capaz de exportar/importar API entre plataformas de API usando swagger, Open API Spec 3.0 | Sin método directo para importar/exportar reglas para plataformas cruzadas |
Capaz de almacenar en caché las respuestas | No se pueden almacenar en caché las respuestas |
Acepta tráfico HTTPS | Acepta tráfico HTTP, HTTPS |
Límite de tiempo de espera 30 segundos | Límite de tiempo de espera 4000 segundos (~66 minutos) |
Se integra con casi todos los servicios de AWS | Use EC2, Lambda, direcciones IP como backend |
No hay verificación de salud disponibleeck available | Chequeo de salud disponible |
Pagar para usar | Pagar por inactivo |
Problema que viene con AWS Lambda, como el arranque en frío, pasos que puede seguir para prevenir:
1. En lugar de lenguajes de programación tipificados estáticamente como C# y Java, utilice lenguajes tipificados dinámicamente como Node.js y Python. A diferencia de los lenguajes escritos estáticamente, los lenguajes escritos dinámicamente examinan lo que escribe durante el tiempo de ejecución.
2. Lambdas no debe usarse en entornos de nube privada virtual (VPC); una VPC es una nube privada aislada y segura alojada en una nube pública. VPC aísla sus recursos informáticos entre sí, lo que puede resultar en tiempos de demora más prolongados y arranques en frío.
3. Evite las llamadas HTTPS dentro de lambda, ya que los protocolos de enlace SSL y otras llamadas relacionadas con la seguridad pueden provocar arranques en frío debido a las limitaciones de la CPU.
4. Evite las dependencias: las dependencias de Java que buscan en el classpath, como Spring, pueden provocar arranques en frío. Además, la carga de clases de Java puede llevar mucho tiempo y provocar un arranque en frío.
5. Aumente la RAM en AWS Lambda para obtener capacidad de CPU adicional; esto puede acelerar el tiempo de ejecución de Lambda y minimizar los gastos en relación con configuraciones de memoria más bajas.
Formas de implementar AWS Lambda:
Implementación de Lambda
Las Lambdas se implementan en función de dos tipos de artefactos:
- Paquetes zip (mediante carga directa o S3)
- Imágenes de Docker (a través de ECR)
Si su código Lambda sin comprimir con dependencias supera los 250 MB, use Docker Images. Para tamaños más pequeños, es más conveniente usar paquetes Zip.
Por lo general, es mejor usar cubos S3 como almacenamiento para artefactos Zip en lugar de carga directa. El almacenamiento de artefactos en el depósito S3 permite reversiones rápidas en caso de errores. Sin embargo, si aún elige la carga directa, recuerde que solo los archivos Zip de menos de 50 MB se pueden usar de esta manera.
Otras alternativas son:
- manual — secuencias de comandos bash, CLI de AWS
- sam — implementación de AWS SAM
- terraform — scripts de terraformar
Mi recomendación:
Marco sin servidor
Serverless Framework ayuda en el desarrollo y la implementación de funciones sin servidor de AWS, Azure, etc., así como otros recursos de infraestructura en la nube necesarios para estas funciones (AWS DynamoDB, Azure CosmosDB, AWS S3, Azure Blob Storage, etc.) .
Su sitio web proporcionó numerosos ejemplos de cómo implementar A-Z, incluidos Nodejs, Python, Java y otros… Es una interfaz de línea de comandos (CLI) que viene con estructura, automatización y mejores prácticas. Esto le permite concentrarse en desarrollar arquitecturas complejas, sin servidor y basadas en eventos compuestas por funciones y eventos. Además, Serverless Framework se puede usar con cualquier idioma, biblioteca, marco o proveedor de nube (AWS, Azure, GCP, etc.).