Presentación del Meetup "Serverless... ¡en local! con Serverless Framework en AWS", por Víctor Javier Madrid (Líder Técnico de Arquitectura de Soluciones en atSistemas)

1. ¡Bienvenidos!

2. Agenda:
• 19:00 – 19:05 - Apertura
• 19:05 – 20:00 - Serverless... ¡en local! con Serverless Framework
en AWS
• 20:00 – 21:00 - Bebida y picoteo para conocernos

3. https://enmilocalfunciona.io

4. Comenzamos el blog en 2016
Y poco a poco hemos ido creciendo:

5. ¡Gracias a todos los que lo hacéis posible!
Más de 100 posts de
más de 60 compañeros y
ex-compañeros
¡Gracias a ti por tu
asistencia y visitas!

6. Serverless... ¡en local!
con Serverless
Framework en AWS

7. ¿Y por dónde empiezo?
https://enmilocalfunciona.io/aprendiendo-serverless-framework-parte-1-introduccion/
https://enmilocalfunciona.io/aprendiendo-serverless-framework-parte-2-instalacion/
Próximamente muchos más…

8. Índice
1. Introducción
2. Entornos de Ejecución
3. Desarrollo “Serverless”
4. Laboratorio
5. Preguntas

9. 1. Introducción

10. En un mundo ideal ¿Serverless significa? … SIN Servidor

11. Un paso más en la evolución
Sistemas
monolíticos
Sistemas
distribuidos
Microservicios
Serverless
Mundo Síncrono
• Enfoque Request-Driven
Mundo Asíncrono
• Enfoque Message-Driven
• Enfoque Event-Driven

12. Patrones : Orquestador vs. Coreográfico
Photo by Manuel Nägeli on Unsplash Photo by Michael Afonso on Unsplash
• Requiere un coordinador central
• El coordinador central “da las órdenes” (centralización)
• Facilita la implementación
• Enfoque síncrono (aunque también puede ser asíncrono)
• NO requiere un coordinador central
• Normalmente existe un plan aunque cada uno es responsable
de dar y recibir órdenes (distribuido)
• Mayor dificultad de implementación -> requiere mecanismo
de mensajería
• Enfoque asíncrono

13. ¿Cuál es la siguiente gran revolución?
Teoría : No hay balas de plata
“No sólo no hay balas de plata a la vista, sino que la
misma naturaleza del software impide que las haya”
Frederick P. Brooks (1987)
Cada cierto tiempo aparece una gran solución a todos los
problemas
Open Source Frameworks Agile
Cloud Contenedores Microservicios
Blockchain Serverless …

14. Aplicaciones Twelve-Factor
Metodología para construir aplicaciones
con ejecución como un servicio
• https://12factor.net/
• https://12factor.net/es/
• Applying the Twelve-Factor App
Methodology to Serverless
Applications

15. 2. Entornos de Ejecución
Clásico / Mascota
Cloud / Ganado
Infraestructura como Código / IaC
Serverless

16. Entorno de ejecución “Clásico” / “Mascota”
Photo by Alicia Jones on Unsplash
Tipo Características
Máquina Tamaño presupuestado
Entornos diferentes
PRO “cuidados especiales”
Software base
Redimensionamiento
Carga y rendimiento
Problemas escalado
Problemas Seguridad
Despliegues lentos
Problemas cambio SW
Problemas cambio HW
Personal
Problemas de tiempos respuesta
Problemas por cortes
Máquina virtual Inmutabilidad de entornos
Mejora de despliegues
Multi-tenancy
Redimensionamiento dinámico
Aislamiento
Entorno completo totalmente configurable y
exportable (Test)
Despliegues más dinámicos, menos
comprometidos y menos intrusivos
Problemas de gestión de recursos SO
Host
Tiempos de respuesta en función recursos consumidos en SO Host
Más tolerancia a problemas por cortes
Contenedor Inmutabilidad de entornos
TEST = PRO
Mejora de despliegues
High Multi-tenancy
Ligero (pocos recursos)
Principio Responsabilidad única
Reproducible en local
Despliegues muy rápidos => Mejora
autoescalado bajo demanda
Tiempos de respuesta en función recursos consumidos en SO Host y
gestión de contenedores y orquestración
Más tolerancia que MV a problemas por cortes
Servidor físico con una asignación específica de sus recursos, una definición
concreta de los lenguajes/versiones a utilizar donde se ejecutan las diferentes
aplicaciones
● Separación entre entornos -> DEV, INT, UAT, QA, PRE y PRO
● Surge una serie de problemas en base a su elección

17. Entorno de ejecución “Cloud” / “Ganado”
Servidor físico proporcionado por un proveedor (Azure, Aws, Google, etc.) asignación
específica o dinámica de sus recursos, una definición concreta de los lenguajes/versiones
a utilizar donde se ejecutan las diferentes aplicaciones
● Dependencia del modelos de servicios a la hora de realizar la distribución de SW
● Surge una serie de problemas en base a su elección
Modelo Descripción
IaaS Infraestructura como servicio : Modelo basado en que un proveedor se encarga de la distribución de la infraestructura necesaria -> También se denomina HaaS (Hardware as a Service)
Objetivo : externalizar el servidor (espacio disco, tiempo computación y/o base de datos)
Facilita : escalabilidad, elasticidad, disponibilidad, seguridad, automatización, mantenibilidad, etc.
Pago por configuración y por uso
PaaS Plataforma como servicio : Modelo basado en que un proveedor se encarga de proporcionar TODO lo necesario para soportar un ciclo de vida completo de puesta en marcha de aplicaciones y servidores
Objetivo : externalizar la aplicación (base de datos, SSOO, servidor de aplicaciones)
Pago por licenciamiento, configuración y por uso
SaaS Software como servicio : Modelo basado en que un proveedor se encarga de proporcionar mantenimiento, soporte y operación a un cliente durante un periodo de contratación de servicio
Objetivo : externalizar el uso
Pago por volumen de usuarios, módulos utilizados, plan de soporte, acceso por dispositivo
XaaS Todo como servicio : Modelo basado en proporcionar todo para pago por “uso” : BI, Seguridad, Desktop, Backup, Email, ...
Photo by Samuel González Izquierdo on Unsplash

18. Entorno de ejecución “Infraestructura como Código” / “IaC”
Evolución “natural” del entorno de ejecución “Cloud”
● Foco en la mejora de la creación y mantenimiento de entornos
● Surge una serie de problemas en base a su elección
● Características :
● Creación de infraestructura versionable, reproducible,
consistente e independiente del entorno
● Entornos limpios y sin estados anterior
● Automatización del proceso manual mediante una explotación
programáticos sobre los entornos de ejecución : clásico y cloud
● Facilita la creación / destrucción de entornos como ciclo de
integración / entrega continua
● Uso de herramientas específicas

19. Modelo Cloud FaaS (Function as a Service)
Modelo de distribución de SW donde el proveedor facilita todo lo necesario para que únicamente los desarrolladores se
limiten a codificar el comportamiento de una función (pieza de lógica de negocio)
● Minimización del desarrollo a la mínima expresión : la función -> Cumplimiento “PSR”
● Toda la infraestructura está delegada -> escalabilidad, pago por tiempo de ejecución, etc.
● Una función consume menos recursos que un microservicios -> problema de mantenerlo levantado
● El lenguaje de implementación depende del proveedor
● Funciones SIN estado -> si se quiere estado hay que utilizar apoyarse en otros servicios
● Funcionalidad específica como : scheduled task / jobs, procesar peticiones web, procesar mensajes de colas, ejecución manual , etc.
● Requiere un puerta de enlace “API” o API Gateway
Servicio de ejecución de funciones proporcionado por diferentes proveedores : AWS Lambda, Google Cloud Functions,
Azure Functions , Iron.io, Webtask.io etc.
Diferencias con BaaS (Backend as a Service)
Combinación con otros servicios externos (servicios de computación sin servidores) -> “Juntar Piezas”
○ Autenticación (Auth0, Amazon Cognito)
○ Productos API (Api Gateway,etc)
○ Sistemas de mensajería (SQS, SNS,etc)
○ Streaming de datos (Kinesis, etc)
○ ...
Funcionalidades complejas -> requieren más de una función -> Patrón Orquestador vs Patrón Coreográfico

20. Entorno de ejecución “Serverless”
Servicio proporcionado por un proveedor (Azure, Aws, Google, etc.)
donde se facilita un servidor (físicos o cloud), la asignación dinámica
de sus recursos, una definición concreta de los lenguajes/versiones a
utilizar y una única función de entrada como contrato
● No hay aprovisionamiento, gestión y mantenimiento de servidores
● Funcionamiento basado en el uso y reaprovechamiento de contenedores
● Se factura por tiempo de ejecución y por su configuración
● Escalado continuo debido al uso
● Disponibilidad y tolerancia a fallos por defecto
● Un evento invoca a esta función que genera el “ambiente” y una vez
ejecutado el “ambiente” desaparece -> arranque “frío” / “caliente” ->
latencia
● Buen comportamiento frente a cargas de trabajo relacionadas con
eventos entrantes
Photo by eberhard grossgasteiger on Unsplash

21. Símil Entorno de ejecución “Serverless”

22. 3. Desarrollo “Serverless”

23. Enfoque Arquitectónico “Serverless”
Cualquier desarrollo se despliega en un “entornos de ejecución Serverless” proporcionados por los diferentes
proveedores (Azure, Aws, Google, etc.) donde solamente hay que introducir el código para poder ejecutarlo
● Cloud-First
● Less Ops -> Abstracción de la infraestructura -> Desaparecen los servidores para el desarrollador -> NO mantenimiento
● Agnóstico del proveedor
● Uso On-Demand
● Pay-for-Use o Pay-for-execution-time (si no se usa se apaga)
● El código que se ejecuta se corresponde con una función -> Depende del criterio del desarrollador
● Tiene similitudes con la Arq. de Microservicios
● Focalización en la construcción y mantenimiento de aplicaciones -> Productividad
● Requiere un cambio cultural no solo técnico
● Fuente de invocación : API , otro FaaS o bien evento del proveedor / otros productos

24. Tipos de Arranque “Serverless”
Casi “todos” los proveedores serverless usan contenedores para generar
los entornos de ejecución
● Se requieren varios “segundos” o algunos “minutos”
● Depende de : proveedor, límites de lenguajes, tiempo / limites de
ejecución , tamaño de la función, etc.
● Los lenguajes interpretados suelen tener mejores tiempos de arranque y
consumo de recursos -> Depende del uso
Mejor para comunicación síncrona que asíncrona
Evitar arranques “Cold Start” -> Mantener las funciones “calientes”
● Los microservicios mantienen el servidor activo todo el tiempo
● Problema 1: ¿qué se entiende por microservicio?
● Problema 2: ¿se puede comparar con una función?

25. ¿Y dónde lo puedo utilizar?
PoCs y pilotos
Extensión backend
aplicaciones
(web/mobile/IoT)
APIs Microservicios
Orientación a
eventos -> EDA
(Event Driven
Architectures)
Uso de servicios
externos
Webhooks ETL
Tareas
programadas
Procesamiento de
datos
CDC (Change Data
Capture)
Pipelines CI / CD ...

26. Ventajas vs. Inconvenientes
● Evitar tener que mantener infraestructuras de servidores
(actualizaciones, ssh, backups, etc.) -> Ahorro costes
● Despliegue independiente y automatizado
● Facilita la IC
● Definición de funciones “pequeñas” -> única responsabilidad
● Definición de funciones desacopladas y a poder ser SIN estado
● Heterogeneidad de lenguajes
● Pago por uso
● “Cuando algo no se necesita entonces se apaga” -> ajuste costes
● Facilita la integración con otros servicios del proveedor (log,
monitorización,etc)
● Escalado particular (“grano fino”) horizontal con enfoque “elástico”
● -> Cuidado con los tiempos de arranque
● Desarrollo en la nube pública -> Aspectos de seguridad
● Desarrollo casi siempre acoplado al proveedor -> vendor lock-in
● Limitaciones -> enfoque de “caja negra”
● Entorno cerrado -> no se pueden realizar muchas personalizaciones u
optimizaciones
● Lenguajes y versiones proporcionados por el proveedor
● Tiempo máximo de ejecución de una función
● Tamaño máximo de la función y del uso de memoria
● Latencia inicial : arranque frío / caliente
● Pérdida del control cuando el nº de funciones crece mucho
● Detección de la trazabilidad de las peticiones
● Dificulta el despliegue cuando se trabaja con varias funciones
● Dificulta la monitorización -> requiere herramientas extra
● Inmadurez de herramientas a la hora de automatizar despliegues
● Dificultad de las organizaciones para romper el monolito
● Mejor para aplicaciones con una vida útil “corta”

27. 4. Laboratorio

28. AWS Lambda
https://aws.amazon.com/es/lambda/
AWS (Amazon Web Service) es uno de los negocios de Amazon
● Objetivo facilitar a las empresas /desarrolladores construir SW avanzado y escalable
haciendo uso de los servicios web
● Conceptos : instancia , monitorización , zona de disponibilidad, regiones, autoescalado,
elasticidad, pago por uso, etc.
● Servicios : Elastic Compute Cloud (EC2), Elastic Block Storage (EBS), Simple Storage Service
(S3), Almacenamiento [Glacier], Base de datos [DynamoDB, RDS, Simple DB], Aplicación
[CloudFront, SQS] y Otros [SNS, SES,Cloud Formation, etc] -> Cada día aparecen nuevos
AWS Lambda : Serverless FaaS orientado para Event-driven y proporcionado por AWS
● Diferentes lenguajes : Node.j, Python, C#, Go, Ruby, Java, etc
● Origen en 2014
● Requiere para su uso Amazon API Gateway
● Aplicar buenas prácticas : https://docs.aws.amazon.com/es_es/lambda/latest/dg/best-
practices.html
● Ejecuciones bajo petición de usuario , otro lambda o bien una alarma / métrica
● TRUCO : Especializar al máximo cada lambda -> Patrón “PSR”
Ejemplo Lambda
exports.myHandler = function (event, context,
callback) {
console.log('Hello World!')
callback(null, 'OK’)
}

29. Framework Serverless
https://serverless.com/
Herramienta por línea de comandos que permite trabajar con múltiples proveedores y que
permite automatizar una serie de tareas a través de comandos
• Se comunica directamente con el CLI de los proveedores
• Homogeniza el uso en los proyectos
• Soporta diferentes lenguajes
• Production-Ready
• Buena documentación y ejemplos -> https://github.com/serverless/examples
• Facilita el trabajo en modo Offline
• Extensibilidad de funciones con el uso de plugins
• Requiere tener instalado Node.js …

30. Local Stack
https://github.com/localstack/localstack
Herramienta que permite emular/mockear los servicios cloud de AWS en
local
● Originalmente era un proyecto de Atlassian
● Facilita poder probar antes de subir el código a PRO
● Para cada servicio establece un puerto para su uso
● La comunicación con cada uno de los servicios se realiza con el AWS CLI
● …

31. Plugins de Serverless
https://github.com/serverless/plugins
Se puede ampliar la funcionalidad de Serverless con plugins ya existentes o bien custom

32. Ejemplo Práctico Node.js
https://github.com/vjmadrid/enmilocalfunciona-aprendiendo-serverless/tree/master/meetup-bcn-mayo-2019
https://github.com/vjmadrid/enmilocalfunciona-aprendiendo-serverless
• Ejercicio Práctico : demo-nodejs-dynamodb-serverless
• Otros recursos

33. Resultado del Ejemplo Práctico Node.js

34. Ejemplo Práctico Python
https://gitlab.com/ruben-gil/serverless-framework-meetup/tree/solved
Nota : Tiene otra casuística

35. PREGUNTAS