Aunque las tecnologías sin servidor han ganado popularidad rápidamente en los últimos años, aún existen muchos conceptos erróneos y preocupaciones al respecto. La dependencia del proveedor, las herramientas, la gestión de costos, el arranque en frío, la monitorización y el ciclo de vida del desarrollo son temas de discusión activa cuando se habla de tecnologías sin servidor. En este artículo, revisaremos algunos de estos temas mencionados y compartiremos consejos y enlaces a fuentes de información útiles que ayudarán a los principiantes a crear aplicaciones sin servidor potentes, flexibles y económicas.
Conceptos erróneos sobre las tecnologías sin servidor
Muchos creen que la sin servidor y el procesamiento de datos sin servidor (, FaaS) son prácticamente lo mismo. Esto significa que la diferencia no es muy grande y vale la pena adoptar la novedad. Aunque AWS Lambda fue una de las "estrellas" del auge de las tecnologías sin servidor y uno de los elementos más populares de la arquitectura sin servidor, esta arquitectura representa algo más que FaaS.
El principio fundamental de las tecnologías sin servidor es que no necesitas preocuparte por gestionar y escalar la infraestructura; solo pagas por lo que utilizas. Muchos servicios se ajustan a estos criterios: AWS DynamoDB, S3, SNS o SQS, Graphcool, Auth0, Now, Netlify, Firebase y muchos más. En general, la sin servidor implica el uso de todas las capacidades de la computación en la nube sin necesidad de gestionar la infraestructura y optimizarla para la escalabilidad. Esto también significa que la seguridad a nivel de infraestructura ya no es tu problema, lo cual es una gran ventaja, considerando la dificultad y complejidad de cumplir con los estándares de seguridad. Finalmente, no necesitas comprar la infraestructura que te es proporcionada.
La sin servidor puede considerarse un "estado mental": una mentalidad al diseñar soluciones. Evita enfoques que requieren mantener cualquier infraestructura. Con el enfoque sin servidor, dedicamos tiempo a resolver problemas que impactan directamente en el proyecto y benefician a nuestros usuarios: creamos una lógica de negocio sólida, desarrollamos interfaces de usuario y diseñamos APIs adaptativas y fiables.
Por ejemplo, si es posible evitar la gestión y el mantenimiento de la plataforma de búsqueda de texto completo, eso es exactamente lo que haremos. Este enfoque para construir aplicaciones puede acelerar significativamente el lanzamiento del producto al mercado, ya que no necesita preocuparse más por manejar una infraestructura compleja. Deshágase de las responsabilidades y costos de gestión de la infraestructura y concéntrese en crear aplicaciones y servicios que sus clientes necesitan. Patrick Deboua llamó a este enfoque , este término es aceptado en la comunidad sin servidor. Las funciones deben considerarse como un eslabón que une servicios en forma de módulos desplegables (en lugar de desplegar toda una biblioteca o aplicación web). Esto proporciona una granularidad increíble en la gestión del despliegue y los cambios en la aplicación. Si no puede desplegar funciones de esta manera, puede ser un indicativo de que las funciones están realizando demasiadas tareas y deben ser refactorizadas.
Algunos se sienten incómodos con la dependencia del proveedor al desarrollar aplicaciones en la nube. Lo mismo ocurre con las tecnologías sin servidor, y difícilmente esto es resultado de un malentendido. Según nuestra experiencia, crear aplicaciones sin servidor en AWS junto con la capacidad de AWS Lambda para integrar otros servicios de AWS, contribuye a las ventajas de las arquitecturas sin servidor. Este es un buen ejemplo de sinergia, donde el resultado de la combinación es mayor que la suma de sus partes. Al tratar de evitar la dependencia del proveedor, puede que se enfrente a problemas aún mayores. Con los contenedores, es más fácil gestionar su propio nivel de abstracción entre los proveedores de la nube. Pero cuando se trata de soluciones sin servidor, los esfuerzos no valdrán la pena, especialmente si se considera la eficiencia económica desde el principio. Asegúrese de averiguar cómo los proveedores garantizan la prestación de servicios. Algunos servicios especializados dependen de puntos de integración con otros proveedores, y pueden ofrecer de forma nativa la capacidad de conectar de manera plug-and-play. Es más sencillo invocar Lambda desde un endpoint de la API Gateway que hacer un proxy de la solicitud a algún contenedor o instancia de EC2. Graphcool permite una fácil configuración con Auth0, lo que es más sencillo que usar herramientas de autenticación de terceros.
Elegir el proveedor adecuado para su aplicación sin servidor es una decisión a nivel arquitectónico. Al crear una aplicación, no espera regresar alguna vez a la gestión de servidores. Elegir un proveedor de nube no es diferente de elegir el uso de contenedores, bases de datos, o incluso un lenguaje de programación.
Considere lo siguiente:
- Qué servicios necesita y por qué.
- Qué servicios ofrecen los proveedores de la nube y cómo puede combinarlos con la solución FaaS elegida.
- Qué lenguajes de programación son soportados (con tipado dinámico o estático, compilados o interpretados, qué benchmarks existen, cuál es el rendimiento en el arranque en frío, cuál es el ecosistema de código abierto, etc.).
- Cuáles son sus requisitos de seguridad (SLA, 2FA, OAuth, HTTPS, SSL, etc.).
- Cómo gestionar su CI/CD y los ciclos de desarrollo de software.
- Qué ventajas puede obtener de soluciones de infraestructura como código.
Si está ampliando una aplicación existente y añadiendo funciones sin servidor de manera incremental, esto puede limitar ligeramente las capacidades disponibles. Sin embargo, casi todas las tecnologías sin servidor ofrecen APIs (a través de REST o colas de mensajes) que permiten crear extensiones de manera independiente del núcleo de la aplicación y con una integración sencilla. Busque servicios con APIs claras, buena documentación y una comunidad fuerte, y no se equivocarás. La simplicidad de la integración a menudo puede ser una métrica clave, y probablemente sea una de las principales razones del éxito de AWS desde que Lambda se lanzó en 2015.
Cuándo es útil la computación sin servidor
Las tecnologías sin servidor se pueden aplicar prácticamente en cualquier lugar. Sin embargo, sus ventajas no se limitan a los casos de uso. La barrera de entrada a la computación en la nube hoy es tan baja precisamente gracias a las tecnologías sin servidor. Si los desarrolladores tienen una idea, pero no saben cómo gestionar la infraestructura en la nube y optimizar costos, no necesitan buscar un ingeniero para esto. Si una startup quiere crear una plataforma, pero teme que los gastos se salgan de control, puede recurrir fácilmente a soluciones sin servidor.
Gracias al ahorro de costos y la facilidad de escalado, las soluciones sin servidor son igualmente aplicables tanto para sistemas internos como externos, hasta web aplicaciones con millones de usuarios. Las facturas se miden más bien en céntimos que en euros. Alquilar el ejemplo más sencillo de AWS EC2 (t1.micro) durante un mes costará €15, incluso si no haces nada con él (¡quién no ha olvidado apagarlo alguna vez!). Para comparar, para alcanzar ese nivel de gastos en el mismo período, necesitarías ejecutar Lambda con 512 MB durante 1 segundo aproximadamente 3 millones de veces. Y si no utilizas esta función, no pagas nada.
Dado que la tecnología sin servidor depende principalmente de eventos, es bastante fácil añadir infraestructura sin servidor a sistemas antiguos. Por ejemplo, con AWS S3, Lambda y Kinesis, puedes crear un servicio de análisis para un antiguo sistema de venta al por menor que pueda recibir datos a través de una API.
La mayoría de las plataformas sin servidor admiten diferentes lenguajes. Los más comunes son Python, JavaScript, C#, Java y Go. Normalmente, no hay restricciones en el uso de bibliotecas en todos estos lenguajes, por lo que puedes utilizar tus bibliotecas de código abierto favoritas. Sin embargo, es recomendable no abusar de las dependencias para que tus funciones se ejecuten de manera óptima y no pierdan las ventajas de una enorme escalabilidad en tus aplicaciones sin servidor. Cuantos más paquetes deban cargarse en el contenedor, más tiempo tomará el inicio en frío.
El inicio en frío es cuando primero es necesario inicializar el contenedor, el entorno de ejecución y el manejador de errores antes de poder usarlos. Debido a esto, el retraso en la ejecución de funciones puede alcanzar hasta 3 segundos, lo que no es ideal para usuarios impacientes. Sin embargo, los inicios en frío ocurren en el primer acceso después de algunos minutos de inactividad de la función. Así que muchos lo consideran una incomodidad menor que se puede evitar mediante el pingueo regular de la función para mantenerla en modo standby. O incluso ignoran este aspecto.
Aunque AWS lanzó, las bases de datos SQL no son ideales para este tipo de uso, ya que al ejecutar transacciones dependen de conexiones, que pueden convertirse rápidamente en un cuello de botella bajo un gran tráfico en AWS Lambda. Sí, los desarrolladores están mejorando constantemente Serverless Aurora, y deberías experimentarla, pero hoy en día las soluciones NoSQL comoson mucho más adecuadas para sistemas sin servidor. Sin embargo, es indudable que esta situación cambiará muy pronto.
El conjunto de herramientas también impone muchas restricciones, especialmente en el área de pruebas locales. Aunque existen soluciones como Docker-Lambda, DynamoDB Local y LocalStack, requieren un trabajo meticuloso y una configuración considerable. Sin embargo, todos estos proyectos están en constante desarrollo, así que es solo cuestión de tiempo antes de que las herramientas alcancen el nivel que necesitamos.
El impacto de las tecnologías sin servidor en el ciclo de desarrollo
Dado que tu infraestructura es simplemente una configuración, puedes definir y desplegar código usando scripts, como scripts de shell. O puedes recurrir a soluciones del tipo configuration-as-code como . Aunque este servicio no proporciona una configuración para todos los ámbitos, permite definir recursos específicos para ser utilizados como funciones Lambda. Es decir, donde CloudFormation puede fallar, puedes escribir tu propio recurso (función Lambda) que cierre esta brecha. De esta manera, puedes hacer lo que desees, incluso configurar dependencias fuera de tu entorno AWS.
Dado que todo esto es solo una configuración, puedes parametrizar tus scripts de despliegue para entornos, regiones y usuarios específicos, especialmente si utilizas soluciones de tipo infrastructure-as-code como CloudFormation. Por ejemplo, puedes desplegar una copia de la infraestructura para cada rama en el repositorio, para probarlas de forma completamente aislada durante el desarrollo. Esto acelera radicalmente la retroalimentación de los desarrolladores, cuando quieren entender si su código funciona adecuadamente en un entorno real. Los gerentes no tienen que preocuparse por el costo de desplegar múltiples entornos, ya que solo se paga por el uso real.
Los DevOps tienen menos preocupaciones, ya que solo necesitan asegurarse de que los desarrolladores tengan la configuración correcta. Ya no es necesario gestionar instancias, balanceadores o grupos de seguridad. Por ello, se utiliza cada vez más el término NoOps, aunque sigue siendo importante saber configurar la infraestructura, especialmente en lo que respecta a la configuración de IAM y la optimización de recursos en la nube.
Existen herramientas muy potentes para monitoreo y visualización como Epsagon, Thundra, Dashbird e IOPipe. Estas herramientas permiten rastrear el estado actual de las aplicaciones sin servidor, proporcionan registros y trazas, registran métricas de rendimiento y cuellos de botella en la arquitectura, realizan análisis y pronósticos de gastos, y mucho más. No solo ofrecen a ingenieros DevOps, desarrolladores y arquitectos una visión exhaustiva del funcionamiento de las aplicaciones, sino que también permiten a los gerentes monitorear la situación en tiempo real, con gastos por segundo en recursos y pronósticos de costos. Organizar esto con infraestructura gestionada es mucho más difícil.
Diseñar aplicaciones sin servidor es mucho más sencillo, ya que no es necesario implementar servidores web, gestionar máquinas virtuales o contenedores, parchear servidores, sistemas operativos, puertas de enlace de internet, etc. La abstracción de todas estas responsabilidades permite que la arquitectura sin servidor se concentre en lo esencial: satisfacer las necesidades del negocio y de los clientes.
Aunque la herramienta podría ser mejor (se mejora cada día), los desarrolladores pueden centrarse en implementar la lógica empresarial y en la mejor distribución de la complejidad de la aplicación entre los distintos servicios dentro de la arquitectura. La gestión de aplicaciones sin servidor se lleva a cabo en base a eventos y está abstraída por el proveedor de la nube (por ejemplo, SQS, eventos S3 o flujos de DynamoDB). Por lo tanto, los desarrolladores solo necesitan escribir la lógica empresarial para reaccionar a ciertos eventos, sin preocuparse de cómo implementar mejor las bases de datos y las colas de mensajes, o cómo organizar el trabajo óptimo con los datos en almacenes de hardware específicos.
El código se puede ejecutar y depurar de forma local, al igual que en cualquier proceso de desarrollo. Las pruebas modulares permanecen igual. La capacidad de implementar toda la infraestructura de la aplicación mediante una configuración personalizable de la pila permite a los desarrolladores obtener rápidamente la retroalimentación necesaria, sin preocuparse por el costo de las pruebas o el impacto en costosos entornos gestionados.
Herramientas y metodologías para construir aplicaciones sin servidor
No existe una forma específica de construir aplicaciones sin servidor. Al igual que no hay un conjunto de servicios para esta tarea. AWS es actualmente el líder en soluciones sin servidor potentes, pero también considere , y . Si utiliza AWS, se puede recomendar el enfoque de construcción de aplicaciones llamado (SAM), especialmente al usar C#, ya que Visual Studio tiene herramientas excelentes. SAM CLI puede hacer lo mismo que Visual Studio, por lo que no pierde nada al cambiar a otro IDE o editor de texto. Por supuesto, SAM también funciona con otros lenguajes.
Si escribes en otros idiomas, el Serverless Framework es una excelente herramienta de código abierto que permite configurar cualquier cosa utilizando potentes archivos de configuración YAML. Además, el Serverless Framework es compatible con varios servicios en la nube, por lo que lo recomendamos a quienes buscan una solución multi-nube. Tiene una gran comunidad que ha creado numerosos complementos para satisfacer diversas necesidades.
Para pruebas locales, las herramientas de código abierto como Docker-Lambda, Serverless Local, DynamoDB Local y LocalStack son muy adecuadas. Las tecnologías sin servidor todavía están en una etapa temprana de desarrollo, al igual que las herramientas para ellas, por lo que al configurarlas para escenarios complejos de prueba requerirás esfuerzo. Sin embargo, implementar un stack en un entorno y probarlo allí es increíblemente barato. Y no necesitas hacer una copia local exacta de los entornos en la nube.
Para reducir los tamaños de los paquetes desplegados y acelerar las cargas, utiliza AWS Lambda Layers.
Utiliza los lenguajes de programación adecuados para tareas específicas. Cada lenguaje tiene sus propias ventajas y desventajas. Existen muchos benchmarks, pero JavaScript, Python y C# (.NET Core 2.1+) son los líderes en términos de rendimiento en AWS Lambda. Recientemente, AWS Lambda ha introducido la API de Runtime, que permite especificar el lenguaje y el entorno de ejecución deseados, así que experimenta.
Mantén un tamaño pequeño para los paquetes de despliegue. Cuanto más pequeños sean, más rápido se cargarán. Evita usar bibliotecas grandes, especialmente si solo utilizas un par de funciones de ellas. Si programas en JavaScript, utiliza herramientas de construcción como Webpack para optimizar la compilación e incluir solo lo que realmente necesitas. En .NET Core 3.0 hay QuickJit y Compilación por capas, que mejoran el rendimiento y ayudan mucho con las ejecuciones frías.
La dependencia de las funciones sin servidor de los eventos puede complicar inicialmente la coordinación de la lógica empresarial. En este sentido, las colas de mensajes y las máquinas de estado pueden ser increíblemente útiles. Las funciones Lambda pueden invocar entre sí, pero hágalo solo si no espera una respuesta («disparar y olvidar») — no querrá que le cobren por esperar a que otra función finalice. Las colas de mensajes son útiles para desagregar partes de la lógica empresarial, gestionar cuellos de botella en las aplicaciones y procesar transacciones (usando colas FIFO). Las funciones de AWS Lambda pueden ser asociadas a colas SQS como colas de mensajes
Conclusión
En los últimos años, las tecnologías sin servidor han evolucionado a un ritmo sin precedentes. Esta transición de paradigma está relacionada con ciertos malentendidos. Gracias a la abstracción de la infraestructura y la gestión de la escalabilidad, las soluciones sin servidor ofrecen beneficios significativos: desde la simplificación del desarrollo y los procesos de DevOps, hasta una gran reducción de los costos operativos.
Y aunque el enfoque sin servidor no está exento de desventajas, existen metodologías y patrones de diseño confiables a través de los cuales se pueden crear aplicaciones sin servidor robustas o integrar elementos sin servidor en arquitecturas existentes.
Fuente: habr.com
