El documento describe la evolución de la arquitectura de aplicaciones desde modelos monolíticos y orientados a servicios hacia modelos serverless y sin servidores utilizando funciones como AWS Lambda. Explica cómo los patrones de arquitectura serverless permiten enfocarse en el código sin preocuparse por la administración de servidores, además de proveer escalamiento automático y alta disponibilidad. Finalmente, presenta algunos ejemplos comunes de uso de arquitecturas serverless como microservicios, procesamiento de datos y sitios web.

1. Comenzando con
arquitecturas sin servidores
Angel Leon
Arquitecto de Soluciones
Sector Público
Agosto 2017

2. Antecedente
¿Por qué los patrones de arquitecturas Serverless con AWS Lambda son
la siguiente evolución del diseño de aplicaciones?

3. La arquitectura monolítica

4. La arquitectura orientada a servicios
Capa de presentación Capa lógica
Capa de datos

5. La arquitectura de microservicios

6. La arquitectura de microservicios

7. Evolución del cómputo en la nube hacia
“Serverless”

8. Evolución del cómputo – Nube pública
InfraestructuraInstancias
Código de la aplicación

9. Evolución del cómputo – Contenedores
InfraestructuraInstancias
Código de la aplicaciónContenedores

10. Evolución del cómputo – Serverless
Código de la aplicación

11. Las herramientas para ayudar son MUCHAS
 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.

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

13. Pero….
muchas de estas herramientas e
innovaciones están acopladas a
una dependencia común…

14. 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?

15. Arquitectura para ser Serverless
Totalmente administrado
 No aprovisionamiento
 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

16. Anatomía de una aplicación Web

17. ¿Qué conforma a una aplicación Web?
Vamos a separarlo…

18. ¿Qué conforma a una aplicación Web?

19. ¿Qué conforma a una aplicación Web?

20. ¿Qué conforma a una aplicación Web?

21. Aplicación Web Serverless

22. ¿A dónde se fueron los servidores?

23. Sitio web estático hospedado en S3
 Especifique un documento índice (ej. index.html)
 Especifique un documento de error
 Los objetos deben ser de lectura pública
 Soporta redireccionamientos
 Todas las solcitudes
 Condicional
bucket with
objects

24. Configuración dinámica
Una buena opción:
 Obtener configuraciones de DynamoDB
 Escriba los valores a variables globales
 El código utiliza las variables globales
Lambda
Function
Amazon
DynamoDB

25. DynamoDB – recordatorio
 Base de datos NoSQL
 Llaves: Hash Key y Range Key (opcional)
 Tips:
 Planeé sus llaves
 Piense en sus queries

26. AWS Lambda

27. Servicio de cómputo, detonado por eventos y sin servidores
Lambda = microservicios sin servidores

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

29. La función Lambda
 Su código
(Java, NodeJS, Python, C#)
 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

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

31. 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 capacidades adicionales para su función (logs,
monitoreo).

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

33. Muchas opciones sin servidores
Storage DatabaseNetwork
Compute Content DeliveryMessaging and QueuesSecurity
Gateways
User Management Monitoring & Logging
Internet of Things
Machine Learning
Streaming Analytics

34. Amazon API Gateway

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

36. Demo

38. App Frontend

39. Amazon S3

40. Amazon API Gateway

41. AWS Lambda

42. Amazon DynamoDB

43. Patrones de arquitecturas “Serverless”
 Microservicios
 Backend de aplicaciones móviles
 Procesamiento de datos
 Sitios Web
 APIs
 Analíticos en tiempo real
 Procesamiento de multimedia

44. Microservicios

45. Backend de aplicaciones móviles

46. Upload
to S3
S3 Bucket Lambda
S3 Notification
Compressed
Image
Compress Image
Upload back to S3
Procesamiento de datos

47. Static
Content
Dynamic
Content
API Gateway Lambda DynamoDB
Sitio Web “Serverless”

48. Internet
Mobile Apps
Websites
Services
AWS Lambda
functions
API Gateway
Cache
Endpoints on
Amazon EC2
Any other publicly
accessible endpoint
Amazon
CloudWatch
Amazon
CloudFront
Amazon
API Gateway
API “Serverless” con API Gateway

49. Motor de analíticos en tiempo real

50. CloudFront S3
Ingest
Lambda functions
HQ Copy
480p
Transcode
360p
Transcode
Audio Only
Transcode
S3
Playback
CloudFront
streaming
Thumbnails
Procesamiento de archivos de video

51. ¡Nuevo!
AWS Step Functions

52. Beneficios de AWS Step functions
Diagnostique y
rastreé problemas
más rápido
Adáptese al
cambio
Fácil de conectar y
coordinar componentes
distribuidos y
microservicios para
crear aplicaciones más
rápido
Administra la
operación e
infraestructura de la
coordinación de
servicios para
asegurar la
disponibilidad
Productividad Agilidad Resiliencia

53. Qué sigue?

54. ¡Construya algo!
Amazon API
Gateway
AWS Lambda Amazon
DynamoDB
https://aws.amazon.com/serverless

55. Remember to complete
your evaluations!
¡No olvide llenar su
evaluación!

56. ¡Gracias!