Este documento presenta una introducción a las arquitecturas sin servidores utilizando AWS Lambda. Explica cómo las arquitecturas serverless son la evolución natural de los modelos monolíticos, SOA y de microservicios. Describe los componentes clave de AWS Lambda como las funciones, eventos y el servicio administrado. También incluye ejemplos de patrones arquitectónicos serverless y mejores prácticas para AWS Lambda y Amazon API Gateway.
7. Las herramientas para ayudar son VASTAS
§ Servidores Web
§ Librerías de código
§ Servicios Web/Frameworks de Aplicación
§ Herramientas de administración de
configuraciones
§ Plataformas de administración de APIs
§ Patrones de despliegue
§ Patrones de CI/CD
§ Contenedores
§ Etc. Etc. Etc.
8. AWS ha ayudado también!
§ Amazon EC2
§ EC2 Auto-Scaling
§ AWS Elastic Load Balancer
§ EC2 Auto-Recovery
§ AWS Trusted Advisor
§ AWS Elastic Beanstalk
§ AWS OpsWorks
§ AWS EC2 Container Service
§ Etc. Etc. Etc.
9. Pero….
muchas de estas herramientas e
innovaciones están acopladas a
una dependencia común…
10. Servidores (Ouch!)
§ ¿Qué tamaño de servidores son
adecuados para mi presupuesto?
§ ¿Cuántos usuarios generan
mucha carga a mis servidores?
§ ¿Cuánta capacidad sobrante le
queda a mis servidores?
§ ¿Cómo puedo detectar si un
servidor ha sido comprometido?
§ ¿Cuántos servidores debería
presupuestar?
§ ¿Cuál SO deberían tener mis
servidores?
§ ¿Cuáles usuarios deberían
tener acceso a mis servidores?
§ ¿Cómo puedo controlar el
acceso desde mis servidores?
§ ¿Quién hará los parches de SO
de mis servidores?
§ ¿Cómo despliegará el nuevo
código a mis servidores?
§ ¿Cómo puedo incrementar la
utilización de mis servidores?
§ ¿Cuándo debería decidir escalar
el número de servidores?
§ ¿Qué tamaño de servidor es
adecuado para mi rendimiento?
§ ¿Debo de ajustar los valores del
SO para optimizar mi aplicación?
§ ¿Qué paquetes deben estar
creados en las imágenes?
§ ¿Cuándo debería decidir crecer mis
servidores?
§ ¿Cómo controlo los cambios en la
configuración del servidor?
§ ¿Cómo las aplicaciones soportarán
fallas en el Hardware?
11. Arquitectura para ser Serverless
Totalmente administrado
§ No provisionamiento
§ Cero administración
§ Alta disponibilidad
Productividad del desarrollador
§ Enfocarse en el código que
importa
§ Innovar rápidamente
§ Reducir el time to market
Escalamiento continuo
§ Automatizado
§ Escala hacia arriba/abajo
13. Servicio de cómputo, detonado por eventos y sin servidores
Lambda = microservicios sin servidores
14. Componentes de Lambda
§ Una función Lambda (que usted escribe)
§ Un evento externo
§ El servicio AWS Lambda
§ Un ambiente de red para la función
15. La función Lambda
§ Su código
(Java, NodeJS, Python)
§ El rol de IAM que toma el
código durante la ejecución
§ La cantidad de memoria
reservada a su código
(afecta CPU y red también)
Una función completa
Lambda válida
16. Un evento externo
§ ¿Cuándo se debe ejecutar su función?
§ Muchos servicios de AWS pueden ser eventos hoy:
• S3
• Kinesis
• SNS
• DynamoDB
• CloudWatch
• Config Rules
• Amazon Echo
• IoT
• Etc.
• …y Amazon API Gateway (más adelante)
17. El servicio AWS Lambda
§ Ejecuta el código de su función sin que tenga que
administrar o escalar servidores.
§ Provee un API para detonar la ejecución.
§ Asegura que la función es ejecutada cuando se detona,
en paralelo, sin importar la escala.
§ Provee capacidade adicionales para su función (logs,
monitoreo).
18. Ambiente de red para la función
Default – un ambiente de red
por defecto dentro de VPC está
incluido
§ El acceso a Internet siempre está
permitido para su función
§ Sin acceso a componentes
contenidos en una VPC propia
Customer VPC – Su función se
ejecuta dentro del contexto de su
propia VPC
§ Comunicación privada con otros
recursos dentro de su VPC
§ Configuración y comportamiento
familiar con:
– Subnets
– Elastic Network Interfaces (ENIs)
– EC2 Security Groups
– VPC Route Tables
– NAT Gateway
20. Diferentes formas de abstraer servicios
§ SaaS
§ PaaS
§ MBaaS
§ *aaS
§ Application Engines/Platforms
21. ¿Qué hace a Lambda único?
§ Abstracción a nivel código/función (arbitraria, flexible,
familiar)
§ El modelo de seguridad (IAM, VPC)
§ El model de precio
§ La comunidad
§ Integración con los servicios de AWS
• Escala
• Eventos
22. Muchas opciones sin servidores
Storage DatabaseNetwork
Compute Content DeliveryMessaging and QueuesSecurity
Gateways
User Management Monitoring & Logging
Internet of Things
Machine Learning
Streaming Analytics
24. Procesamiento de video Serverless
Laptop
Encoders
HLS
S3
Playback
VOD Stream
mobile client
CloudFront
Streaming
Live stream
mobile client
CloudFro
nt
S3 Ingest
480p
Transcod
e
HQ Copy
360p
Transcod
e
Audio-
only
Transcod
e
Thumbnai
l
QOS
Analytics
Funciones Lambda en cascada
http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda
35. Mejores prácticas para AWS Lambda
1. Limite el tamaño de la función
– especialmente para Java
(iniciar JVM toma tiempo)
2. Node – recuerde la ejecución
es asíncrona.
3. No asuma el reuso de
contenedores de funciones –
pero aprovéchelo cuando
suceda.
1. No olvide el espacio en disco
(500MB /tmp directorio a cada
función)
2. Use aliases para liberar
funciones.
3. Use el servicio de logs
incluido (incluye detalles del
contexto del servicio)
4. Cree metricas personalizadas
(operativas, y de negocio)
36. Mejores prácticas de Amazon API Gateway
1. Use plantillas
request/response.
2. Tome control de los códigos
de respuesta HTTP
3. Use Swagger import/export
para compartir entre cuentas
1. Use integración con
templates
2. Combine con Cognito para
administrar el control de
acceso de usuarios finales.
3. Use variables de ambientes
(inserte los valores de
configuración del API en las
funciones para logs y
comportamiento)
37. Mejores prácticas adicionales
1. Use estrategias de nombrado
consumibles (nombres de
funciones Lambda, roles IAM,
nombres de API, ambientes
de API, etc.)
2. Use convenciones de
nombres y versiones para
automatizar
3. Externalice la autenticación a
roles de IAM en medida de lo
posible
1. El menor privilegio y roles
separados de IAM
2. Externalice la configuración -
DynamoDB es muy útil
3. Contacte a soporte antes de
eventos a gran escala
conocidos
4. Sea consciente del throttling
del servicio, contacte a
soporte si sucede.