CambioDigital-OL

0

Fuente abierta serverless: Fission, Fn, Kubeless y OpenWhisk

nube_publicaLa palabra “serverless” o ‘sin servidor’ está de moda y es seductora, porque los servidores son un poco fastidiosos. ¿Todos esos parches para esos agujeros de seguridad que se describen en un millón de palabras, en un millón de correos electrónicos en su bandeja de entrada? Si pudiera deshacerse de un servidor, podría olvidarse de esos parches. ¿Todos esos puertos en los firewalls que debe recordar para mantenerlos cerrados? Tampoco serán de su preocupación. El mundo sin servidores lo liberará. Al menos eso es lo que la palabra parece prometer.

El mundo sin servidores se ve relajado y lleno de tiempo para dedicarlo a su única misión verdadera: lo que su traje le diga. Pero no se deje engañar. Pagará por esta libertad de la preocupación, sacrificando su libertad para deambular o cambiar. Las plataformas sin servidor en las nubes de Amazon, Microsoft y Google entregan su magia a través de una interfaz patentada; y cada vez que descarga algunas de sus preocupaciones en sus brazos de espera, se vuelve adicto.

Los programadores odian los grilletes como éste y es por eso que varios de ellos intentan crear paquetes de código abierto que ofrezcan algunas -o incluso la mayoría de las características de las plataformas sin servidor basadas en la nube, pero en una pila de código que puede llevar a cualquier parte. Esto no solo hace que la depuración y las pruebas sean más fáciles, sino que le permite llevar todo su kit y kaboodle a otra nube con mejores precios, mejor latencia o cualquier otra cosa. Incluso puede llevarlo a ese armario con aire acondicionado como solía llamar a la sala de servidores.

Para manejar este floreciente mundo de frameworks sin servidor de código abierto, arranqué algunas máquinas y escribí alguna lógica simple. Todavía es demasiado pronto para llegar a conclusiones firmes porque a los proyectos les gusta decir que son “pre alfa”, pero hay muchas promesas para liberarnos del bloqueo.

Aquí presentamos un vistazo a los cuatro principales esfuerzos: Fission, Fn, Kubeless y OpenWhisk. Seguramente vendrán más próximamente.

Fission
Una solución de servidor de fuente abierta de Platform9, Fission teje contenedores que se ejecutan dentro de Kubernetes utilizando algunos contenedores estándar con cargadores dinámicos. Sus funciones se extraerán en el contenedor estándar apropiado y se cargarán para responder consultas de un servidor web que ya se encuentra dentro del contenedor.

Los entornos estándar incluyen los modelos dominantes (Node.js, Python y Go) así como algunas soluciones de la vieja escuela como PHP, .Net, Ruby e incluso Perl. Por supuesto, también puede lanzar el suyo con el idioma que desee, siempre que produzca un archivo binario que responda a una solicitud HTTP.

Es probable que Fission sea más útil para cualquiera que quiera saltar directamente al nivel de Kubernetes, con las opciones de escalado automático que proporciona el orquestador de contenedores. Fission corre dentro de los cúmulos de Kubernetes utilizando las herramientas estándar como Kubectl, Helm y Tiller.

Un rápido ejemplo de cinco líneas de utilización de la interfaz de línea de comandos de Fission para convertir una función simple en un contenedor en ejecución.

Un rápido ejemplo de cinco líneas de utilización de la interfaz de línea de comandos de Fission para convertir una función simple en un contenedor en ejecución.

Si no puede confiar en una llamada HTTP para invocar las funciones, Fission puede activarlas desde un Crontab o un mensaje desde una de las dos herramientas de cola admitidas (Azure Queue Storage o NATS Streaming). También hay una opción para definir “flujos de trabajo” en un archivo YAML que ejecutará múltiples tareas en secuencia.

El mayor servicio proporcionado por Fission es mantener el conjunto de contenedores estándar que cargan dinámicamente su código. Están esencialmente preconfigurados, lo que le ahorra la molestia de agregar el código necesario para que funcionen correctamente en el clúster.

Fn Project
El ingreso de Oracle al espacio sin servidor, Fn pega algunas plantillas, las rutinas de compilación estándar para los principales idiomas y algunos contenedores Docker estándar. Fn está un poco más centrado en Java que los demás, lo que no sorprende demasiado si consideramos que Oracle posee Java. Fn debería funcionar con la mayoría de las combinaciones de idiomas y crear rutinas, siempre que Docker esté en la base. Parte de la literatura de Oracle dice “Una dependencia: Docker”.

Una de las características más interesantes es un conjunto de contenedores que le permitirán ejecutar su código AWS Lambda en el stack local de Oracle en lugar del suyo. Las funciones básicas son relativamente fáciles de mapear usando estas envolturas, pero a menudo eso es solo una parte de la imagen. La mayoría de las personas usa Lambda como código de pegamento para otros servicios en la nube de Amazon. Estas envolturas solo le ayudan a traer el código Lambda, así que tendrá que encontrar alguna otra solución para el trabajo pesado realizado por las APIs de AWS. Los contenedores son geniales, pero su utilidad depende de cómo haya diseñado su arquitectura y de cuántos de los servicios de Amazon utilizan su código.

La interfaz de Fn, como todas estas herramientas, es toda una línea de comando. Escriba fn y luego agregue comandos para crear nuevas plantillas, y cree el código resultante o finalmente impleméntelo. Usted escribe que una función simple es un archivo separado, y luego fn lo agrupará con la plantilla correcta para que pueda ejecutarse en un contenedor Docker en algún lugar.

Las plantillas preconstruidas para Go, Java, Python, Ruby y Node.js se incluyen como kits de desarrollo Fn (FDK), pero no es necesario concentrarse en ellas. Todas le piden que cree una función que tome una cadena como parámetro y devuelva una cadena como resultado. No podría ser más simple.

Esta interfaz de usuario experimental en Fn muestra cómo se pueden vincular varias funciones diferentes en un flujo de trabajo

Esta interfaz de usuario experimental en Fn muestra cómo se pueden vincular varias funciones diferentes en un flujo de trabajo

Cuando implemente el código, Fn lo conectará a un activador HTTP que agrupa todos los parámetros y los alimenta a su función que se ejecuta en un contenedor Docker. Prácticamente todo lo demás queda abierto a sus sueños y diseños. Sí, Fn le está salvando de todos los dolores de cabeza de implementación, pero aún tiene que escribir todo ese código dentro de esa función.

Puede juguetear un poco con los mecanismos dentro de Fn. La información de mantenimiento se almacena en una base de datos básica (SQL3) utilizada para realizar un seguimiento de las rutas y otra información de despliegue, pero puede usar MySQL o Postgres fuera de la caja. También hay una opción configurable para la cola de mensajes que ayuda a las diferentes versiones de la coordinación Fn. Probablemente no los toque, pero la opción está ahí si quiere más.

Fn se siente muy ligero y simple, sin duda por diseño. Se necesitan unas pocas herramientas de compilación estándar y algunas plantillas Docker estándar, y las vincula para que sea más fácil escribir un poco de código y ver que se ejecute en uno de estos contenedores Docker.

Kubeless
Kubeless proviene de Bitnami, una de las compañías que nos ayuda a extraer toda la potencia de la nube con varios tipos diferentes de productos manuales. Como Fission, Kubeless está diseñado para llevar toda la diversión de serverless a los clústeres de Kubernetes. El nombre es una especie de broma, porque la tecnología no tiene nada que ver con Kubernetes. En todo caso, se trata de explotar las funciones incorporadas de Kubernetes para crear una infraestructura rápida sin servidores.

Kubeless convierte sus funciones en recursos personalizados, algo que Kubernetes está diseñado para crear y escalar según sea necesario. A los desarrolladores parece que les gusta más Python, aunque solo sea porque los ejemplos están escritos en gran parte en ellos, pero también existen tiempos de ejecución de Node.js, Ruby, PHP, Go y .Net. Aunque Java 1.8 no se encuentra en algunas partes de la documentación, está incluido en la lista de tiempos de ejecución disponibles, según la versión que instalé.

Las funciones básicas son un poco más sofisticadas que en otros frameworks. Cada función que escriba tomará dos parámetros, un objeto con el evento y otro con metadatos o contexto. Esto permite modelos de programación un poco más sofisticados y autoconscientes que los enfoques que simplemente pasan una cadena a la función. Al final, debe devolver una cadena que se devolverá a cualquier solicitud HTTP que haya comenzado a funcionar. (Hay algunas funciones de ayuda más agradables en algunas de las pilas, donde el tiempo de ejecución de Node.js acepta un objeto y lo serializa).

Kubeless tiene una interfaz de usuario que le permite editar su función y luego implementarla con un clic.

Kubeless tiene una interfaz de usuario que le permite editar su función y luego implementarla con un clic.

Si no desea desencadenar las funciones desde una solicitud HTTP, Kubeless también se puede configurar para responder a mensajes Kafka o NAT, o una invocación programada en un momento determinado. También puede ampliar esto creando una fuente de recursos personalizada para los eventos.

El enfoque Kubeless será más atractivo para cualquiera que haya adoptado Kubernetes por completo y se sienta cómodo dentro de este mundo de clústeres y escalado automático. Kubeless es principalmente una herramienta para convertir rápidamente un código básico en un clúster de Kubernetes que responde a la solicitud.

OpenWhisk
OpenWhisk es la herramienta oficial de IBM para crear funciones en la nube en IBM Cloud. También es un proyecto de código abierto (en estado de incubación) guiado por la Apache Software Foundation. OpenWhisk es realmente una síntesis de varios proyectos populares de Apache que se unen para tomar algunas líneas de su código, envolverlas en contenedores Docker, e invocar su ejecución a través de una API REST. Las solicitudes son enviadas por Nginx, convertidas en mensajes de Kafka y luego pasadas a los contenedores. La información de autenticación y gestión se almacena en un CouchDB. Es como una reunión de la Fundación Apache.

El código en sí se puede escribir en JavaScript, Java, Python, PHP, Go y, ¿quién sabe? Incluso Swift para aquellos que se toman un tiempo libre escribiendo aplicaciones para iPhone. Por supuesto, puede usar casi cualquier cosa que pueda agrupar en un contenedor Docker, siempre que los parámetros de la función puedan ser aceptados por stdiny los resultados drantransferidos a través de stdout.

Los desarrolladores de OpenWhisk han construido esencialmente un conjunto de frameworks estándar para cada uno de los principales lenguajes que tomarán algo de entrada de texto y escindirán algunos resultados de texto usando algunas bibliotecas preconfiguradas. Cuando escriba su función corta, OpenWhisk la insertará en este contenedor estándar y todo debería funcionar, si ha seguido las instrucciones y ha escrito su función correctamente.

Siempre habrá arrugas. El código de Java espera la biblioteca Google GSON para estar disponible. El contenedor de su código Swift ejecutará la versión de código abierto de Swift, por lo que puede haber o no momentos en los que el código se comporte exactamente igual a lo que ha experimentado en el mundo de iOS. Es probable que JavaScript sea la opción más popular para todos, y su código JavaScript se ejecutará dentro del Nodo 6 o Nodo 8, que son bien entendidos y predecibles.

La ruta de una solicitud de OpenWhisk. Después de que la solicitud llega a la puerta de enlace HTTP, viaja a través de Kafka hacia los paquetes Docker correctos.

La ruta de una solicitud de OpenWhisk. Después de que la solicitud llega a la puerta de enlace HTTP, viaja a través de Kafka hacia los paquetes Docker correctos.

Sin embargo, hubo una gran diferencia entre usar OpenWhisk en la nube bien curada de IBM y ejecutarlo en mi propia máquina. La interfaz web de IBM simplificó la escritura de algunas líneas y su ejecución exitosa. Me tomó solo media hora pasar de la nada a una interfaz en ejecución que almacenaba texto en una base de datos de IBM Cloudant.

Cuando traté de hacer algo similar con la distribución de código abierto, seguí ejecutando en roadblock después de que roadblock configuró el host de API. La documentación no está tan completa como debería ser. Hay punteros a varias rutas diferentes de inicio rápido, y estará adivinando y llenando agujeros a medida que avanza.

Pronto queda claro que hay bastante configuración para que todo esto se ejecute en su propia máquina. Las instrucciones para el empaque, su función Swift es un buen ejemplo de cómo algunas líneas de código requieren mucha configuración y secuencias de comandos para hacerlo funcionar.

Serverless vs. simplicidad
Los cuatro proyectos llenan un nicho bastante estrecho. La palabra “sin servidor” no se usa de la manera más amplia posible, y hay muchas otras opciones que ofrecen mucha de la misma flexibilidad y libertad de scutwork sin usar la palabra de moda “sin servidor”. A menudo se dice que las bases de datos son la opción sin servidor original y muchos de los sistemas de código abierto como WordPress, Drupal y Magento son efectivamente sin servidor. Los extiendes agregando fragmentos de PHP que se ajustan a un gran framework. Lo que solíamos llamar complementos o módulos, podría comercializarse como “sin servidor”.

En este contexto, ninguna de estas herramientas está tan libre de preocupaciones como cualquiera de esa generación de tecnología. Estas cuatro plataformas sin servidor están más cerca de un administrador mejorado para los clústeres de Kubernetes o Docker. Son más como herramientas de administración que hacen que sea más simple hacer malabares con toda la configuración que necesita hacer para configurar y ejecutar estos clústeres. O como las herramientas automáticas de compilación que envuelven su función y la ejecutan en un clúster.

Los límites de su función están definidos por su arquitectura. Los creadores de herramientas tienen como objetivo ofrecer la máxima flexibilidad. Todos ellos tienen una larga lista de idiomas admitidos, pero luego tratan de endulzar el trato diciendo que trabajarán con cualquier binario que obedezca las reglas de formato de entrada y salida. Entonces, todo lo que pueden hacer es unir las partes y escupir un contenedor.

Resulta que meter las piezas dentro del contenedor sigue siendo una gran parte del desafío. Toda la literatura dice que puede ejecutar estas tareas o acciones escribiendo una función. Pero qué función puede ser. Y entonces está atascado manejando todo el trabajo dentro del contenedor. Tiene que obtener las bibliotecas y el código dentro de allí justo antes de entregar el control. Y luego tiene que manejar todas las otras partes como las bases de datos y las APIs.

Esto termina siendo mucho más trabajoso que solo escribir un poco de código para AWS Lambda, IBM Cloud Functions o los equivalentes de Microsoft Azure y Google Cloud. Cuando todos los planetas se alinean en ese mundo, el almacenamiento de datos de la nube o los servicios API ofrecen toda la persistencia y el análisis que necesita. Realmente solo tiene que escribir algunas funciones simples para codificar un poco de lógica de negocios y listo. El resto de la nube está ahí para hacer el trabajo.

Toda la persistencia, las integraciones de API y otros andamios que proporcionan las nubes representan un desafío para los proyectos de código abierto. Todos los proyectos hacen un buen trabajo al tomar su función y ponerla en funcionamiento. Pero no manejan todo lo demás, y eso significa que también tendrá que duplicar todas estas otras características. Si pisotea y huye de los principales proveedores de la nube, se sentirá como el niño que se escapa de casa con una mochila llena de ‘Pop Tarts’ y descubre que el hogar es más que comida. Es una cama, una lavadora, una televisión, un baño, un perro, etc.

Comodidades en la nube
En este punto, los proyectos de código abierto son bastante buenos para las propias nubes. Después de desempacar estos proyectos de código abierto, rápidamente comencé a tropezar con docenas de formas en que la vida es más difícil fuera del cómodo y encerrado mundo de la nube. Esto puede cambiar un poco a medida que las plataformas maduran y los programadores empujan el significado de la palabra “sin servidor”.

Al principio, creo que serverless estaba destinado principalmente a ser usado como un tipo de script de shell para la nube, una forma de agregar un poco de lógica para suavizar el flujo de datos hacia y desde los grandes servicios como IBM Cloudant o Amazon S3. Ahora las personas están adoptando la idea por su simplicidad, y luego están cambiando y escribiendo funciones increíblemente complejas dentro del framework sin servidor. Algunos de los programadores más ‘machos’ están llevando a cabo trabajos de transcodificación, de máquina o computacionales bastante complejos y los calzan en llamadas sin servidor que apenas terminan por debajo de los límites de tiempo y memoria.

Los kits de herramientas de código abierto hacen un buen trabajo con esta visión más grande y más grandiosa de serverless. Si va a hacer casi todo el trabajo dentro de su única función, bueno, estas herramientas lo pondrán en marcha en poco tiempo.

Pero aquí está el problema. La razón por la cual el servidor puede ser más barato para muchas personas, es porque solo paga por el servidor cuando está ejecutando su código. Hasta que tenga una carga de trabajo lo suficientemente grande como para mantener un servidor funcionando a pleno rendimiento, debería ser mucho más económico ejecutar su función en una nube que le ayudará a compartir el hardware con otras funciones. Si su función genera solo el 10% de una carga, puede ser más barato pagar el 10% del precio inflado de un servidor en la elegante y sobrecargada nube, que el 100% de un servidor en su sala de máquinas cuando el 90% del servidor se desperdicia.

La economía de esto es confusa e involucra el costo de la electricidad, el costo de los bienes inmuebles y el costo del hardware. Si es inteligente, puede ahorrar mucho. Estos proyectos de código abierto hacen posible que considere duplicar la magia sin servidor en su propia granja de servidores, pero también significa que tendrá que navegar por toda la complejidad económica y de despliegue usted mismo. La buena noticia es que hacen un trabajo bastante bueno al manejar el esfuerzo de convertir una función en un contenedor en ejecución. Si solo esa fuera la única tarea.

Peter Wayner, InfoWorld.com – Fuente: CIOPeru.pe

Ordenado por: Nuevas Tecnologías Tags: 

TOT

 

 

Contenidos recomendados...

Comparta esta publicación

Artículos relacionados

Escriba su comentario

Ud. tiene que estar conectado para publicar comentarios.

Red de publicaciones IDG en Latinoamérica: Computerworld Ecuador - Computerworld Colombia - CIO Perú // Contáctenos
© 2018 Computerworld Venezuela - All rights reserved ---- WordPress - Tema adaptado por GiorgioB