Funciones como Servicio. FcS: su monitorización y uso como herramientas

FcS. Funciones como Servicio: su monitorización y uso como herramientas

¿Qué tal si empezamos por una introducción? Acompañaremos enlaces de artículos ya publicados -y de terceros- que amplían cada concepto o tema a fin de mantener lo más compacto posible nuestro viaje.

Desde hace al menos cinco años se escuchan frases como “la nube, hay que subirlo todo a la nube“, lo cual es una estrategia de ventas muy artera: al decir “nube” nuestra mente se eleva automáticamente, se va hasta más allá de este planeta, y podríamos perder de vista nuestros datos (y en nuestro caso, nuestras aplicaciones también), por lo que debemos tener sumo cuidado de hacia dónde se dirige nuestra información.

En Pandora FMS tenemos bien puestos nuestros pies en la Tierra y nuestra flexibilidad da lo suficiente como para otear en el horizonte las nubes existentes (y también las que están por venir). Por ello, os hemos hablado de los conceptos básicos sobre la nube -si se quiere, con poco optimismo- y reafirmamos aquí lo allá planteado:

«Ten en cuenta siempre el objetivo de negocio por encima de las consideraciones y supuestas ventajas técnicas. La nube es un herramienta más».

Incluso hemos publicado que hay que mirar con recelo a la nube: son muchas las preguntas que debemos hacernos antes de migrar algunos de nuestros procesos. Ciertamente hay casos de éxito bien documentados y hasta hemos aterrizado en “Amazon Web Services” AWS® para sacar partido de las cosas buenas, ofreciendo una imagen de la versión Open Source de Pandora FMS (eso sí, os indicamos claramente cómo aprovechar nuestro protocolo Tentacle y poder monitorizar otras máquinas virtuales a fin de centralizar la información de los registros o “logs”).

No nos hemos quedado atrás a la hora de monitorizar entornos virtuales como Docker Swarm (que están en la nube), debido al desafío que presentan sus métricas. Como podéis ver, nuestro equipo colectivo en este vuestro blog se ha esforzado en traeros todas las novedades que son asimiladas por la increíble flexibilidad de Pandora FMS.

En esta entrada haremos un enfoque, tal como lo hizo uno de nuestros colegas, y lo aplicaremos a las Funciones como Servicio, las cuales abreviamos como FcS. Esto proviene del idioma inglés, “Function as a Service”, cuyo acrónimo FaaS nos evoca a mencionar otros términos importantes: “Software as a Service” o SaaS (por ejemplo eHorus o incluso CRM en la nube) e “Infraestructure as a Service” o IaaS (y faltan muchos más que englobaremos bajo el término YaaaS: “Yet another as a Service”).

¿Qué son las FcS?

Las FcS son los programas cortos (funciones) que hagamos con determinado lenguaje de programación, son monolíticos y los alojamos con un proveedor y pueden ser llamados por nosotros, por otras aplicaciones o incluso eventos.

Aquí la clara ventaja es que nosotros como programadores podemos olvidarnos de servidores, sus actualizaciones, conexiones SSH, etcétera, a tal punto de que olvidaremos que estamos en un servidor y nos dedicaremos a realizar la FcS sin mayor contratiempo (¿Será éste el fin de los DevOps tal como los conocemos?). Es por ello que, en inglés, a dichas funciones las llaman “serverless“, lo que consideramos que no es cierto: el servidor siempre estará allí. Que no nos importe dónde esté y cómo está configurado, mantenido y monitorizado no implica que la figura no exista.

En resumen, las FcS son programas que se cargan, ejecutan y al finalizar todos sus datos son destruidos y solamente nos cobrarán por el tiempo en ejecución.

¿Cuáles son los usos de las FcS?

Los usos pueden ser prácticamente infinitos:

• Pudiéramos hacer una FcS que se ejecute cada hora, lea un fichero XML, extraiga únicamente los campos que necesitemos y los almacene en una base de datos (incluso que nos diga si hay campos nuevos en el documento, ya que esa es una versatilidad del XML: agregar datos sin afectar la compatibilidad en la lectura).
• Un FcS pudiera consultar varias RSS, unirlas y realizar un documento HTML que se guarde en un teléfono móvil para ser consultado fuera de línea.
• Otra FcS bien pudiera conectarse a una base de datos y consultar el número de unidades vendidas de un artículo específico y/o su existencia, disponibilidad y precio.
• También podremos redimensionar imágenes de manera masiva; verificar el pago y saldo en máquinas dispensadoras de gaseosas; conectar nuestras aspiradoras a nuestra red WIFI (IoT, o Internet de las cosas), notificaciones por Slack o bien pudiéramos consultar el precio de unas determinadas acciones en cualquier bolsa de valores del mundo.

¿Como podemos monitorizar las FcS?

Pandora FMS puede, de manera indirecta, lidiar los procesos de negocio mediante la Monitorización Transaccional, por lo que los resultados de nuestras FcS sobre una base de datos, y con el agente Pandora FMS adecuado a esa base de datos, obtendremos el mismo fin: cuidar de que nuestros procesos, clientes y empresas estén operativos y produciendo. Este artículo trata sobre implementar agentes de manera directa sobre nuestras FcS, sin perder de vista el escenario completo.

¿Quiénes alojan FcS?

A la fecha, no siendo muchas, hay varias empresas que venden tiempo de máquinas:

• IBM® con su “OpenWhisk actions®”.
• Microsoft® con sus “Azure Functions®”.
• Google® con sus “Cloud Functions” (aún en fase beta).
• Amazon® con sus “AWS Lambdas®”.

Como mencionamos, dada nuestra incursión en AWS®, en este artículo nos enfocaremos en las AWS Lambdas® (podéis mirar las preguntas frecuentes en este enlace) por ser un producto maduro y que muchas empresas de hecho ya utilizan.

AWS Lambdas®

De manera acertada, Amazon® denomina a las FcS como “Lambdas”, por ser éste el concepto que engloba a las mínimas y recursivas funciones de un lenguaje de programación. Sin embargo, no os dejéis “engañar”: el cálculo lambda es complejo y aquí lo simplificaremos al máximo.

Características de las AWS Lambdas®

• Cada función AWS Lambda® tiene sus límites: 50 megabytes de manera comprimida, 512 megabytes en su propia carpeta temporal en disco y para cada instancia, mínimo 128 megabytes de memoria hasta 3 gigabytes (potencia de CPU es proporcional a la memoria contratada), el tiempo de ejecución máximo es de 300 segundos.
• Podemos programar para Java, JavaScript (Node.JS), PHP, Ruby, Python y .NET® .
• Nota importante: sucesivas versiones de una FcS serán mantenidas tanto tiempo como queramos y podemos llamarlas específicamente una a una (máximo de mil al mismo tiempo).
• Amazon® factura por bloques de 100 milisegundos, sin embargo los planes de precios son calculados en segundos y el primer millón de solicitudes es gratuito. Estas solicitudes (tiempo utilizado) se multiplican por la memoria contratada. En la práctica, a la larga, el plan de 1024 MB sale más económico, pues por tener mayor poder de cálculo ocupa menos tiempo.

Definiendo una AWS Lambda®

Debemos, en formato JSON o YAML, realizar una definición formal ante Amazon® de nuestra futura FcS: nombre, versión, dependencias, memoria a utilizar, etcétera; todos los detalles los encontraremos aquí. Por ejemplo, una función en Node.js para hacer una solicitud HTTPS en YAML (según AWS SAM®), sería la siguiente:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: Demonstrates using a built-in Node.js module to make an HTTPS request.
Resources:
httpsrequest:
Type: 'AWS::Serverless::Function'
Properties:
Handler: index.handler
Runtime: nodejs4.3
CodeUri: .
Description: Demonstrates using a built-in Node.js module to make an HTTPS request.
MemorySize: 128
Timeout: 60https://aws.amazon.com/es/java/?nc2=h_l2_d
Policies:https://aws.amazon.com/es/java/?nc2=h_l2_d
- Version: '2018-04-15'
Statement:
- Effect: Allow
Action:
- 'ses:SendBounce'
Resource: '*'

Invocando una AWS Lambda®

Una vez tengamos nuestra FcS lista y alojada, la podemos invocar vía API por medio de autenticación de token: sólo de ser positiva la identificación es llamada la FcS y de ser negativo devuelve un código 303 (esto protege nuestros bolsillos de ataques de lanzamientos indiscriminados). Son muchos los productos de Amazon® que pueden invocar nuestras FcS, previamente autorizados por nosotros, pero en particular nos interesa el que podemos invocar bajo demanda.

Amazon Cloud Watch®

Si bien ya nuestros guiones están en la capacidad de recolectar métricas acerca de la ejecución o no al recibir respuesta bajo demanda (por ejemplo error 303 para no autorizado y 404 para no encontrado), internamente Amazon nos ofrece ciertas métricas básicas mediante Amazon Cloud Watch®, las cuales son las siguientes (las respuestas exitosas que devuelven valor cero no son registradas por Amazon Cloud Watch®):

• Invocations
• Errors (valores de respuesta 4XX)
• Dead Letter Error
• Duration (en milisegundos pero facturan en bloques de 100 milisegundos)
• Throttles (importante error 429 número de instancias abiertas simultáneamente, muchas solicitudes al mismo tiempo)
• IteratorAge
• ConcurrentExecutions
• UnreservedConcurrentExecutions

Si nuestra FcS está escrita en Python podremos, además, agregar nuestras propias métricas, bien podemos incluir las respuestas exitosas:

import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def my_logging_handler(event, context):
logger.info('got event{}'.format(event))
logger.error('Algo va mal.')
return 'Nuestras propias métricas.'

En vez de “logging.INFO” podremos cambiar el tipo de de métrica. Otro punto a destacar es que ¡cualquier “print” también será guardado como métrica!

from __future__ import print_function
def lambda_handler(event, context):
print('Esto también se guardará en Cloud Watch')
return 'Nuestras propias métricas.'

Por la consola de Amazon CloudWacth® podremos ver los registros de una función específica, ejecutando el siguiente comando (ver límites de consultas sin costo adicional):

serverless logs -f mi-funcion-FcS

Emulador de AWS CloudWatch® y sus métricas

Si lo que queremos es practicar en un entorno de pruebas local nuestro propio emulador de Amazon Lambda® (métricas incluídas), podremos utilizar “Serveless Offline Plugin” (sólo para Node.JS) y visualizar dichos “awslogs” para humanos (aquí un ejemplo sobre cómo Amazon Cloud Watch devuelve una métrica. Lo podéis ver aquí en lenguaje de máquina).

¿Quiere ir más allá en la monitorización de las FcS de Amazon®?

Amazon® ofrece el servicio AWS X-Ray®, que es gratuito para los primeros cien mil rastreos y el primer millón de rastreos recuperados; a partir de esos valores comienza el cobro. Esencialmente, es una plataforma de depuración a la cual podemos programar comandos específicos dentro de nuestro código de función, con la certeza de que dichos datos explícitos serán guardados y de ser necesarios recuperados por nosotros para su análisis. Aquí, un ejemplo de las librerías a las que debemos llamar en Java:

import com.amazonaws.xray.javax.servlet.AWSXRayServletFilter

Dejad vuestros comentarios e impresiones, aquí abajo. Queremos conocer vuestras dudas y haremos lo necesario por responderlas en la medida de lo posible, ¡Hasta una próxima oportunidad, nos “leemos”!