He oído decir que ‘serverless’ (sin servidor) es fantástico porque el código no se ejecuta en ningún servidor. Obviamente, el código no se ejecuta en el aire, así que ¿donde se ejecuta en una arquitectura serverless? ¿Qué es serverless y por qué ha generado tantas expectativas? ¿Están justificadas?
El término serverless se malinterpreta porque hay un servidor, pero los desarrolladores no necesitan preocuparse por su gestión. Usar serverless significa que los desarrolladores se ocupan de la aplicación a nivel de tarea en lugar de a nivel de servidor. Es decir, no necesitan preocuparse de gestionar y operar servidores o tiempos de ejecución en la nube o ‘on-premise’ (en local).
Serverless también puede describirse como Funciones como Servicio (FaaS). Los productos FaaS ejecutan funciones (código) que se ejecutan bajo demanda como respuesta a eventos. El beneficio de ejecutar código bajo demanda está en el caso de uso donde tu código no necesita estar ejecutándose todo el tiempo. Cuando usas un producto serverles tan sólo pagas por los recursos que consume tu aplicación, no por una unidad prepagada. En ciertos escenarios, esto puede ahorrarte dinero. El otro beneficio de tener tu código separado en funciones es que escalar y desplegar tan sólo ciertas funciones es más fácil. Imaginemos una función concreta que es mucho más pesada que otras; en una arquitectura serverless esa función se puede escalar individualmente en lugar de tener que escalar toda la aplicación entera.
Esto suena un poco a microservicios, y el concepto es similar. El objetivo de un microservicio es romper una aplicación grande en sistemas pequeños, desacoplados e independientes que se conectan de nuevo para que la aplicación funciones. Las funciones van un paso más allá y son más pequeñas que los microservicios, éstos pueden contener varias funciones. La diferencia está en los casos de uso. Algunas cosas no son apropiadas para las funciones y viceversa. Finalmente, las funciones serverless y los microservicios tienen su lugar en el desarrollo, pero cada uno tiene sus fortalezas y debilidades.
Así que, ¿cuáles son las fortalezas o beneficios de serverless? Hemos hablado acerca de su escalabilidad y coste pero ¿hay algo más? Como desarrollador, serverless está bien porque no necesitas ocuparte del servidor. En una situación en que sólo quieres escribir código que responda a eventos, pero no necesitas creas una aplicación entera, serverless es fantástico. Además, algunos servicios serverless como AWS Lambda proporcionan disponibilidad y tolerancia a fallos por defecto, así que como desarrollador tienes dos cosas menos de las que preocuparte. Además, serverless puede mejorar la resilencia de tu aplicación. Dado que el código no esta alojado en un servidor específico, no tienes un único punto de fallo. Si la máquina donde se ejecuta el código falla, el proveedor serverless pasará el código a otra máquina y la experiencia del usuario final no debería verse afectada. Básicamente, si los desarrolladores ya no se ocupan de los servidores, pueden invertir su tiempo en construir aplicaciones escalables y más fiables.
Pero aún así, alguien tiene que ocuparse de los servidores porque nuestro código no se ejecuta en el aire. Incluso desde la perspectiva de operaciones, hay potencial para ahorrar dinero. Primero, no estarás ejecutando y pagando las 24 horas, sólo bajo demanda. Además, igual que en los microservicios, con la infraestructura serverless puedes optimizar tus recursos y disminuir los costes.
Serverless parece fantástico hasta ahora, pero también tiene sus desventajas. Primero, está la complejidad de diseñar y mantener una infraestructura serverless. Separar tu aplicación en microservicios añade complejidad. Separar tus microservicios además en funciones lleva la complejidad a un nuevo nivel. Existe una complejidad arquitectónica en el diseño y construcción de una aplicación de arquitectura distribuida. Existe la complejidad de mantener este sistema y la desventaja de ‘debugar’ un sistema distribuido. Por ahora, no existen muchas herramientas que ayuden a los desarrolladores a monitorizar/debugar entornos serverless, pero seguro que pronto los habrá.
La segunda desventaja es el rendimiento. En una arquitectura serverless, experimentarás latencias más altas ya que tus funciones responden a disparadores en tu aplicación. Cuando tu función es invocada por primera vez, una máquina tiene que iniciarse para ejecutar la función. En las Lambdas de AWS, las instancias permanece activas hasta unos 10 minutos después de que se ejecuten por primera vez así que están disponibles para las siguientes invocaciones. Después de esos 10 minutos, tendrás que esperar de nuevo a que una instancia arranque. Si el rendimiento es una alta prioridad, es mejor seguir con servidores en cloud o bajo premisa.
El tercer problema es que nos atamos a un proveedor. Si cambiamos a otro, probablemente necesitaremos modificar nuestro código, herramientas, diseño o arquitectura. Así que mover tu código de una solución a otra requerirá esfuerzos. Actualmente hay varios proveedores en el mercado. Este es un pequeño resumen de los cuatro más importantes:
- AWS Lambda es probablemente el más grande y popular framework serverless. Empezó con Node.js pero ahora soporta Java y Python. Es interesante usar AWS Lambda ya que está integrado con otros servicios de AWS y Alexa Skills Kit. Un desarrollador puede usar la consola o herramientas de línea de comandos para gestionar el código.
- Google Cloud Functions es un competidor de AWS Lambda que se ejecuta en la nube de Google. Esta plataforma tan solo soporta Node.js. Una gran diferencia entra Google Cloud Functions y AWS Lambda es que el último proporciona muchos más servicios que pueden integrarse. Sólo unos pocos servicios como Google Cloud Storage están integrados con Google Cloud Functions.
- IBM Open Whisk es una alternativa de código abierto a AWS Lambda y está integrado con IBM Bluemix. OpenWhisk soporta Node.js y Swift. Los desarrolladores pueden interactuar con el framework gracias a un CLI y pueden instalar OpenWhisk en una máquina local con Ubuntu. Creo que la mejor parte de OpenWhisk es que puede integrarse con cualquier tercero que soporte Webhooks.
- Microsoft Azure Functions soporta variedad de lenguajes incluyendo JavaScript y Python. Microsoft proporciona un IDE en su portal para ayudar a los desarrolladores a crear prototipos y desplegar sus funciones.
Creo que AWS Lambda es el framework serverless más maduro. Se lanzó en 2014, mientras que Google y Microsoft lanzaron sus soluciones dos años después. AWS Lambda soporta características avanzadas como encadenamiento de peticiones, ‘edge processing’ y se integra con variedad de productos de AWS.
En conclusión, ¿están justificadas todas las expectativas de serverless? En ciertos casos de uso, serverless puede ser brillante. Si tu aplicación esta dirigida por eventos o usada esporádicamente y el rendimiento no es crítico, es un buen enfoque para consumir recursos en la nube manteniendo un coste bajo. Sin embargo, no es ideal para otras situaciones, como tener una tarea o servicio corriendo permanentemente. En estos escenarios, serverless puede acabar costando más dineros, perdiendo uno de sus beneficios principales. Creo que serverless aún está poco maduro y las empresas están intentado averiguar si es la solución correcta para ellas. Sin embargo, es interesante ver el futuro de serverless ya que creo que tiene un gran potencial, especialmente a medida que vaya evolucionando las herramientas de monitorización y debug.
Este es mi octavo artículo de la serie ‘What is’ en mi blog. Escribiré más cada semana aquí y en mi blog!
Puedes ver el artículo original en inglés en https://dev.to/aditichaudhry92/what-is-serverless-1bf