1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Ivan Salazar, Enterprise Solutions Architect
Noviembre, 2016
Comenzando con
aplicaciones sin servidores
en AWS

2. Agenda
§ Antecedente
§ AWS Lambda
§ Amazon API Gateway
§ Demo
§ Serverless Architecture Patterns
§ Serverless Best Practices

3. Antecedente
Cómo es que los patrones de arquitecturas “Serverless” con AWS
Lambda son la siguiente evolución del diseño de aplicaciones

4. La arquitectura monolítica

5. La arquitectura orientada a sercivios (SOA)
Capa de presentación Capa lógica
Capa de datos

6. La arquitectura de microservicios

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

12. AWS Lambda

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

19. “Pero espera…” – (usted)

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

23. Ejemplo de arquitectura sin
servidores

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

25. “Pero…
para poder utilizar Lambda, necesito
diseñar aplicaciones basadas en
eventos?” – (usted)

26. SOA aún funciona

27. Amazon API Gateway

28. Un servicio totalmente administrado para APIs
Crear Configurar Publicar
Mantener Monitorear Seguro

29. Demo
AWS Lambda
Function
web browser
Amazon S3
Contenido dinámico
Serverless Webform
Amazon API
Gateway
HTML estático
Amazon
DynamoDB

30. Patrones de arquitecturas
Serverless

31. Microservicios

32. Backend móvil

33. Motor de analíticos en tiempo real

34. Mejores prácticas para
Serverless

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.

38. Una invitación

39. Construya algo!
Amazon API
Gateway
AWS Lambda Amazon
DynamoDB

40. Thank you!Gracias!