Cómo la computación sin servidor ahorra tiempo y dinero

0
159

Los desarrolladores pasan innumerables horas resolviendo problemas de negocios con el código. Luego es el turno del equipo de operaciones. En primer lugar, éste pasa innumerables horas descubriendo cómo obtener el código que los desarrolladores escriben y ejecutan en las computadoras disponibles. En segundo lugar, el equipo se asegura de que aquellas computadoras funcionen correctamente. La segunda parte es realmente una tarea interminable. ¿Por qué no delegar esa parte a otra persona?

Durante las últimas dos décadas, una gran cantidad de innovación en TI -máquinas virtuales, computación en la nube, contenedores- se ha centrado en asegurarse de que no tenga que pensar mucho en la máquina física subyacente en la cual se ejecuta su código. La computación sin servidor es cada vez más un paradigma popular, que lleva este deseo a su conclusión lógica: con la computación sin servidor, no tiene que saber nada sobre el hardware o el sistema operativo en el cual se ejecuta su código, ya que todo está a cargo de un proveedor de servicios.

¿Qué es la computación sin servidor?
La computación sin servidor es un modelo de ejecución para la nube en el cual un proveedor de nube asigna dinámicamente -y luego le cobra al usuario- solo los recursos de cómputo y almacenamiento necesarios para ejecutar una determinada pieza de código. Naturalmente, todavía existen servidores involucrados, pero su abastecimiento y mantenimiento están totalmente a cargo del proveedor. Chris Munns, promotor de la computación sin servidor de Amazon, afirmó en una conferencia en el 2017 que, desde la perspectiva del equipo que escribe e implementa el código, «no existen servidores para administrar ni abastecer en absoluto. Esto no incluye nada que sea básico, nada que sea virtual, nada que sea un contenedor -nada que involucre que usted administre un host, actualice un host o se ocupe de nada a nivel de sistema operativo, no es algo que deba hacer en el mundo sin servidor”.

Como el desarrollador Mike Roberts explica, el término se usó una vez para los denominados contextos de back end como servicio, donde una aplicación móvil se conecta a un servidor back end alojado completamente en la nube. Pero hoy en día, cuando las personas hablan de computación sin servidor o de una arquitectura sin servidor, se refieren a las ofertas de función como servicio, en las que un cliente escribe un código que solo aborda la lógica de negocios y lo carga a un proveedor. Ese proveedor se encarga de todo el abastecimiento de hardware, la máquina virtual y la administración de contenedores, e incluso las tareas como multithreading, que a menudo están incorporadas en el código de la aplicación.

Las funciones sin servidor son controladas por eventos, lo que significa que el código se invoca solo cuando es activado por una solicitud. El proveedor cobra solo por el tiempo de procesamiento utilizado por esa ejecución, en lugar de una tarifa mensual fija, para mantener un servidor físico o virtual. Estas funciones pueden conectarse entre sí para crear un canal de procesamiento; o pueden servir como componentes de una aplicación más grande, interactuando con otro código que se ejecuta en contenedores o en servidores convencionales.

Los beneficios y desventajas de la computación sin servidor
A partir de esa descripción, dos de los mayores beneficios de la computación sin servidor deberían quedar claros: los desarrolladores pueden centrarse en los objetivos comerciales del código que escriben -en lugar de en cuestiones de infraestructura- y, de manera muy detallada, las organizaciones solo pagan por los recursos de cómputo que realmente usan, en lugar de comprar hardware físico o alquilar instancias de nube que, en su mayoría, permanecen inactivas.

Como Bernard Golden señala, este último punto es de particular beneficio para las aplicaciones basadas en eventos. Por ejemplo, podría tener una aplicación que está inactiva la mayor parte del tiempo, pero en ciertas condiciones debe manejar muchas solicitudes de eventos a la vez. O puede tener una aplicación que procesa datos enviados desde dispositivos de Internet de las cosas (IoT, por sus siglas en inglés) con conectividad a Internet limitada o intermitente. 

En ambos casos, el enfoque tradicional requeriría el abastecimiento de un servidor robusto que pueda manejar las capacidades de trabajo máximas -pero ese servidor estará subutilizado la mayor parte del tiempo. Con una arquitectura sin servidor, solo pagaría por los recursos del servidor que realmente usa. La computación sin servidor también sería buena para tipos específicos de procesamiento por grupos. Uno de los ejemplos canónicos de un caso de uso de arquitectura sin servidor es un servicio que carga y procesa una serie de archivos de imagen individuales y los envía a otra parte de la aplicación.

Quizás la desventaja más obvia de las funciones sin servidor es que son intencionalmente efímeras y, como afirma AlexSoft, «no es adecuado para tareas a largo plazo”. La mayoría de los proveedores sin servidor no permitirán que su código se ejecute por más de unos cuantos minutos. Cuando activa una función, ésta no retiene ningún dato estadístico de las instancias ejecutadas anteriormente. Un problema relacionado es que el código sin servidor puede tardar varios segundos en activarse, no es un problema en muchos casos de uso, pero si su aplicación requiere baja latencia, tenga cuidado.

Muchos de los otros inconvenientes, como lo señalan Rohit Akiwatkar y Gary Arora, tiene que ver con quedar atado al proveedor. Aunque existen opciones de código abierto disponibles, el mercado sin servidor está dominado por los grandes proveedores comerciales de nube, de los que hablaremos en un momento. Eso significa que, con frecuencia, los desarrolladores terminan usando herramientas de sus proveedores, lo que dificulta el cambio si se sienten insatisfechos. Asimismo, debido a que gran parte de la computación sin servidor tiene lugar, por definición, en la infraestructura del proveedor, puede ser difícil integrar el código sin servidor en canales internos de desarrollo y prueba.

Los proveedores sin servidor: AWS Lambda, Azure Functions y Google Cloud Functions
La era moderna de la computación sin servidor comenzó con el lanzamiento de AWS Lambda, una plataforma basada en el servicio de nube de Amazon, en el 2014. En el 2016, Microsoft siguió su ejemplo con Azure FunctionsGoogle Cloud Functions, que había estado en versión beta desde el 2017, finalmente alcanzó el estado de producción en julio del 2018. Los tres servicios tienen diferencias ligeramente distintas en cuanto a limitaciones, ventajas, lenguajes con soporte y formas de hacer las cosas. Rohit Akiwatkar cuenta con un resumen útil y detallado sobre las distinciones entre los tres. También se está ejecutando IBM Cloud Functions, que se basa en Apache OpenWhisk, una plataforma de código abierto.

Entre todas las plataformas de computación sin servidor, AWS Lambda es la más prominente, y obviamente ha tenido más tiempo para evolucionar y madurar.

Los stacks sin servidor
De manera similar a muchos reinos de software, el mundo sin servidor ha visto la evolución de los stacks de software, que reúnen diferentes componentes necesarios para construir una aplicación sin servidor. Cada stack consta de un lenguaje de programación en el que va a escribir el código, un marco de trabajo para la aplicación que proporciona una estructura para su código, y un conjunto de activadores que la plataforma comprenderá y usará para iniciar la ejecución del código.

Si bien puede combinar diferentes ofertas específicas en cada una de estas categorías, existen limitaciones según el proveedor que utilice, así como algunas cosas en común. Para los lenguajes, por ejemplo, puede usar Node.js, Java, Go, C# y Python en AWS Lambda; pero solo JavaScript, C# y F# funcionan de forma nativa en las funciones de Azure. Cuando se trata de activadores, AWS Lambda tiene la lista más larga, pero muchos de ellos son de la plataforma AWS específicamente, como Amazon Simple Email Service y AWS CodeCommit. Mientras tanto, las funciones de Google Cloud pueden activarse mediante solicitudes HTTP genéricas. Paul Jaworski analiza en profundidad los stacks para cada una de las tres grandes ofertas.

Los marcos de trabajo sin servidor
Vale la pena detenerse un poco en el componente del marco de trabajo, ya que eso definirá mucho la manera cómo terminará construyendo su aplicación. Amazon tiene su propia oferta nativa, el Serverless Application Model (SAM) de código abierto, pero también existen otros, la mayoría de los cuales son multiplataforma y también son de código abierto. Uno de los más populares es el llamado Serverless, y destaca que proporciona la misma experiencia en cada plataforma compatible, es decir: AWS Lambda, Azure Functions, Google Cloud Functions e IBM OpenWhisk. Otra oferta popular es Apex, que puede ayudar a incorporar algunos lenguajes que podrían no estar disponibles en ciertos proveedores.

Las bases de datos sin servidor
Como señalamos anteriormente, una de las peculiaridades de trabajar con código sin servidor es que no tiene un estado persistente, lo que significa que los valores de las variables locales no persisten en las instancias. Cualquier dato persistente al que deba acceder su código debe almacenarse en otro lugar y, para los principales proveedores, los activadores disponibles en los stacks incluyen bases de datos con las que pueden interactuar sus funciones.

Algunas de estas bases de datos se denominan sin servidor. Esto significa que se comportan de manera muy similar a otras funciones sin servidor que hemos analizado en este artículo, con la obvia excepción de que los datos se almacenan de forma indefinida. Pero se deja de lado a gran parte de la sobrecarga de administración involucrada en el abastecimiento y mantenimiento de una base de datos. Como lo indica el desarrollador Jeremy Daly, «Todo lo que necesita hacer es configurar un clúster, y le manejarán automáticamente toda la actualización del mantenimiento, los backups y las escalas”. Al igual que con las ofertas de función como servicio, solo paga por el tiempo de cómputo que realmente usa, y los recursos se incrementan y disminuyen según sea necesario para equiparar la demanda.

Cada uno los tres grandes proveedores sin servidor ofrecen sus propias bases de datos sin servidor: Amazon tiene Aurora Serverless y DynamoDB, Microsoft tiene Azure Cosmos DB, y Google tiene Cloud Firestore. Sin embargo, éstas no son las únicas bases de datos disponibles. Nemanja Novkovic tiene información sobre más ofertas.

La computación sin servidor y Kubernetes
Los contenedores ayudan a potenciar la tecnología sin servidor, pero el proveedor se encarga de la administración de los elementos generales y, por lo tanto, es invisible para el usuario. Muchos ven la computación sin servidor como una forma de obtener muchas de las ventajas de los microservicios en contenedores, sin tener que lidiar con su complejidad; e incluso están empezando a hablar de un mundo de postcontenedores.

En realidad, los contenedores y la computación sin servidor, casi con toda seguridad, coexistirán durante muchos años. En realidad, las funciones sin servidor pueden existir en la misma aplicación que los microservicios en contenedores. Kubernetes, la plataforma de orquestación de contenedores más popular, también puede administrar infraestructuras sin servidor. De hecho, con Kubernetes puede integrar diferentes tipos de servicios en un solo clúster.

La computación sin servidor offline
Es posible que la posibilidad de comenzar con la computación sin servidor sea un poco intimidante, ya que parece que necesitaría registrarse con un proveedor para jugar y ver cómo funciona. Pero no tema: existen formas de ejecutar el código sin servidor offline en su propio hardware local. Por ejemplo, el SAM de AWS proporciona la función Local, que le permite probar el código Lambda offline. Y si está utilizando el marco de trabajo para la aplicación Serverless, visite serverless-offline, un complemento que le permite ejecutar el código localmente. ¡Feliz experimentación!

Josh Fruhlinger, InfoWorld