Nube y Virtualizacion Tecnología Tutorial

¿Cómo monitorizar una arquitectura sin servidor?

agosto 3, 2018

¿Cómo monitorizar una arquitectura sin servidor?

El post está disponible también en : Inglés

Arquitectura sin servidor: una introducción y nuevos retos para la monitorización

Cuando hablamos de la computación en la nube, podemos encontrar la tecnología de Arquitectura sin servidor, y su creciente popularidad en los últimos tres años.

En principio, el concepto de computación en la nube cubre tres niveles de servicio:

  • IaaS (Infrastructure as a Service), que permite el acceso a una infraestructura informática virtualizada que incluye elementos tales como servidores virtuales, balanceadores de carga, conexiones de red, etc.
  • PaaS (Platform as a Service), que permite acceder a un entorno para el desarrollo e implementación de servicios y aplicaciones habilitados para la nube.
  • SaaS (Software as a Service), que permite el acceso a aplicaciones en la nube, sin necesidad de realizar ninguna instalación de software.

La parte ” sin servidor ” se entiende al principio como la posibilidad de que los desarrolladores de software accedan a un servicio en la nube que les permita crear aplicaciones sin tener que configurar y administrar los servidores en los que se ejecutarán esas aplicaciones.

Expresado de esta manera, la arquitectura sin servidor se refiere a los servicios llamados BaaS (Backend as a Service) en los que los procesos como la autenticación, el acceso a la base de datos o la mensajería se suministran a través de servidores físicos o virtuales ubicados en la nube.

Sin embargo, hay algunas diferencias entre BaaS y la arquitectura sin servidor

Con BaaS, en realidad, tenemos un servidor en la nube que escucha la solicitud HTTP o llamadas API , ejecuta varias acciones y proporciona el servicio contratado.

La Arquitectura sin servidor implementa el paradigma de programación orientado a eventos según la cual el flujo del programa es determinado por la aparición de un evento en particular como un clic del ratón o el mensaje de otro programa.

Los proveedores de la arquitectura sin servidor definen los lenguajes de programación soportados y los desarrolladores escriben el código de un programa considerando un único punto de entrada y la ejecución de una única función.

Cuando se denomina al programa generalmente llamado con el nombre genérico de ” función “, ocurre lo siguiente:

  • El entorno de ejecución se crea,
  • La función se ejecuta y
  • Cuando la función finaliza, el entorno desaparece.

La escala es lineal; si la función se llama n número de veces, el entorno de ejecución, en principio, se creará y eliminará el mismo número de veces.

Los usuarios no pagan por un programa residente que escuche (como en BaaS) sino por el número de ejecuciones y consumo de recursos (memoria x tiempo de ejecución total).

Para ser rentables, las funciones deben ser pequeñas, estar bien orientadas a un propósito y ser eficientes. Es por eso que regularmente encontramos funciones relacionadas con microservicios.

En literatura especializada, podemos encontrar la definición de FaaS (Function as a Service) para describir este tipo de servicio. Este concepto podría ser útil para establecer una diferencia con PaaS.

Finalmente, podemos definir la Arquitectura sin servidor como una arquitectura donde tenemos un entorno de ejecución basado en la nube que se crea para hacer una función y es eliminado cuando finaliza la ejecución.

Hoy en día hay varios proveedores de este tipo de servicios; podemos mencionar Amazon con AWS Lambda, Microsoft con Azure Functions, Google con Google Cloud Functions e IBM con OpenWhisk.

Para aquellos lectores interesados en saber más sobre la arquitectura sin servidor, recomendamos este artículo de Martin Fowler , donde el concepto se explica de una manera más detallada.

Ahora, el impacto real de la arquitectura sin servidor está por definirse. Sin embargo, incluso si encontramos aplicaciones completas desarrolladas bajo este enfoque o si todo se queda en el desarrollo de micro servicios que pueden ser llamados utilidades, la arquitectura sin servidor representa un paradigma digno de análisis desde el punto de vista de la monitorización.

La arquitectura sin servidor es un nuevo capítulo de una novela que comenzó cuando empezamos a preguntarnos: ¿cómo vamos a controlar nuestras plataformas y aplicaciones si contratamos un servicio en la nube?

En 2016, en este mismo blog, se publicó un artículo titulado Cloud Monitoring: ¿Qué debes saber sobre la monitorización en la nube? , donde había una introducción a este tema y los principales retos que trae consigo.

Deberíamos tener en cuenta las advertencias de este artículo acerca de cómo delegar la supervisión de los proveedores de servicios en la nube y las limitaciones de las herramientas de supervisión que suministran.

Teniendo esto en cuenta, veamos qué desafíos adicionales representa una arquitectura sin servidor. Las preguntas fundamentales son estas:

      ¿Cómo monitorizar una aplicación si nuestro servidor de back-end no existe?
      ¿Cómo monitorizar una plataforma si tenemos servidores tan efímeros que sólo existen cuando se llama a una función?

Como el servidor no existe, no tenemos la opción de usar un agente para recopilar datos.

Por lo tanto, podemos utilizar las herramientas de monitorización suministradas por el proveedor , por ejemplo AWS CloudWatch, donde podemos encontrar las métricas asociadas con nuestras funciones lambda.

Las métricas como el número de llamadas , los errores y el tiempo de ejecución nos brindan una visión general de nuestras funciones, pero podrían ser insuficientes para monitorizar una aplicación compleja o una sola función con varias conexiones externas a las API o bases de datos .

Necesitamos una forma de recopilar y acceder a la información de registro generada por nuestras funciones para determinar métricas importantes como latencia, recursos, edad , fallas, etc. y luego tenemos que ser capaces de correlacionar estas métricas con la observabilidad general de nuestra aplicación .

Una opción podría ser introducir en el código de la función las llamadas a otra función para recopilar los datos necesarios. Pensemos, por ejemplo, que en el código de la función A llamamos a otra función B diseñada para recopilar datos. De esta forma, podemos usar una herramienta de registro para interpretar y presentar la información de una manera coherente. En este artículo puedes encontrar un buen ejemplo de esta opción.

Para esta opción, dos elementos son preocupantes: ¿qué pasa si nuestra función se llama miles de veces en un corto periodo de tiempo y tenemos que pagar por la función original y por la función de registro?). El otro punto es la contextualización (¿podemos realmente correlacionar app – evento – función – rendimiento, por ejemplo?

Una segunda opción se basaría en el hecho de que, por ejemplo, toda la información de registro en funciones lambda va a AWS CloudWatch, por lo que en esta opción necesitaríamos una herramienta para interactuar con CloudWatch y ayudarnos a controlar registros, fallos, excepciones y uso de recursos. etc. Un buen ejemplo de esas herramientas es Dashbird .

La pregunta es: ¿pueden esas herramientas hacer el mismo servicio con otro proveedor?

Finalmente, tenemos que decir, más allá de las dos opciones mencionadas anteriormente; la monitorización de las funciones sin servidor genera serias dudas sobre la observabilidad de nuestras aplicaciones y plataformas.

La solución ideal podría ser extender el uso de nuestra herramienta de monitorización habitual a cualquier tipo de computación en la nube que decidamos contratar para mantener un procedimiento de monitorización unificado .

Toda la experiencia que podemos obtener con esas herramientas de monitorización y el profundo conocimiento de nuestra plataforma y aplicaciones seguramente puedan marcar la diferencia. Invitamos a nuestros lectores a conocer más sobre la monitorización unificada de Pandora FMS en este enlace.


    Written by:



    Leave a comment

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.