La tecnología os presenta día tras día nuevas maneras de hacer vuestro trabajo,hoy os venimos a decir que prescindáis de servidores para programar: FcS ¿sorprendido?
FcS: cómo trabajar con ellas y no morir en el intento
Parafraseando la famosa película española de 1991 comenzamos este artículo por este vuestro blog no sin antes presentaros un amplio panorama como introducción. Acompañaremos enlaces de artículo por acá 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 términos 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 hacia donde se dirige nuestra información.
En Pandora FMS tenemos bien puestos nuestros pies en la Tierra y nuestra flexibilidad da lo suficiente para otear en el horizonte con 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 ver 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 de 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 nos hemos esforzado en traeros toda novedad que es asimilada 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» y cuyo acrónimo FaaS nos recuerda inmediatamente el mencionar -solamente- otros términos importantes: «Software as a Service» SaaS (por ejemplo eHorus o incluso CRM en la nube) e «Infraestructure as a Service» IaaS (y faltan muchas más que englobaremos bajo 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 que alojamos con un proveedor y pueden ser llamados por nosotros, por otras aplicaciones o incluso eventos.
Acá 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, 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 han dado por llamarlas «serverless» lo cual 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?
Pues los usos pueden ser infinitos, prácticamente:
- Pudiéramos hacer una FcS que se ejecute cada hora, lea un fichero XML, extraiga únicamente los campos que necesitamos 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.
- 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 (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, que no son muchos, hay varias empresas gustosas de vendernos 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 os mencionamos, dada nuestra incursión en AWS®, en este artículo nos enfocaremos en las AWS Lambdas® (mirad 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 este 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 acá. 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: '*'
Si llevamos nuestro control de versiones de FcS en Github podemos contratar a la empresa SLAppForge Sigma otorgándole los debidos accesos para poder modificarlas e implementarlas directamente desde la página web de dicha empresa. Esto ahorra tiempo a los programadores y seguridad a las empresas (un programador no necesita tener credenciales en Github ni en AWS Lambda®, solamente identificarse y entrar en SLAppForge Sigma para hacer unicamente su labor de programar); también Amazon® ofrece CodeCommit® («gratis«).
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: solo 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). Por una espacio de una hora Amazon® mantendrá en caché nuestras credenciales de autenticación, así que bien pudiéramos realizar una FcS que a su vez liste nuestras FcS cada 62-65 minutos y nuestro clientes tendrán mejor acceso a nuestra plataforma contratada (pequeño hackeo de nuestra parte). 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 al 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 practicar en un entorno de pruebas local, nuestro propio emulador de Amazon Lambda® (métricas incluídas), podremos utilizar «Serveless Offline Plugin» (solo para Node.JS) y visualizar dichos «awslogs» para humanos (acá un ejemplo sobre cómo Amazon Cloud Watch devuelve una métrica lo podéis ver acá en lenguaje de máquina).
Monitorización de terceros a nuestras FcS
Amazon® decidió delegar este trabajo a terceros que se convirtieron en aliados de negocios (¿Pandora FMS también podrá allanar este camino?). Uno de ellos es Dashbird el cual es un pago adicional para nosotros a esa empresa y que además debemos autorizarlos con una política de acceso y una credencial de identificación para que ellos tomen las métricas de manera directa en Amazon® por nosotros y nos presenten la información. Ejemplo de política de acceso que deberemos guardar como «dashbird-policy» es la siguiente (descripción sugerida «Allow Dashbird to read CloudWatch logs«):
{
"Version": "2018-04-15",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:FilterLogEvents",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "logs:describeLogStreams",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "lambda:listFunctions",
"Resource": "*"
}
]
}
También deberemos crear un nuevo rol para Dashbird y asociarlo con la política anterior.
¿Quiere ir más allá en la monitorización de las FcS de Amazon®?
Amazon® ofrece el servicio AWS X-Ray® el cual 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 al cual podemos programar comandos específico 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. Acá un ejemplo de las librerías a las que debemos llamar en Java:
import com.amazonaws.xray.javax.servlet.AWSXRayServletFilter
¿Fácil, verdad? Hubiéramos comenzado por allí desde un principio pero ¿acaso no disfrutamos del «hackear» el sistema de funcionamiento de esta novedosa FcS llamada AWS Lambda®?
Dejad vuestros comentarios e impresiones, acá abajo, queremos saber vuestras dudas y haremos lo posible por responderlas en la medida de lo posible, ¡hasta una próxima oportunidad, nos «leemos»!🤓