Aplicaciones web sin servidor, o casi (arquitecturas serverless)

¿Cómo es esto posible? Si tenemos una cosa clara en el mundo de Internet es que si queremos tener en pie un servicio, éste debe estar alojado en una máquina que esté conectada a Internet, con energía y que nos asegure en cierta forma que está levantada. Estos servidores pueden ser de diversos tipos según las necesidades de la aplicación: web, base de datos, autentificación, tareas, logs, notificaciones, etc. Así que, ¿qué es esto de aplicaciones sin servidor? ¿o serverless?

¿Sin servidor? Serverless?

En realidad, este término no tiene que ver con que exista físicamente un servidor o no, sino con el hecho de delegar su administración a un tercero. Al mismo tiempo, nosotros no pedimos un servidor, pedimos un servicio Por lo que este término se aplica siempre que no tengamos que administrar el servidor que ejecuta un servicio, es más, en muchos casos, no sabemos sus características ni tenemos acceso a él más allá del servicio que ejecuta. Es más, el proveedor nos da un punto de entrada para poder llamar al servicio, y lo que haya por detrás será todo un misterio. Ellos nos garantizan el servicio encargándose de todo.

Esto pueden ser aplicaciones en la nube (ay la nube, ese gran desconocido, literalmente), como bases de datos, servidores de autentificación, incluso APIs para nuestras aplicaciones. Esto se utiliza sobre todo para aplicaciones móviles, en las que disponemos de un frontend y por detrás se hacen llamadas a servicios web que a su vez pueden hacer llamadas a otros servicios, todos remotos. Esto se suele llamar BaaS (Backend as a Service).

Por otro lado, algo que está muy de moda últimamente es la ejecución de funciones como servicio o FaaS (Functions as a Service), de hecho casi siempre que escuchemos algo sobre Serverless se referirán a esto y no es más que el alojamiento y ejecución de código por un tercero en contenedores de cómputo descentralizados y administrados por un tercero. Estos terceros suelen ser IBM, Google, Microsoft, Amazon, etc En definitiva, nuestro código no sabemos dónde se aloja ni dónde se ejecuta, sólo sabemos cómo llamarlo y cómo ver la respuesta de la ejecución. Es más, dependiendo del uso que hagamos de esta tecnología puede que haya muchas máquinas ejecutando nuestro código a la vez, sirviendo respuestas para nuestras aplicaciones… y todo sin tener que montar ni contratar un servidor.

Como hemos podido ver, estas soluciones son administradas, es decir, tampoco necesitamos que nadie se tome molestas para encargarse de la seguridad del servidor, balanceo de carga, actualizaciones de software, direccionamiento, almacenamiento, ni nada. Sólo debemos encargarnos de subir nuestro código y listo. Pero claro, eso de Serverless, seguro que se le ocurrió a uno de marketing porque suena muy bien. Está claro que servidor sí que hay, pero bueno, no tenemos que prestarle mucha atención.

¿Para qué quiero yo esto?

El objetivo, además de que es algo muy moderno, por un lado es que se reducen costes. Aunque hay que mirarlo con lupa y estudiar casos concretos. Es decir, para una empresa, el tiempo de un empleado supone dinero y el tiempo que el empleado invierte en tareas de mantenimiento de un servidor, significa una inversión económica. Además, tener una máquina contratada para realizar un servicio determinado es también una inversión económica, generalmente en forma de alquiler mensual y esto cubre momentos en los que se está utilizando el servicio y momentos en los que no hay nada utilizándose. Y normalmente, las empresas que facilitan este tipo de servicios cobran por el tiempo de uso de los servicios.

Por otro lado, nos garantiza la escalabilidad de los servicios (escalabilidad? Introducción a la escalabilidad de aplicaciones web. Técnicas, opciones, seguridad y consejos.). Ya que, en el caso de FaaS, sólo ejecutamos funciones, estas funciones podrán conectar con bases de datos y utilizar servicios externos, pero gozan de independencia de la máquina donde se ejecutan por lo que podremos llamar al servicio las veces que necesitemos, simultáneamente y no debemos tener ningún problema en la disponibilidad (no es plan de hacermos un DDOS tampoco). En el caso de BaaS también estamos llamando a servicios independientes por lo que el escalado no es un problema.
El caso es que el tema del escalado, que bien nos puede suponer un quebradero de cabeza de esta forma es transparente a nosotros y lo harán los servicios de manera natural.

Paranoico de mí

Pero claro, estamos dependiendo de un tercero, o de varios terceros, no tenemos control sobre la infraestructura, en muchos casos ni podemos visitarla, internamente no sabemos cómo funciona (más allá de lo que nos cuentan), puede que hasta desconozcamos la versión exacta del software que ejecutan estos contenedores. Aunque es verdad que las empresas muestran gran transparencia en sus operaciones no es lo mismo que si lo hicieras tú.
Siguiendo con la dependencia, la supervivencia de nuestras aplicaciones depende por completo de los servicios del tercero que contratamos. Eso quiere decir que si la empresa cambia sus condiciones (empeorándolas) tenemos un problema, si hacen una actualización de software y nuestro código no es compatible, tenemos otro problema gordo, si la empresa cierra (recordemos que todos los imperios han caído tarde o temprano), tenemos un problema más gordo aún y cambiar de empresa puede ser otro problema si no lo abordamos desde el principio.

No es lo mismo contratar un VPS con un sistema operativo donde podemos copiar los archivos de nuestra aplicación y desplegar (más o menos) que si tenemos que realizar cambios en nuestra aplicación para hacer llamadas a los servicios que hemos cambiado de empresa. Normalmente cada una tiene sus APIs para garantizar los accesos a sus servicios, autentificación de las llamadas, disparadores, etc. Aunque todos suelen tener partes comunes, también tienen sus particularidades.

¿Para qué lo podemos usar?

Lo primero, para tener todos los bloques de nuestra aplicación de Internet separados y bien diferenciados, lo que nos ayudará a crecer más rápidamente y como dijimos antes, la escalabilidad será algo natural.

Aunque ahora me voy a centrar un poco más en FaaS. Es decir, lo que haremos con este tipo de servicio es simplemente la ejecución de código. Una función, por ejemplo hecha en Python que tiene que ejecutarse en alguna ocasión. ¿Cuándo? Generalmente estas funciones se ejecutarán cuando se dispare un evento del tipo: petición web, entrada de datos en base de datos, inserción de mensaje en un log, creación de una notificación, entrada de un usuario determinado, nuevos archivos en servidores de almacenamiento y mucho más.

Normalmente nuestra aplicación tendrá un servidor web de entrada, que sí lo gestionamos nosotros (ese es nuestro VPS, o nuestros servidores balanceados), pero ahí vamos a incluir el código más básico posible: generación de páginas a partir de las plantillas, obtención sencilla de datos, control de sesiones, y poco más.

Por ejemplo, si tenemos en base de datos toda la información de ventas anual y queremos crear una gráfica resumen con todo y algunos datos estadísticos, seguramente si hemos vendido mucho debemos hacer cientos de cálculos y podemos encargárselos a otro liberando algo de carga en nuestro servidor, aunque el la entrada/salida de nuestra base de datos va a tener impacto igual, pero los cálculos y el trabajo de memoria y CPU para extraer medias, periodos, tendencias y demás se lo lleva otro. Todo esto lo podemos extender a todas aquellas tareas que sean un poco más pesadas de la cuenta. A lo mejor no tardan mucho tiempo, pero involucran sobre todo CPU y memoria y puede perjudicar el rendimiento global de nuestra aplicación. Estas tareas pueden ser: grandes importaciones/exportaciones de datos, generación de imágenes o miniaturas, generación de vídeos, etc.

En el lado del programador

El número de lenguajes es limitado y lo pone el proveedor del servicio. Contamos con lenguajes más o menos famosos y útiles como Python o NodeJs, en algunos sistemas podremos ejecutar Java o C#. Es normal que todos los lenguajes no estén soportados, porque hay que preparar los entornos de ejecución para que sea seguro utilizarlos y, supongo que con el tiempo se podrá ampliar el número de lenguajes soportados. Esto también puede causar dependencias, ya que puede que un proveedor soporte un lenguaje y otro no.

Por el lado de los desarrolladores, tenemos que contar con herramientas que nos permitan desarrollar el código de estos servicios de forma sencilla. Como la forma más común y sencilla de disparar los eventos es con peticiones HTTP. Actualmente hay sistemas que nos permiten crear un pequeño servidor local que atiende estos tipos de peticiones y ejecuta el código seleccionado. Luego, cuando pasemos el código a nuestro servidor sólo tendremos que cambiar el punto de acceso al servicio (que no será local, será el que nos dé nuestro proveedor). Y todo porque desarrollar desplegando todo el rato es muy feo.

Es conveniente también automatizar los despliegues. Y tenemos herramientas para ello, pero dependen del proveedor que cojamos. Sólo tendremos que crear un script o un archivo de instrucciones de despliegue y ya podremos usarlo para desplegar. Lo bueno es que esta tecnología nos permite crear tantos eventos como queramos, y tenemos la posibilidad de tener varios entornos, testing y producción por ejemplo, y sólo tenemos que cambiar el punto de entrada.

Tenemos que tener en cuenta que las funciones que ejecutamos deben estar lo más optimizadas posible, porque nos cobrarán por tiempo de ejecución, por lo tanto, las funciones deben estar bien definidas, tener un único objetivo y evitar entrar en bucles infinitos o esperas innecesarias. Eso sí, estas funciones podrán disparar eventos que ejecuten otras funciones en el futuro, así que tendremos que tener un poco de cuidado para que nuestras funciones no se pisen las unas a las otras…

Resumiendo

Para no agobiarnos mucho, con esta tecnología, definiremos una serie de eventos que, cuando se disparen, ejecutarán un fragmento de código en un ambiente de ejecución o contenedor controlado. Este código se ejecutará y el contenedor se destruirá. Si la función tiene que ejecutarse muchas veces, incluso simultáneamente, el proveedor se encarga del escalado/encolado/etc.

Estas funciones pueden conectar con otros servicios de base de datos, almacenamiento u otros tipos de servidores, incluso disparar la ejecución de otras funciones.

En próximos posts voy a contaros mi experiencia trabajando con Amazon Lambda

Referencias

No te pierdas estos sitios con interesantes lecturas sobre arquitectura Serverless:

• ¿Qué es eso de serverless? – Medium
• Serverless by Martin Fowler

También podría interesarte....