En 2018 era una de las tendencias a seguir de cerca y este año comienza a irrumpir tímidamente en las grandes empresas. Pero, ¿Qué es FaaS? ¿Viene a sustituir a los microservicios ahora que el mercado apuesta claramente por ellos?
En el presente artículo se pretende realizar una breve introducción a este concepto, así como destacar las ventajas y desventajas que presenta.
¿Que es FaaS?
FaaS, también conocido como Functions as a Service, es un modelo de arquitectura cloud que permite al desarrollador ejecutar pequeños fragmentos de códigos o funciones stateless, durante un determinado periodo de tiempo, sin necesidad de aprovisionar ni administrar servidores.
Es el proveedor de la nube (AWS, Azure, Google) quien se encarga de la gestión del entono de ejecución y únicamente se factura por el tiempo en el que el código está siendo ejecutado.
¿Como funciona?
El código se despliega en la plataforma cloud deseada y se configura para ser invocado en base a eventos. Se entiende por evento desde una petición HTTP hasta acciones de otros servicios de la nube, como por ejemplo, almacenar un fichero en un S3 o registrar una determinada traza en CloudWatch. (Ambos servicios de AWS)
Una vez registrado el evento, el proveedor cloud crea un contenedor con el entorno de ejecución adecuado para el lenguaje de programación empleado y ejecuta la función desplegada.
Este contenedor será reutilizado en posteriores ejecuciones, siempre y cuando no supere los 5 minutos de inactividad, dato que puede variar en función del proveedor y el estado de la infraestructura. En caso de superar dicho umbral, el contenedor será destruido.
Finalmente, es importante señalar que las peticiones entrantes no se encolan, es decir, en caso de llegar 3 peticiones simultáneas, se crearán 3 instancias de la función y se ejecutarán en paralelo.
¿Que ventajas aporta?
Serverless
La principal ventaja reside en su arquitectura serverless que permite despreocuparse por completo de la gestión de los servidores, para centrar todos los esfuerzos en lo que realmente importa, qué es la lógica de negocio.
Es el proveedor proveedor cloud pertinente quien se encarga tanto del aprovisionamiento, administración y mantenimiento del entorno de ejecución, así como del escalado, la alta disponibilidad, la centralización de los logs, el tracing distribuido o la monitorización.
En la siguiente imagen se puede observar como este modelo no es más que la evolución lógica a la que tiende el mercado tras la irrupción de la nube.
Se pasó de un modelo on premise, en el que el desarrollador debía encargase desde la lógica de negocio de la aplicación hasta la administración completa del servidor, pasando por los modelos IassS y PaaS, en los que la parte de infraestructura pasaba a ser paulatinamente responsabilidad del proveedor de la nube, hasta llegar a un modelo FaaS, en el que la única preocupación del desarrollador es la lógica de negocio.
Pago por uso
Una de las características más destacadas es únicamente se factura por el tiempo en el que la función se esté ejecutando, al contrario que en un IaaS o un PaaS, en el que hay que pagar por el mero hecho de tener el código desplegado.
Dicho de otro modo, la facturación se ajusta al uso real que se hace de la infraestructura.
Escalabilidad
El escalado es otro de los apartados que sale muy favorecido de este modelo de arquitectura.
Por un lado, está el hecho de que es el proveedor cloud quien se encarga levantar nuevas instancias en función de la carga de trabajo, por lo que lo que la limitación a nivel de hardware deja de ser un problema (Existen limitaciones a nivel de software, pero varían en función del proveedor).
Es decir, en caso de llegar 1000 peticiones de forma concurrente se crearán mil instancias de la función para dar respuesta a la demanda, de ahí a la necesidad comentada anteriormente de que el código desarrollado sea stateless.
Por otro lado, el escalado se realiza a grano fino, o lo que es lo mismo, en lugar de escalar una aplicación o un microservicio, se escala una función. Esto permite reducir costes ya que únicamente se paga por los recursos utilizados.
Time to market
La reducción del time to market es otra de claras ventajas que presenta este modelo.
El hecho de desarrollar pequeñas piezas de código desacopladas, no necesariamente escritas en el mismo lenguaje de programación, unido a los despliegues automatizados, reduce significativamente el tiempo que lleva desarrollar una nueva funcionalidad en comparación con las tradicionales aplicaciones monolíticas o microservicios.
Lo mismo ocurre con el mantenimiento y evolutivos, ya que siempre es más sencillo desarrollar sobre pequeños fragmentos de código acotados.
¿Que desventajas presenta?
Cold start
No iban a ser todas buenas noticias y el cold start entra en escena como la principal desventaja a tener en cuenta, especialmente si se pretenden desarrollar soluciones en tiempo real o con un bajo tiempo de respuesta.
Al inicio del artículo se comenta el hecho de que, cada vez se dispara un evento, el proveedor cloud se encarga de crear un contenedor con el entorno de ejecución adecuado, inyectar el código fuente y ejecutar la función. Una vez ejecutada, el contenedor se mantiene vivo para su reutilización en sucesivas peticiones, siempre y cuando no supere los 5 minutos de inactividad.
Dicho esto, se denomina cold start al tiempo que requiere el proveedor cloud para descargar el código fuente, configurar el contenedor e inicializar la aplicación para poder ejecutar la función.
Este lapso de tiempo varía significativamente en función de lenguaje de programación y la memoria asignada para su ejecución.
Como se puede observar en la comparativa adjuntada, lenguajes como Java o .NET tienen un cold start desmedido independientemente de la memoria asignada, especialmente si se pretenden ejecutar peticiones síncronas. Python, Go o Node Js por el contrario podrían llegar a aguantar el tipo con los recursos adecuados.
A estas alturas alguno podría pensar que tampoco es para tanto, al fin y al cabo, lo procesos asíncronos pueden asumir eso tiempo y los síncronos tan solo lo padecen la primera vez que se crea el contenedor, ¿no?
Es cierto que, en general, los procesos asíncronos pueden asumir ese tiempo. Ahora bien, tal y como comentábamos al principio del artículo, las peticiones entrantes en una arquitectura FaaS no se encolan y en caso de llegar 3 peticiones simultaneas se crearán 3 contenedores para dar respuesta a la demanda, con el consecuente cold start en cada una de ellas.
En la siguiente imagen se puede observar precisamente esto; El resultados de ejecutar 100 peticiones sobre una función, con una concurrencia de 10.
Backpresure
Anteriormente comentaba que uno de las grandes ventajas de una arquitectura FaaS era su capacidad prácticamente “ilimitada” de escalado, si bien esto puede provocar que hagan acto de presencia otros problemas en el modelo de solución.
El primer actor a observar es la base de datos. Generalmente la clásica base de datos relacional soporta un limitado número de conexiones abiertas de manera simultánea, de ahí al uso de los pools para su reutilización. Pero en un modelo FaaS esta solución deja de tener cabida, debido a que se crean tantas instancias como peticiones simultáneas se produzcan, con su correspondiente pool y conexión a la base a datos.
Existen diversas alternativas para dar solución a esta casuística, como tratar de reaprovechar las conexiones a través de los hot-context, acceder a la bases de datos vía HTTP en aquellas que lo soporten (MongoDB, DynamoDB…), delegar la gestión de los datos en un microservicio, o pensar en BDs serverless como Aurora. Analizaremos este tema en profundidad en el siguiente artículo.
Pero la base de datos puede no ser la única afectada por el escalado. Si se disponen de dependencia con APIs de terceros como PayPal, Stripe o Twitter por ejemplo, puede ser un problema, ya que limitan el máximo número de peticiones por segundo.
Algo similar puede ocurrir en caso de tener dependencia con los sistemas legacy de la empresa. Su capacidad de escalado no es comparable con la de los microservicios o funciones y pueden acabar ahogados en situaciones de máxima carga.
Herramientas de desarrollo
Otro de los elementos a tener en cuenta es el bajo grado de madurez de las herramientas de desarrollo. No hay más que acceder a los repositorios GIT de aws-sam-cli, cloud-functions-emulator o azure-functions-core-tools, utilidades para desarrollar, testear y debuggear funciones en local, para comprobar que se encuentran aún en estado alpha o beta.
Es previsible que en los próximos meses evolucionen a una velocidad de vértigo, pero es conveniente tenerlo en cuenta si se va a comenzar a desarrollar ahora.
Conclusión
En conclusión, del mismo modo que la migración a un escenario de microservicios trajo consigo beneficios y nuevos retos, con el modelo FaaS ocurre algo similar.
Ahora bien, al igual que los microservicios, no son el remedio a todos los problemas, por lo que conviene analizar cuidadosamente el de uso para tratar de diseñar la mejor solución.
Aclaración
Aunque durante el artículo se vincula estrechamente la arquitectura FaaS con un modelo cloud, es necesario matizar que no es estrictamente necesario, ya que iniciativas como Knative o Fission permiten ejecutar funciones en entornos on premise.
Referencias
Se recomienda encarecidamente leer los siguientes artículos que han servido de base para el escrito:
Mikel's TechBlog 