Funciones de Azure, GPC Cloud y AWS Lambda

Funciones de Azure

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.).

Recent Post