Serverless, la nueva palabra de moda en la ciudad ha ganado mucha atención por parte de los profesionales y los novatos en la industria de la tecnología. En parte debido a la forma en que los proveedores de la nube como AWS han promocionado la arquitectura, desde conferencias hasta reuniones y publicaciones de blog en casi todas partes. Pero serverless no se trata solo de exageraciones, sino que promete la posibilidad de implementaciones comerciales ideales que suenan bastante agradables a los oídos y probablemente también sean livianas para el presupuesto. “Concéntrese en su , no en la ” aplicación infraestructura Sin embargo, suena aliviador saber que muchas de sus horas de luz se dedican a implementar, mantener, depurar y monitorear la infraestructura. Con todo ese trabajo pesado de infraestructura fuera del camino, realmente podemos centrarnos en los objetivos comerciales a los que sirven nuestras aplicaciones. Muchos esfuerzos productivos podrían canalizarse en la dirección correcta, donde debían estar idealmente. Tal vez suene demasiado bueno para ser verdad, pero así es como deberían haber sido las cosas. Al menos para aquellos de ustedes que no pueden permitirse pasar mucho tiempo atrapados en la red de complejidades de la infraestructura moderna y compleja. Dejando a un lado las expectativas, Serverless realmente está abriendo camino en su camino para interrumpir la infraestructura de su servidor. Serverless ya se utiliza en la producción de empresas como Netflix, Reuters, AOL y Telenor. La adopción en toda la industria aumenta constantemente. Serverless está listo para ocupar su propio lugar, pero no espere que Serverless conquiste su infraestructura por completo. Habrá casos de uso en los que serverless podría resultar ser la elección incorrecta. Entonces, ¿qué es sin servidor? Serverless es un modelo de ejecución de computación en la nube en el que el proveedor de la nube administra dinámicamente la asignación y el aprovisionamiento de servidores. Una aplicación sin servidor se ejecuta en contenedores de cómputo sin estado que son activados por eventos, efímeros (pueden durar una sola invocación) y completamente administrados por el proveedor de la nube. El precio se basa en la cantidad de ejecuciones en lugar de la capacidad de cómputo precomprada, ¿no es el marco ideal para ese proyecto que ha estado planeando durante mucho tiempo? Bueno, adelante, hazlo. Las aplicaciones sin servidor son sistemas basados en la nube impulsados por eventos en los que el desarrollo de aplicaciones se basa únicamente en una combinación de y llamadas a procedimientos remotos alojados en la nube . servicios de terceros, lógica del lado del cliente (Funciones como servicio) La mayoría de los proveedores de la nube han invertido mucho en serverless y eso es mucho dinero; con la promoción masiva dada y la oferta realista, puede asumir con seguridad que serverless será uno de los servicios en la nube más utilizados en los próximos años. Estos son algunos de los servicios en la nube disponibles actualmente: Fuente: https://www.slideshare.net/loige/building-a-serverless-company-with-nodejs-react-and-the-serverless-framework-jsday-2017-verona AWSLambda Funciones de la nube de Google Funciones de Azure IBM OpenWhisk Cálculo de la función de Alibaba Funciones de hierro Tarea web Auth0 Proyecto Oracle Fn sin kube Arquitectura tradicional frente a arquitectura sin servidor Fuente: https://www.gocd.org/2017/06/26/serverless-architecture-continuous-delivery/ Durante años, sus aplicaciones se ejecutaron en servidores que tuvo que parchar, actualizar y cuidar continuamente hasta altas horas de la noche y temprano en la mañana debido a todos los errores inimaginables que rompieron su producción. Mientras los administrara, toda la responsabilidad de su correcto funcionamiento recaía sobre usted. Serverless tiende a ser diferente a lo mencionado anteriormente, ya no necesita preocuparse por los servidores subyacentes. La razón es que usted ya no los administra y, con la administración fuera de escena, la responsabilidad recae en los proveedores de la nube. Pero independientemente de las características geniales de Serverless en algunos casos, la arquitectura tradicional lo eclipsa. Precios Una de las principales ventajas de usar Serverless es el costo reducido, durante años el costo de aprovisionar servidores y mantener ese equipo de servidores 24x7 que hizo un agujero en su bolsillo se ha ido. El modelo de costos de Serverless se basa en la ejecución: se le cobra por la cantidad de ejecuciones. Se le asigna una cierta cantidad de segundos de uso que varía según la cantidad de memoria que necesita. Asimismo, el precio por MS (milisegundo) varía según la cantidad de memoria que requieras. Obviamente, las funciones de ejecución más breves son más adaptables a este modelo con un tiempo máximo de ejecución de 300 segundos para la mayoría de los proveedores de la nube. El ganador aquí es Serverless Architecture. Redes La desventaja es que solo se accede a las funciones sin servidor como API privadas. Para acceder a estos, debe configurar una API Gateway. Esto no tiene un impacto en su precio o proceso, pero significa que no puede acceder directamente a ellos a través de la IP habitual, ¡chasquido! El ganador aquí es Arquitectura Tradicional. Dependencias de terceros La mayoría de sus proyectos, si no todos, tienen dependencias externas, se basan en bibliotecas que no están integradas en el lenguaje o marco que utiliza. A menudo usa bibliotecas con funcionalidades que incluyen criptografía, procesamiento de imágenes, etc., estas bibliotecas pueden ser bastante pesadas. Sin acceso a nivel de sistema, debe empaquetar estas dependencias en la propia aplicación. Reinventar la rueda no siempre es una buena idea. El ganador aquí se basa en el contexto. Para aplicaciones simples con pocas dependencias, Serverless es el ganador; para algo más complejo, la Arquitectura Tradicional es la ganadora. Entornos Configurar diferentes entornos para Serverless es tan fácil como configurar un solo entorno. Dado que es pago por ejecución, esta es una gran mejora con respecto a los servidores tradicionales, ya no necesita configurar máquinas de desarrollo, preparación y producción. Eventualmente perdería la cuenta de todos los entornos, en algún momento. El ganador aquí es Serverless Architecture. Se acabó el tiempo Con la informática sin servidor, hay un límite de tiempo de espera estricto de 300 segundos. Las funciones demasiado complejas o de ejecución prolongada no son buenas para Serverless, pero tener un tiempo de espera difícil hace que sea imposible realizar ciertas tareas. Un límite estricto en este tiempo hace que Serverless sea inutilizable para aplicaciones que tienen tiempos de ejecución variables y para ciertos servicios que requieren información de una fuente externa. El claro ganador aquí es la Arquitectura Tradicional. Escala El proceso de escalado para Serverless es automático y continuo, pero hay una falta de control o una ausencia total de control. Si bien el escalado automático es excelente, es difícil no poder abordar y mitigar los errores relacionados con las nuevas instancias sin servidor. Es un vínculo entre la arquitectura sin servidor y la tradicional. Funciones como servicio (FaaS) FaaS es una implementación de arquitecturas sin servidor donde los ingenieros pueden implementar una función individual o una parte de la lógica comercial. Comienzan en milisegundos (~100 ms para AWS Lambda) y procesan solicitudes individuales dentro de un tiempo de espera de 300 segundos impuesto por la mayoría de los proveedores de la nube. Principios de FaaS: Gestión completa de servidores. Facturación basada en invocación Basado en eventos y escalable instantáneamente Propiedades clave de FaaS: Funciones lógicas independientes del lado del servidor FaaS son similares a las funciones a las que está acostumbrado a escribir en lenguajes de programación, unidades de lógica pequeñas y separadas que toman argumentos de entrada, operan en la entrada y devuelven el resultado. Apátrida Con Serverless, todo es sin estado, no puede guardar un archivo en el disco en una ejecución de su función y esperar que esté allí en la siguiente. Cualquiera de las dos invocaciones de la misma función podría ejecutarse en contenedores completamente diferentes debajo del capó. Efímero FaaS está diseñado para funcionar rápidamente, hacer su trabajo y luego apagarse nuevamente. No se quedan sin usar. Mientras se realiza la tarea, los contenedores subyacentes se desechan. Evento activado Aunque las funciones se pueden invocar directamente, generalmente se desencadenan por eventos de otros servicios en la nube, como solicitudes HTTP, nuevas entradas de bases de datos o notificaciones de mensajes entrantes. FaaS a menudo se usa y se considera como el vínculo entre los servicios en un entorno de nube. Escalable por defecto Con las funciones sin estado, se pueden inicializar varios contenedores, lo que permite ejecutar tantas funciones (en paralelo, si es necesario) como sea necesario para atender continuamente todas las solicitudes entrantes. Totalmente gestionado por un proveedor de la nube AWS Lambda, Azure Functions, IBM OpenWhisk y Google Cloud Functions son las soluciones FaaS más conocidas disponibles. Cada oferta suele admitir una variedad de lenguajes y tiempos de ejecución, por ejemplo, Node.js, Python, .NET Core, Java. La aplicación sin servidor Una solución sin servidor consta de un servidor web, funciones Lambda (FaaS), servicio de token de seguridad (STS), autenticación de usuario y base de datos. Fuente: http://blog.tonyfendall.com/2015/12/serverless-architectures-using-aws-lambda/ : la interfaz de usuario de su aplicación se representa en el lado del cliente en Modern Frontend Javascript App, lo que nos permite usar un servidor web simple y estático. Aplicación de cliente : Amazon S3 proporciona un servidor web robusto y simple. Todos los archivos HTML, CSS y JS estáticos para nuestra aplicación se pueden servir desde S3. Servidor web : son los habilitadores clave en la arquitectura sin servidor. Algunos ejemplos populares de FaaS son AWS Lambda, Google Cloud Functions y Microsoft Azure Functions. AWS Lambda se utiliza en este marco. Los servicios de la aplicación para iniciar sesión y acceder a los datos se crearán como funciones de Lambda. Estas funciones leerán y escribirán desde su base de datos y proporcionarán respuestas JSON. Funciones Lambda (FaaS) : genera credenciales de AWS temporales (clave API y clave secreta) para los usuarios de la aplicación. La aplicación cliente utiliza estas credenciales temporales para invocar la API de AWS (y, por lo tanto, invocar Lambda). Servicio de token de seguridad (STS) : AWS Cognito es un servicio de identidad integrado con AWS Lambda. Con Amazon Cognito, puede agregar fácilmente el registro e inicio de sesión de usuarios a sus aplicaciones móviles y web. También tiene la opción de autenticar a los usuarios a través de proveedores de identidad social como Facebook, Twitter o Amazon, con soluciones de identidad SAML o utilizando su propio sistema de identidad. Autenticación de usuarios de datos: AWS DynamoDB proporciona una base de datos NoSQL completamente administrada. DynamoDB no es esencial para una aplicación sin servidor, pero aquí se usa como ejemplo. Base Beneficios de la arquitectura sin servidor Desde la perspectiva empresarial El costo en el que incurre una aplicación sin servidor se basa en el número de ejecuciones de funciones, medido en milisegundos en lugar de horas. Agilidad del proceso: las unidades implementables más pequeñas dan como resultado una entrega más rápida de funciones al mercado, lo que aumenta la capacidad de adaptarse al cambio. El costo de contratar ingenieros de infraestructura back-end se reduce. Costos operativos reducidos Desde la perspectiva del desarrollador Responsabilidad reducida, sin infraestructura back-end de la que ser responsable. Cero administración del sistema. Gestión operativa más sencilla. Fomenta la adopción de Nanoservicios, Microservicios, Principios SOA. Configuración más rápida. Escalable, no hay necesidad de preocuparse por la cantidad de solicitudes simultáneas. Monitoreo fuera de la caja. Fomenta la innovación. Desde la perspectiva del usuario Si las empresas están utilizando esa ventaja competitiva para enviar funciones más rápido, los clientes recibirán nuevas funciones más rápido que antes. Es posible que los usuarios puedan proporcionar más fácilmente su propio backend de almacenamiento (es decir, Dropbox, Google Drive). Es más probable que este tipo de aplicaciones ofrezcan almacenamiento en caché del lado del cliente, lo que proporciona una mejor experiencia sin conexión. Inconvenientes de la arquitectura sin servidor Desde la perspectiva empresarial Reducción del control general. El bloqueo del proveedor requiere más confianza para un proveedor externo. La exposición adicional al riesgo requiere más confianza para un proveedor externo. Riesgo de seguridad. Riesgo de recuperación ante desastres El costo es impredecible porque el número de ejecuciones no está predefinido Todos estos inconvenientes se pueden mitigar con alternativas de código abierto, pero a expensas de los beneficios de costos mencionados anteriormente. Desde la perspectiva del desarrollador La tecnología inmadura da como resultado la fragmentación de componentes, mejores prácticas poco claras. Complejidad arquitectónica. La disciplina requerida contra la dispersión de funciones. La tenencia múltiple significa que es técnicamente posible que las funciones vecinas puedan acaparar los recursos del sistema detrás de escena. Probar localmente se vuelve complicado. Restricciones significativas en el estado local. La duración de la ejecución está limitada. Falta de herramientas operativas. Desde la perspectiva del usuario A menos que se diseñe correctamente, una aplicación podría proporcionar una experiencia de usuario deficiente como resultado del aumento de la latencia de las solicitudes. Marcos sin servidor Fuente: / https//serverless.com Las plataformas sin servidor necesitan infraestructuras donde puedan ejecutarse, los marcos independientes del proveedor proporcionan una forma independiente de la plataforma para definir e implementar código sin servidor en varias plataformas en la nube o servicios comerciales. (Javascript, Python, Golang) Marco sin servidor (Javascript) Ápice (Javascript) ClaudiaJS (Golang) Esparta (Javascript) Gordon (Python) Zappa (Javascript, Python, Golang, Crystal) Arriba Resumen La arquitectura sin servidor es ciertamente muy emocionante, pero viene con un montón de limitaciones. Ya que la validez y el éxito de las arquitecturas dependen de los requerimientos del negocio y de ninguna manera únicamente de la tecnología. De la misma manera, Serverless puede brillar cuando se usa en el lugar adecuado. Eche un vistazo a la maravilla que es Serverless, es hora de echar un vistazo a cómo se ve Serverless desde el interior. Aquí hay algunos enlaces para que pueda comenzar su viaje sin servidor. serverless _Serverless Examples: una colección de repeticiones y ejemplos de arquitecturas sin servidor creadas con Serverless…_github.com /examples serverless _awesome-serverless - ☁️ Una lista seleccionada de increíbles servicios, soluciones y recursos para serverless / nobackend…_github.com anaibol/awesome- estáticos _Manejo de formularios estáticos con funciones lambda sin servidor de AWS_hackernoon.com Creación de un formulario de contacto sin servidor para sitios web Espero que este artículo haya ayudado a comprender la informática sin servidor. Me encantaría saber cómo usa Serverless en sus proyectos. Aplaude si aumentó tu conocimiento, ayúdalo a llegar a más personas.
