Aplicaciones Serverless
•Descargar como PPTX, PDF•
0 recomendaciones•655 vistas
Los nuevos modelos de arquitectura basados en servicios Cloud ofrecen múltiples posibilidades a los arquitectos para diseñar todo tipo de soluciones, olvidándose de los requisitos de infraestructura. Desarrolla una aplicación sin la necesidad de una infraestructura explícita ni de conocimientos en servidores o despliegues.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (19)
Similar a Aplicaciones Serverless
Similar a Aplicaciones Serverless (20)
Más de atSistemas
Más de atSistemas (20)
Aplicaciones Serverless
- 1. MADRID · NOV 27-28 · 2015 Aplicaciones Serverless
- 3. 29 NOV · 2016 Qué vamos a ver Contexto de la aplicación Definición de la arquitectura La aplicación en marcha AWS Lambda desde cero Valoración Otras alternativas
- 4. 29 NOV · 2016 Contexto de la aplicación Inicio Rápido Lógica Negocio EscalableMulticanal Inversión Gradual Incidencias
- 5. 29 NOV · 2016 Arquitectura: Alternativas
- 6. 29 NOV · 2016 Arquitectura: Elección FaaS AWS Flexibilidad Inmediatez Mínima inversión Suite completa Nuestra experiencia AWS Lambda
- 7. 29 NOV · 2016 Function as a Service (FaaS) “Serverless can also mean applications where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party..” (ThoughtWorks) Mike Roberts: http://martinfowler.com/articles/serverless.html Cloud Eventos Efímera Escalable Sin estado Gestionada
- 8. 29 NOV · 2016 Arquitectura: Componentes IAM Role Security S3 API Gateway Lambda DynamoDB Route 53 ! ! ! CloudFront Alarm CloudWatch Monitoring
- 9. 29 NOV · 2016 API Gateway API REST
- 10. 29 NOV · 2016 Lambda Lógica Trigger Operación Multilenguaje Runtime
- 11. 29 NOV · 2016 Showtime!!!
- 12. 29 NOV · 2016 T2M Rendimiento CapacidadDelegación Bajo Coste Valoración
- 13. 29 NOV · 2016 Madurez Herramientas Mejores prácticas Plataforma Portable Evolución
- 14. 29 NOV · 2016 Otras alternativas
- 15. 29 NOV · 2016 APIs RAML en Amazon API Gateway AWS Lambda: Primeros pasosenmilocalfunciona.io @enmilocalfun
- 16. 29 NOV · 2016 Servicios: Transformación Digital PoCs y Estudios de Viabilidad Definición de Arquitecturas Implantación y Soluciones de Big Data y Data Lake Real Time Analytics eCommerce CMS Mobile Apps User Experience Marketing Digital Advanced Testing & QA DevOps, Agile y Ciclo de Vida del Software Entrega Continua Integración Continua B i g Data & Analytics Customer Experience DevOpsArquitectura de Soluciones M i g r a c i o n e s , Ad m i n i s t r a c i ó n y O p e r a c i o n e s Definición de Arquitecturas Multicanal Reingeniería de Procesos End to End Diseño e Implantación de APIs Estrategia de Gobierno y Catálogo de Servicios SOA/BPM
Notas del editor
- JUANJO
- LUISMI Motivación: De donde viene la idea de trabajar con una aplicación Serverless. Por qué elegimos que la aplicación estuviera implementada como una función como servicio. Mostrar la arquitectura planteada para poder ejecutar la aplicación Componentes infraestructurales que conforman el Core de una aplicación serverless y componentes complementarios que complementan la funcionalidad. Vamos a mostrar la aplicación en funcionamiento realizando una serie de peticiones y mostraremos sus logs de ejecución. Crearemos una nueva función desde cero Mostraremos alguna publicación nuestra relacionada con el tema de la charla. Analizaremos las ventajas e incovenientes de adoptar la estrategia Serverless en aplicaciones productivas y veremos cual es la evolución lógica de este tipo de plataformas. Veremos varias alternativas de plataformas de diferentes vendors que soporten este tipo de arquitecturas.
- JUANJO Aplicación Nos surgió la necesidad de implementar una aplicación inicialmente con un frontal web pero abierta a poder tener una aplicación móvil como frontal. Requisitos La aplicación debía estar en producción lo antes posible La aplicación debía asegurar alta disponiblilidad y escalabilidad ya que normalmente se tiene una carga de trabajo homogénea pero en determinadas ocasiones debe soportar mayores picos de carga La aplicación debe exponer un API estándar para que pueda ser fácilmente consumida desde diferentes frontales La aplicación necesita de una base de datos para almacenar la información de configuración y ejecución Situación Inicialmente no se dispone de un entorno para desarrollar la aplicación El cliente no dispone de la infraestructura necesaria para soportar la aplicación y no descarta soluciones en la nube Tenemos una cuenta AWS y conocemos lo que el vendor nos ofrece
- LUISMI Primero y en función de los requisitos de la aplicación nos planteamos la duda de implementar la aplicación basándonos en una Arquitectura Tradicional o en una Arquitectura Serverless basada en servicios cloud. Debido a las restricciones de tiempo y de infraestructura que teníamos optamos por irnos a la nube, despreocupándonos de montar nuevos entornos y solicitar la asignación de miembros del equipo de Sistemas. Cuando hablamos de una arquitectura Serverless podemos distinguir dos modelos: BaaS (Backend as a Service o Mobile Backend as a Service): Se trata de servicios en la nube que mediante SDKs y APIs permiten vincular aplicaciones web o aplicaciones móviles con sistemas de terceros alojados en la nube que proporcionan lógica de backend y gestionan el estado. BaaS: Evitan, a los desarrolladores, tener que partir desde cero en el momento de comenzar a implementar una aplicación ya que no hay que desarrollar un backend completo para cada aplicación a codificar. BaaS: Tradicionalmente no son muy flexibles en cuanto las posibilidad de customizar la interacción con el backend, por ejemplo en cuanto a incluir lógica personalizada de gestión de reintentos. BaaS: Implica que no se escribe lógica personalizada en la parte servidora, toda se tiene que escribir en la parte cliente, como se tienen varios clientes hay que replicar esta lógica y además no se puede exprimir el servidor por lo tanto mayor carga de trabajo para el cliente que afecta a consumos de bateria en aplicaciones móviles. Algunas de las funcionalidades que aporta el modelo (M)BaaS son: Almacenamiento de ficheros Compartición de ficheros Notificaciones push Analíticas de uso Integración con redes sociales Gestión de usuarios y roles Algunos ejemplos: Auth0 como servicio de autenticación Firebase como servicio de base de datos. El modelo de negocio se basa en pago por uso estableciendo diferentes planos de consumo. FaaS: El concepto se explica en la siguiente transparencia
- LUISMI Como hemos comentado, por las necesidades de nuestro proyecto, la lógica de negocio perteneciente al backend debía ser codificada por nosotros y no teníamos necesidad de utilizar aplicaciones o servicios de terceros. Estas premisas nos llevaron a optar por un modelo Serverless FaaS, el cual aseguraba: Inmediated: Permitiera comenzar a trabajar de manera inmediata. Simplicidad y agilidad: La implementación fuese sencilla y las tareas en fase de desarrollo se puedan completar de manera ágil. Minimizar al máximo la adaptación del código a la plataforma, permitiendo mantener el foco en los requisitos funcionales de la aplicación. Personalización: Flexibilidad en la elección del lenguaje de desarrollo. Multicanalidad: Estandarización de la interfaz expuesta. Bajo coste operativo: Liberación de tareas relativas al mantenimiento y operación de la infraestructura. En la elección de de Lambda como componente core de la solución se tuvo en cuenta: La facilidad de puesta en producción de la aplicación, llegando de manera rápida al mercado. La riqueza de la plataforma de AWS que agrupa todos los componentes necesarios para optar por el modelo Serverless. Nosotros teníamos ya experiencia trabajando con los servicios AWS y eso siempre es un plus.
- LUISMI LUISMI: Desaparición de la concepción de servidor en fase de desarrollo, lo que implica la despreocupación por la comunicación, el descubrimiento, la caída y el mantenimiento de la sesión en los servidores. Sin estado: No existe relación entre diferentes invocaciones, cada invocación desencadena en una ejecución independiente que no va a compartir nada con el resto de ejecuciones. Orientada a eventos: La aplicación permanece en escucha hasta recibir un evento que lanza la ejecución. Efímera: Los contenedores que soportan la aplicación pueden tener la vida de un solo evento si existe poca carga de trabajo, en contraprestación a las máquinas virtuales utilizadas para cubrir peticiones de manera permanente. Gestionada por un tercero: El código es responsabilidad del desarrollador pero la infraestructura y todo las tareas asociadas a la mismas se externalizan a un tercero. Es una nueva forma de entender el Cloud Computing que implica un cambio de mentalidad en desarrollo y explotación.
- LUISMI https://cloudcraft.co/view/b19eb033-fac8-4b06-ad13-fc06f7aaa59f?key=WNugrps-BvghPmkah6AbTA A continuación se presenta el diagrama de arquitectura con los componentes necesarios para ejecutar la aplicación: Aplicación Web cliente: Alojada en Bucket S3 Las APIs REST son ofrecidas por API Gateway y son consumidas por la aplicación cliente. API Gateway genera los eventos que recepcionan las funciones Lambda. Las funciones Lambda se comunican con la base de datos Dynamo DB para realizar las operaciones CRUD (consulta, lectura, actualización y borrado.) La monitorización recae de la parte del CloudWatch. IAM permite establecer el control de acceso mediante roles (que tienen asociados políticas) entre las APIs del Gateway y las funciones Lambda (No configurado en la demo) y entre estas y las tablas de la base de datos DynamoDB. También permite el envío de información a CloudWatch. -------------- S3 Bucket: Hosting de la aplicación cliente y si fuera preciso almacenamiento de imágenes API Gateway: HTTP Server con la función de enrutar peticiones HTTP a funciones FaaS. Mapeo de parámetros HTTP a argumentos de entrada de las funciones. Conversión de los resultados devueltos por la función a respuestas HTTP para devolver al cliente. Aporta funcionalidad adicional como autenticación, autorización, control de acceso, calidad del servicio a nivel de método, mocks, configuración de códigos de respuesta, monitorización, gestión de versiones, transformación de datos, caché de respuestas, generación de SDK’s para los clientes, gestión de API Keys, definición de APIs mediante Swagger. En definitiva creación y gestión de APIs. Soporta cientos de miles de peticiones concurrentes. Coste por número de peticiones y cantidad de información transferida. Da Soporte a integración con dispositivos móviles y a IoT gracias a la exposición de APIs. Lambda: ya comentado DynamoDB: Base de datos NoSQL que permite aliviar al desarrollador de las tareas de operación y escalado de una base de datos distribuida (Hardware, configuración, puesta en marcha, replicación, aplicación de parches o escalado de clúster).Monitorización de recursos y métricas de rendimiento. SDKs. IAM: Definición de rol que agrupe políticas para permitir enlazar los logs desde API Gateway a CloudWatch, para permitir la ejecución de funciones Lambda y la interactuación de estas con DynamoDB. CloudWatch: Integración con API Gateway para ofrecer las funcionalidades de monitorización a través dashboards personalizables con información relativa a volumen de llamadas recibidas, a métricas de rendimiento, a información sobre latencia y a las estadísticas de error.
- LUISMI Englobado dentro de los Application Services Exponer un API REST estándar, definida en Swagger (modelo, recursos y métodos) Enrutar peticiones HTTP a eventos que disparen funciones Lambda. Mapeo de parámetros HTTP a argumentos de entrada de las funciones. Conversión de los resultados devueltos por la función a respuestas HTTP para devolver al cliente. Conversión de códigos de respuesta. Creación de Mocks para simular las funciones Lambda cuando estas no estaban desarrolladas. Mantener versiones de las APIs y diferentes entornos. Identificación de clientes mediante API Keys. Planes de consumo para diferentes niveles de suscripción. Generación de SDK’s para Android, IOS y JavaScript. Cacheo de respuestas. Creación y gestión de APIs. Swagger, RAML. HTTP Server con la función de Transformación entre modelos, caché de respuestas. Autenticación, autorización, control de acceso, calidad de servicio. Generación de SDK’s para facilitar adopción en clientes.. Soporta cientos de miles de peticiones concurrentes. Coste por número de peticiones y cantidad de información transferida. Soporte a integración con dispositivos móviles y a IoT gracias a la exposición de APIs Comparación con API Management Implica conocimiento de conceptos y configuraciones propias de Gateways hasta para el uso de las funciones más sencillas, mediante la inclusión de patrones los Gateways deberán evolucionar para evitar caer en configuraciones erróneas.
- JUANJO Orientado a eventos Coste por uso Multilenguaje Alta disponibilidad Escalabilidad Operación: Consola, CLI, SDK
- LUISMI: Aplicación gestión incidencias. 5 minutos.
- LUISMI 1. Infraestructura externalizada Serverless se basa en el concepto de externalización lo que implica: Liberación de este tipo de tareas (planning , setup, mantenimiento) tanto a nivel de equipos de sistemas como a nivel del desarrollador. No hay administración de sistemas. Reducción de tiempos de desarrollo gracias a la simplificación de DevOps a solo Dev. El despliegue se limita a empaquetar y subir el código olvidándonos de otras tareas asociadas a despliegues tradicionales (scripts de arranque y parada, contenedores, nada de herramientas de gestión de la configuración, chef/puppet…) Entornos siempre disponibles. 2. Coste Menor coste en personal: Al liberar de tareas de Operación a los equipos estos tendrán que utilizar menos horas de trabajo en llevar a producción una aplicación por lo que estos equipos podrán reducirse. Reducción del tiempo de trabajo del equipo de Infraestructura y Sistemas. Menor coste en Infraestructura: El proveedor gestiona la infraestructura de múltiples aplicaciones (Compartición de hardware y red) pertenecientes a diferentes compañías, por lo que trabaja a gran escala, lo que implica que puede rebajar mas las tarifas que si trabajara en exclusiva para un cliente particular. En función de la utilización, es pago por uso. Cuando no hay invocaciones no se genera gasto. Eliminación de servidores propios configurados para soportar picos puntuales de trabajo y que la mayor parte del tiempo mantienen ciclos de CPU sin uso. Aplicaciones con peticiones muy ocasionales (microservicios) Aplicaciones con fases de picos de carga periódicos que hacen que el tráfico no sea homogéneo, no implica ninguna modificación en un modelo Serverless. Permite hacer pruebas con nuevas aplicaciones, incluso llegando a no sobre pasar el nivel de uso gratuito que suelen ofrecer los proveedores. Reducción del Time To Market, una nueva idea o modificación llega de forma rápida a estar desplegada. Si se optimiza el código de la aplicación, pasando a ejecutar una funcionalidad de manera mas rápida se ahorra tiempo de procesamiento en el servidor lo que conlleva un ahorro en el coste del pago por uso. Por todo esto el modelo Serverless interesa a pequeñas Startups y no tan pequeñas Netflix tiene en su roadmap la adopción de Lambda para: Procesos de codificación (Enconding) de ficheros multimedia y validación de procesos de backup entre otros. BaaS: Se externalizan aplicaciones enteras como servicios de autenticación Auth0 o base de datos Firebase. Reducción de costes de desarrollo. 3. Capacidad Gestión de grandes volúmenes de peticiones y datos sin necesidad de realizar planificaciones extraordinarias ni de tomar decisiones en cuanto a futura capacidad de procesamiento. El problema del número de peticiones concurrentes que el servidor es capaz de procesar en un servidor antes desaparece. 4. Rendimiento Escalabilidad horizontal es automática, elástica y gestionada por el proveedor. Las instancias que levantan las funciones son creadas y destruidas en función de la carga de trabajo instantánea, son efímeras. El problema del número de peticiones concurrentes que soporta el servidor antes de ver muy empobrecido su rendimiento desaparece. Lenguaje de programación soportados La adopción de este tipo de arquitectura por parte los usuarios se ve favorecida por la posibilidad de desarrollar en diferentes lenguajes de programación (JavaScript, Java, Phyton, JRuby…). El número de lenguajes aún es limitado. 6. Eco La mayoría de los servidores están en funcionamiento con una carga muy baja de trabajo, ya que deben soportar picos de carga, al reducir considerablemente el número de servidores ineficientes el impacto medioambiental sería menor.
- LUISMI Las arquitecturas Serverless se basan en una tecnología muy reciente (apenas dos años de vida) con lo que todavía tienen un largo camino que recorrer en el cual tendrán que ir puliendo las dificultades que a día de hoy nos encontramos al trabajar con ella. Infraestructura: Comentar también la posibilidad de private serverless Herramientas Para realizar tareas de este tipo (con herramientas que sean propias del vendor y externas) tanto en FaaS como en Gateways: Agrupar funciones para su despliegue Configuración a nivel de entorno Monitorización y logging analytics Depuración Estado Mantener el estado es una demanda. In process Cachés: Se vería algo mejorado mantenindo vivas las intancias de las funciones por mas tiempo. Mejoras infraestructales de plataforma Que permitan resolver problemas como la latencia inicial o la duración de las ejecuciones Surgimiento de mejores prácticas Surgimiento de patrones de todo tipo que permitan estandarizar el trabajo con funciones. Despliegues atómicos. Tamaño de las funciones. Hitos en migraciones desde arquitecturas tradicionales. Hibridación entre servidores tradicionales, Baas y Faas Mas lenguajes Inclusión de mas lenguajes de programación Test de integración y aceptación En máquinas locales donde se tenga todo el control Portabilidad Estandarización de actividades como despliegue, configuración, interfaz… para aliviar el vendor locking actual Nacimiento de nuevos frameworks que buscan la abstranción del vendor. Abstracción de Triggers de componentes propietarios. Private Serverless
- JUANJO Amazon AWS El vendor más conocido y consolidado en arquitecturas Serverless. Google Cloud Functions Versión Alpha Eventos emitidos por Google Cloud Storage y Google Cloud Pub/Sub pueden activar de forma asíncrona las funciones. Para ejecuciones asíncronas se utilizan invocaciones HTTP. Las funciones están en escritas en Javascript y corren en un entorno de ejecución Node.js estándar. Portables a otros entornos de ejecución Node.js → Depuración. Despliegue directo desde repositorios GitHub o Bitbucket. Oracle Cloud Paas Functions Futuro nuevo miembro de Oracle PaaS Cloud Services. Una función puede pertenecer a un stack, que es una colección de componentes que se gestionan conjuntamente (start, stop, patch, scale...). Triggers que reaccionan ante eventos emitidos por: Kafka Event Bus API Platform Database (DBaaS) MySQL CS Cache WebHooks Eventos provenientes os de Management Cloud (APM, Log Analytics) Mensajes provenientes de Messaging Cloud Soporta varios lenguajes (todos los soportados en el Application Container Cloud Service) IBM Bluemix OpenWhisk OpenWhisk Runtime Open Source bajo licencia Apache 2.0 (Disponible en GitHub) Las funciones se denominan acciones y se implementan entre otros en Java, Node.js y Swift vía contenedores Dockers en el open source OpenWhisk Utiliza reglas de negocio para enlazar eventos con triggers y acciones Una acción puede ejecutar cualquier binario en un contenedor Docker. Acceso simplificado a servicios cognitivos Watson (sin coste de salida de red) Al estar disponbile en GitHub se puede implantar en un servidor local CLI, UI y SDK para invocar vía API a las acciones Red Hat Openshift Iron.io Beta? Iron.io es una plataforma de procesamiento serverless multi-cloud Triggers de tipo: webhooks pub/sub schedules queues API Endpoints Flujos asíncronos cubiertos end to end La plataforma Iron.io expone Intefaz y API. Iron.io ha sido partner de Openshift gracias a varios productos disponibles en Openshift Hub. Hybrid iron.io.se integra de manera sencilla plataformas basadas en contendores como OpenShift gracias a un servicio de ejecución desplegable de manera independiente. ( Hybrid iron.io es una container image on Docker Hub ) Cuando un job se levanta, el runner coge la imagen Docker asociada y utiliza un contenedor nuevo, ejecuta el proceso, y destruye el contenedor. Este proceso lo repite a gran escala. Azure Functions Preview El trigger de las funciones puede saltar por un evento en un servicio Azure, en SaaS (OneDrive) por un servicio de tercero, por un sistema on premise, por un timer basado en sintaxis CRON.o por un WebHook. Soporta lenguajes como Javascript, C#, Phyton y PHP Soporta scripting como Bash, Batch y PowerShell Soporta despligue contínuo basado en Visual Studio Team Services, GitHub y BitBucket
- JUANJO