Un Vistazo a Funciones como Servicio

En el contexto de programación, una “función” típicamente se refiere a un conjunto de líneas de código que realizan una tarea específica, y puede o no recibir parámetros al igual que retornar un valor. Con la era del cómputo en la nube, ya casi todo se puede ofrecer como servicio, desde la virtualización de servidores hasta la ejecución de funciones individuales bajo demanda, mejor conocido como “Funciones como Servicio”, (FaaS, por sus siglas en inglés).

El modelo FaaS ofrece ejecución de cómputo bajo demanda por fragmentos de código. Es parte de la tendencia “serverless”, que implica pensar menos en la infraestructura y poner más foco en la lógica del negocio. Entre sus ventajas están la escalabilidad automática, costo por ejecución y abstracción de la infraestructura.

Lo importante es que nuestras “funciones” se ejecuten de manera confiable y con alto desempeño, sin tener que preocuparnos por la infraestructura que hay debajo. Nosotros escribimos código que realice una determinada tarea usando el lenguaje de programación de nuestra preferencia, y estas funciones se ejecutan bajo demanda desde la infraestructura en la nube del proveedor que elijamos. Las funciones reaccionan a eventos dentro y fuera de la nube, por lo que las hace muy interesantes y poderosas.

¿Cómo escribo una función como servicio?

Al construir cualquier componente de software, típicamente debemos tener en cuenta distintos aspectos tales como: hardware, sistema operativo, lenguaje de programación, ambiente de desarrollo (IDE), bibliotecas, compilador o interprete, entre otros. Pero al construir una función como servicio, solamente nos enfocamos en el comportamiento que buscamos que tenga nuestra función y el lenguaje de programación que usaremos. Es decir, escogemos un lenguaje de programación, escribimos nuestro código y empezamos a trabajarlo desde una interfaz web con el navegador de nuestra preferencia. Todo lo demás es provisto y automatizado, la infraestructura se ofrece a través de centros de datos cuya ubicación posiblemente ni siquiera sepamos.

Una vez programadas, las funciones se exponen como un hipervínculo con el protocolo HTTP. Dicho hipervínculo se puede invocar a través de cualquier navegador web u otro cliente, que regresa una respuesta en formato JSON. Es común comparar FaaS con web services, pero FaaS es un esquema más sencillo y desacoplado, que a su vez lo hace más poderoso.

Costo de ejecución

Aunque puede haber variaciones en ciertos detalles, en general el modelo de costos es similar a través de los distintos proveedores que ofrecen FaaS. Básicamente, se cobra en base al número de veces que la función es ejecutada, el tiempo de ejecución que toma (medido en milisegundos) y la cantidad de memoria que consume.

Estructura

Los 3 principales componentes de una Función como Servicio son:

• Function Code: Tal cual como su nombre lo indica, es el código que nosotros escribimos dentro de la función con un fin específico.

• Binding: Se refiere a los datos de entrada o salida.

  • Input: Parámetros que podrá recibir la función para empezar a trabajar.

  • Output: Valor de retorno de la función.

• Trigger: El elemento que desencadenará la ejecución de la función, una palabra más habitual seria evento.

Un trigger define cómo se invoca la función, incluyendo el tipo de datos que procesará, por lo que esta característica está estrechamente relacionada con el costo de cómputo procesado.

Dependiendo el proveedor de tecnología encontraremos una arquitectura diferente de otra, sin embargo, conservan principios similares como el acoplamiento de capas con un RunTime para soportar más de un lenguaje de programación. La figura 1 muestra la arquitectura de Azure Functions diseñada en la nube de Microsoft Azure.

​

Figura 1. Arquitectura de Azure Functions.

Ya dentro de nuestro editor funciones como servicio nos encontramos la siguiente estructura:

• Run file: Es el archivo que contiene el código que escribimos.

• Function file: Es el archivo que contiene la configuración de los building, triggers y parámetros, todo en formato JSON.

• Project file: Es el archivo que contiene las referencias a los ensamblados que necesitemos para el código de nuestra función.

Conclusión

Las funciones como servicio buscan mejorar la eficiencia y disminuir el acoplamiento de nuestras aplicaciones, ya que no están casadas con lenguajes de programación ni entornos de desarrollo integrado, y además respaldadas por una infraestructura de centros de datos a través de todo el mundo. Lo único que necesitamos es escribirlas y exponerlas públicamente.

Para empezar a trabajar con funciones como servicio te invito a que visites  http://bit.ly/2ByrvYq y veas paso por paso lo fácil que es crear una función como servicio con Azure Functions.