Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Meetup En mi local funciona - Serverless... ¡en local! con Serverless Framework en AWS

180 visualizaciones

Publicado el

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)

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Meetup En mi local funciona - Serverless... ¡en local! con Serverless Framework en AWS

  1. 1. ¡Bienvenidos!
  2. 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. 3. https://enmilocalfunciona.io
  4. 4. Comenzamos el blog en 2016 Y poco a poco hemos ido creciendo:
  5. 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. 6. Serverless... ¡en local! con Serverless Framework en AWS
  7. 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. 8. Índice 1. Introducción 2. Entornos de Ejecución 3. Desarrollo “Serverless” 4. Laboratorio 5. Preguntas
  9. 9. 1. Introducción
  10. 10. En un mundo ideal ¿Serverless significa? … SIN Servidor
  11. 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. 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. 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. 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. 15. 2. Entornos de Ejecución Clásico / Mascota Cloud / Ganado Infraestructura como Código / IaC Serverless
  16. 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. 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. 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. 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. 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. 21. Símil Entorno de ejecución “Serverless”
  22. 22. 3. Desarrollo “Serverless”
  23. 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. 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. 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. 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. 27. 4. Laboratorio
  28. 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. 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. 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. 31. Plugins de Serverless https://github.com/serverless/plugins Se puede ampliar la funcionalidad de Serverless con plugins ya existentes o bien custom
  32. 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. 33. Resultado del Ejemplo Práctico Node.js
  34. 34. Ejemplo Práctico Python https://gitlab.com/ruben-gil/serverless-framework-meetup/tree/solved Nota : Tiene otra casuística
  35. 35. PREGUNTAS

×