Llegamos a ustedes gracias a:



Reportajes y análisis

La informática sin servidor explicada

Por fin libertad para los desarrolladores

[01/06/2018] La informática sin servidor -o serverless- proporciona una gran oportunidad para los desarrolladores que buscan alivio de la carga que proporciona mantener una infraestructura. Al abstraer todo menos un bloque de código, el modelo sin servidor hace que sea más rápido para los desarrolladores iterar y desplegar código nuevo, permitiendo que los equipos más pequeños -con presupuestos más pequeños- hagan cosas que solo las grandes empresas podían hacer antes. O, como dijo recientemente Mat Ellis, fundador de Cloudability, en un episodio de CloudCast, "Serverless intenta industrializar el impacto de los desarrolladores".

Por supuesto, en el fondo, los servidores aún existen, zumbando. Pero las arquitecturas sin servidor son apátridas. Hacen su trabajo ejecutando un poco de lógica -una función-, y llamando a otros servicios para hacer lo que necesitan. Si es un desarrollador que principalmente crea aplicaciones que utilizan servicios a través de APIs o necesita responder a eventos, la arquitectura serverless puede ser el medio más fácil, rápido y menos arriesgado para hacer el trabajo.

En este artículo, analizamos lo que realmente significa la arquitectura sin servidor, o serverless, ofrecemos una comparación detallada de las principales opciones de nubes públicas y arrojamos luz sobre un proyecto real sin servidores en curso en Coca-Cola.

La informática sin servidor definida: Se trata de la función

Serverless es un modelo de servicio de computación en la nube que, como IaaS, PaaS, SaaS, BaaS y CaaS, depende del acceso ubicuo, conveniente y bajo demanda a un grupo compartido dinámico de red configurable, almacenamiento y recursos informáticos. Serverless, sin embargo, toma un enfoque diferente al uso de esos recursos.

No existe una definición acordada para la informática sin servidor, pero ha surgido un manifiesto sobre el concepto. Con serverless, las funciones son la unidad de implementación. No hay máquinas, máquinas virtuales o contenedores visibles para el programador.

Entre los principales servicios disponibles para servidores en la nube se encuentran AWS Lambda, Azure Functions y Google Cloud Functions. En la nube, "FaaS" (función como un servicio, por sus siglas en inglés) puede ser un mejor término. Y cuando digo "función", realmente me refiero a una función. Aquí hay un ejemplo de AWS Lambda codificado en Node.js:

exports.myHandler = function (evento, contexto, devolución de llamada) {
console.log ("value1 =" + event.key1);
// hacer cosas
devolución de llamada (nulo, "algún mensaje de éxito");
}

Eso es. Cargue la función y conéctela a una solicitud o evento. Cuando su proveedor de alojamiento sin servidor (en este caso, AWS) detecta que se ha realizado una solicitud (una invocación de REST, por ejemplo) o ha ocurrido un evento (digamos, un archivo se agrega a un depósito de S3), se llamará a su función, los argumentos pasados y sus parámetros de retorno se transmitirán como el resultado. Es más complicado en la práctica, por supuesto, porque puede agregar restricciones de seguridad, por ejemplo, pero esa es la esencia.

Detrás de la escena hay servidores, por supuesto, pero como desarrollador, nunca debe pensar en ellos. Todo lo que debe saber es su función.

Su función puede escribirse en cualquier idioma admitido por su proveedor. Todo lo que necesita hacer es asignar una solicitud o evento entrante a una llamada de función. Cada proveedor tiene su propio conjunto de idiomas admitidos, convenciones, procedimientos, costos, capacidades y restricciones (consulte la tabla a continuación). Pero esto es lo que el manifiesto serverless quiere decir con "traiga su propio código".

Su función puede ser arbitrariamente compleja, y puede llamar a bibliotecas incluidas o servicios externos a través de una API. Para ser escalable, una función sin servidor solo debe usar servicios que sean escalables.

Dependiendo del proveedor, el código puede escribirse directamente en un editor en línea o cargarse como un archivo de código, un archivo .zip o .jar, o un contenedor. Esta es también una desventaja de la falta de servidores, ya que las herramientas para cargar y administrar su código a través del ciclo de lanzamiento aun no son muy buenas, aunque están interviniendo numerosos marcos para llenar el vacío.

Por supuesto, el código realmente no puede ser arbitrariamente complejo. Hay restricciones dependientes del proveedor. Cada host tiene un tamaño máximo de carga de código (50MB para AWS Lambda, por ejemplo). Cada host tiene un tiempo máximo de ejecución de la función (entre 1 y 300 segundos para AWS Lambda). Cada función también está limitada en la cantidad de memoria que tiene disponible y la potencia de la CPU utilizada. ¿Desea más memoria, una mejor CPU o un tiempo de ejecución más largo? Pagará más. La facturación es otra diferencia entre proveedores, como verá a continuación.

Serverless_computing_1.mp4

Esta animación explica algunos de los conceptos de informática sin servidor, y cómo representa la próxima fase de la computación en la nube para aplicaciones y productos de Internet.

La informática sin servidor cambia la gestión del código

Ya no tiene que lidiar con la planificación de la capacidad, la implementación, el escalado, la instalación, los parches, etc. Esto a menudo se llama "sin operaciones" o "menos operaciones", pero en realidad son "operaciones diferentes". El código aún necesita ser organizado, desarrollado, construido, probado, versionado, liberado, registrado y monitoreado.

Ya que todo lo que ve es la función, su proveedor está a cargo de activar sus funciones en respuesta a cualquier solicitud o evento. Cuando llega una solicitud y una instancia gratuita de la función no está disponible, el código debe asignarse a un servidor y comenzar. Como desarrollador, no hace nada. El proveedor debe asegurarse de que haya suficiente capacidad para manejar la carga. Por supuesto, en el caso de un escenario de arranque en frío, el golpe de latencia es uno de los inconvenientes de serverless.

La economía de la informática sin servidor

Con serverless, paga por el consumo y solo se le cobra cuando se ejecuta su servicio. Nunca paga por tiempo de computación inactivo. Las implicaciones de esto son vastas. Puede construir una infraestructura completa sin pagar un centavo. Los costos operativos, de desarrollo y de escalado, se reducen.

Contraste esto con PaaS y IaaS, donde paga por capacidad. Un proveedor de PaaS administrará los servidores por usted, pero su aplicación tiene procesos de larga ejecución que siempre está pagando, incluso si permanecen inactivos. La capacidad se puede gestionar construyendo un sistema de autoescalamiento sensible a la carga, pero siempre pagará por un exceso de capacidad.

Cómo manejar el estado en la informática sin servidor

Como todo lo que ve es una función, no hay lugar para almacenar el estado. Cuando se ejecuta una función, sus recursos de cálculo se pueden recolectar y reutilizar. Por lo tanto, el estado debe almacenarse en algún otro servicio, como una base de datos o un caché.

Para controlar los costos de facturación, los proveedores colocan un tiempo de ejecución máximo en una función. Actualmente, son cinco minutos para AWS Lambda y Azure Functions. Hay una desventaja en los límites de ejecución. ¿Qué sucede si, por ejemplo, está actualizando una base de datos? ¿O si su función hace muchas llamadas a otros servicios para devolver un resultado? ¿O si su función tiene una gran cantidad de información para procesar? Estas operaciones pueden demorar mucho más de cinco minutos en algunos casos.

A menos que su función sea simple, deben codificarse como servicios sin estado y orientados a eventos, impulsados por una máquina de estado que mantiene los datos en una tienda persistente entre invocaciones. Esto puede ser complicado. Pero sus enfoques normales en la nube aún funcionan. Divida las entradas en lotes y póngalos en una cola de trabajo, por ejemplo.

Para ayuda, AWS ha creado un nuevo servicio llamado Step Functions que implementa una máquina de estado y permite que las funciones duren indefinidamente. En realidad, AWS Lambda debería ser mejor que requerir el uso de un servicio completamente diferente y costoso.

Métricas y registro en informática serverless

Aunque serverless reduce la interfaz de servicio a una única función, a veces llamada nanoservicio, la complejidad siempre se conserva. Con PaaS, la unidad atómica de cálculo es la aplicación. Esto tiene ventajas y desventajas. Debido a que una aplicación es grande, puede ser lenta para iniciarse y detenerse; puede ser difícil escalar en respuesta a la demanda; puede ser difícil facturar en un nivel granular. Pero PaaS también es fácil de administrar, monitorear y depurar.

Al extender el código a través de una gran cantidad de funciones, sin servidor puede ser realmente difícil de depurar. El seguimiento de los flujos lógicos se distribuye entre varios archivos de registro diferentes, y no hay conexión entre las llamadas. El registro y las métricas son obligatorios, pero no son suficientes. Las herramientas en esta área necesitan mejorar.

Comparación de proveedores de computación serverless

Entonces, ¿cómo comenzar? Hay múltiples opciones para comenzar con serverless. Los dos grandes espacios son usar la nube pública u optar por una solución local.

Proveedores sin servidor basados en la nube: Serverless se ha convertido en una apuesta de mesa para cualquier nube pública, por lo que los principales proveedores están desarrollando su propio producto. Amazon tiene AWS Lambda desde abril del 2015. Microsoft tiene Azure Functions desde noviembre del 2016. Google tiene Google Cloud Functions, que está en versión beta.

En términos de decidir entre los tres, si ya está en la nube pública, lo mejor es usar el producto de su proveedor actual. Una gran parte de la utilidad de serverless es la riqueza de los servicios disponibles y los eventos que puede consumir. Esas elecciones son mejores dentro de su nube. Pero si está comenzando en la nube y la estabilidad es importante, entonces AWS Lambda ha estado por más tiempo y es la opción más segura hasta el momento.

Para AWS Lambda, las funciones son independientes, aunque en la práctica, a menudo se administran en grupos utilizando un marco como https://serverlesss.com/. Se le cobrará según el número de solicitudes para sus funciones y la hora en que se ejecuta su código. Si desea más CPU, debe asignar más memoria.

Con Azure Functions, una aplicación de función se compone de una o más funciones individuales que Azure App Service administra juntas. Una aplicación de función puede usar un plan de alojamiento Consumption o un plan de alojamiento de App Service. Con un plan de consumo, una aplicación de función se amplía automáticamente, y se paga según el tamaño de la memoria y el tiempo total de ejecución en todas las funciones, medida en segundos-gigabytes. El uso de una facturación del plan de alojamiento del servicio de aplicaciones se parece más a EC2.

Debido a que Google Cloud Functions todavía está en beta, aún se desconoce cómo funcionan y se facturan las funciones. Sabemos que hay dos tipos de funciones: funciones HTTP y funciones de fondo. Las funciones HTTP se invocan directamente a través de HTTP (S). Las funciones de fondo se invocan indirectamente mediante un mensaje en un sub tema Pub / Sub de Google Cloud o un cambio en un bucket de Google Cloud Storage.

  AWS Lambda Azure Functions Google Cloud Functions
Sistema operativo Linux Windows Linux
Idiomas soportados JavaScript / Node.js, Python, Java, C # JavaScript, C #, F #, Python, PHP, Bash, Batch, PowerShell JavaScript / Node.js
Precios Nivel gratuito (primeras solicitudes de 1M o 400.000 segundos GB de tiempo de computación gratis por mes); cargos adicionales por solicitud: 20 centavos por solicitud de 1M; cargos adicionales de cómputo: 0.001667 centavos por segundo GB; la memoria y la CPU están vinculadas en Lambda Nivel gratuito (primeras solicitudes de 1M o 400,000GB segundos de tiempo de computación gratis por mes); cargos adicionales por solicitud: 20 centavos por solicitud de 1M; cargos adicionales de cómputo: 0.0016 centavos por segundo - GB Desconocido
Licencia Fuente cerrada Fuente abierta Desconocido
Tiempo máximo de ejecución por solicitud 5 minutos 5 minutos (plan de cálculo de consumo) Sin límite
Fuentes de eventos S3, DynamoDB, Kinesis Streams, SNS, SES, Cognito, Cloud Formation, Cloud Watch, Code Commit, Programar eventos, Configuración, Eco, Alexa, Pasarela API HTTP (webhook), GitHub (webhooks), Azure Storage (blob, colas, tablas), Azure Event Hubs, Azure Service Bus (colas y temas), Azure DocumentDB, Azure Notification Hubs, local (utilizando Service Bus) Desencadenantes HTTP (solicitudes HTTP), desencadenantes de Cloud Pub / Sub, desencadenantes de almacenamiento en la nube, registro en la nube, Gmail
Tablero web CLI, funciona lo suficientemente bien CLI, excelente (Visual Studio Online incluido) Cloud Platform Console, CLI (parece ser la interfase principal)
Gestión de registro Reloj en la nube Transmisión de eventos en vivo (básica) Stackdriver Logging, Stackdriver Monitoring,Stackdriver Debugger, emulador local
IAM granular La política de IAM se puede asociar con Lambda Aún no Desconocido
Almacenamiento persistente Ninguna Variables de entorno Desconocido
Invocación HTTP AWS API Gateway (tiene gran flexibilidad, es complejo de usar) Webhooks HTTP (automático, uno por función, muy simple) Trigger HTTP (muy simple)
Función de control de versiones Versiones y alias No Cloud Source branch / tag
Asignación de memoria Por función Por servicio de aplicación Desconocido
Número máximo de funciones Sin límite 20 por proyecto 20 por proyecto (durante la etapa alfa)
Ejecuciones concurrentes 100 ejecuciones paralelas por cuenta y por región (puede aumentarse) 10 instancias (que no son funciones, puede haber docenas o incluso cientos de ejecuciones concurrentes en una sola instancia) Sin límite
Gestión de dependencia Compila todos los paquetes externos y empaqueta el código fuente package.json / project.json NPM package.json
Autenticación AWS Cognito (flexible pero complejo) Se puede autenticar desde Microsoft auth y terceros (Facebook, Twitter, Google) Desconocido
Almacenamiento de disco 500MB, efímero 5TB, persistente Desconocido
Despliegue Edición en línea (primitiva); Cargar zip desde el disco local o S3 Edición en línea (primitiva); Git (GitHub, Bitbucket); Dropbox; Visual Studio Online (muy bueno); OneDrive; Consola Kudu; Servicios de equipo de Visual Studio Carga de zip; Almacenamiento en la nube; Cloud Source Repositories (una plataforma de Git); GitHub; Bitbucket

Proveedores serverless en las instalaciones: Hospedar serverless en su propio centro de datos aún no es una tarea sencilla, aunque cada vez es más fácil y hay múltiples opciones. Aun así, debe estar dispuesto a configurar y mantener la infraestructura.

Este es un espacio de movimiento rápido. Los vendedores están luchando por una posición, tratando de crear un mercado a la sombra de los gigantes proveedores de nubes públicas. Vaya con cuidado. Cada promesa de portabilidad de la aplicación debe ser vista con escepticismo.

  • Azure Stack. Si su objetivo es ejecutar en las instalaciones como la nube pública, Azure Stack parece ser la mejor opción. Es una gran promesa como una opción sin servidor equivalente a la nube, aunque eso requiere la pregunta de por qué no usar la nube.
  • IBM OpenWhisk. OpenWhisk es la oferta FaaS de IBM que puede ser alojado o local. Tiene una puerta de enlace API, soporte nativo Swift y Node.js, además de compatibilidad con imágenes Docker. Es probable que vea más adopción este año, ya que es uno de los productos mejor respaldados.
  • Iron.io. Iron.io fue el primer proveedor sin servidor, pero ahora tiene que abrirse camino en un mundo de proveedores de grandes nubes. Ofrece dos opciones: IronFunctions y Project Kratos. Project Kratos es una estrategia de adopción: permite a las empresas ejecutar la funcionalidad de AWS Lambda en cualquier proveedor de la nube, así como en las instalaciones, eliminando el bloqueo del proveedor; mientras que IronFunctions es la estrategia extendida: es una plataforma de código abierto sin servidor/FaaS basada en Docker que puede ejecutar en cualquier lugar: en nubes públicas, privadas e híbridas, incluso en su propio equipo portátil.
  • Fission.io. Fission.io es un nuevo enfoque interesante para serverlesss que usa Kubernetes para su infraestructura en la nube. Kubernetes se ocupa de la gestión, programación y creación de redes del clúster. Hay una línea de pensamiento que Kubernetes, debido a que tiene una comunidad de desarrolladores dinámica y productiva, que surgirá como la infraestructura de nube de fuente abierta. Construir un producto sin servidor en Kubernetes crea una interesante pila local alternativa.
  • OpenStack. OpenStack actualmente no tiene soporte nativo para FaaS, pero hay algo gestándose llamado Project Picasso. Tiene dos componentes principales: Picasso API e IronFunctions. Picasso utiliza el motor contenedor de back-end provisto por IronFunctions.

Implemente el suyo. Serverless no es una ciencia exacta. Puede construir su propia plataforma sin servidor sobre su infraestructura actual y obtener todos los beneficios sin tener que migrar a una nueva pila. Esta es una buena opción si no desea tratar su centro de datos como si fuera una nube.

Caso de estudio de la informática sin servidor: Coca-Cola

¿Cómo funciona el trabajo sin servidor en el mundo real? Aquí hay un video, Coca-Cola: Ejecución de aplicaciones sin servidor con requisitos empresariales, en el que Michael Connor, director de estrategia técnica de Coca-Cola North America, explica cómo Coca-Cola utiliza AWS Lambda para procesar transacciones desde sus máquinas expendedoras.

https://www.youtube.com/watch?v=yErmil00DYs

Algunos hallazgos:

  • Serverless es casi tres veces más barato que IaaS. Pero en aproximadamente 80 millones de transacciones por mes, IaaS se vuelve más atractivo.
  • Coca-Cola ahora exige soluciones sin servidor o requiere una justificación de por qué no usará serverless.
  • Serverless no resuelve todos sus problemas, pero resuelve problemas que no contribuyen al resultado final.
  • Serverless no causa desperdicio a la cabeza de cuenta. Elimina el trabajo sucio. Aplicar parches a los servidores no ayuda a refrescar.

Coca-Cola midió dónde gastó tiempo al usar IaaS vs. serverlesss:

Tarea IaaS Sin servidor
Proyectos comerciales 39% 68%
Trabajo no planificado 24% 6%
Cambios 20% 17%

Solo el 39% del tiempo se gastó en la entrega de proyectos comerciales al usar IaaS. Luego de pasar a la falta de servidores, Coca-Cola gastó el 68% de su tiempo en proyectos comerciales, con margen de mejora.

Después de mudarse a AWS, hubo una avalancha inicial de servidores en minutos, cuando solía llevar semanas. Esa prisa desaparece a medida que se da cuenta del costo de mantener servidores a lo largo de su vida. Serverlesss reduce este dolor, señala Connor de Coca-Cola.

Coca-Cola también quiere que los desarrolladores se desarrollen, no que realicen deberes de devops. Pasar a "sin servidor" reduce drásticamente la cantidad de operaciones necesarias, y el tipo de operaciones que aún están en juego está más en línea con el conjunto de habilidades del desarrollador.

El ejemplo de máquina expendedora en cuestión implica lo siguiente:

  • Cuando compra algo en una máquina expendedora, desliza su tarjeta.
  • La transacción va desde la máquina expendedora a una Pasarela de pago.
  • Payment Gateway envía una llamada REST API a Amazon API Gateway.
  • API Gateway llama a una función Lambda.
  • La función maneja toda la lógica comercial: transacciones, créditos, débitos, etc.
  • Las notificaciones se envían a los usuarios a través de un servicio de notificaciones push de Apple/Android. A su vez, lo vuelven a enviar a Apple Pay/Android Pay, para que pueda ver un débito en la billetera de su dispositivo.
  • Luego hay "compre 10 y obtenga una gratis", y otras promociones además de todo esto.

Con Lambda, todo esto sucede en menos de un segundo, y Amazon carga 1/1,000th de un centavo. Además, se cobra a Coca-Cola solo si un cliente ejecuta una transacción. De lo contrario, Coca-Cola no paga nada. Para Lambda, recibiendo aproximadamente 30 millones de llamadas al mes, el costo fue de 4.490 dólares por año.

Al utilizar un enfoque AWS IaaS, el costo de un servidor T2 mediano es de aproximadamente 56 dólares por mes. El costo completamente cargado es casi cinco veces mayor que: 250 dólares = 56 dólares (servidor) + 150 dólares (administración: parches, en llamadas, contabilidad) + 30 dólares (seguridad: antivirus) + 14 dólares (automatización: Marioneta, Chef, Ansible). Con seis servidores medianos T2, el costo fue de 12.864 dólares por año, por lo que la solución Lambda es un 65% más económica que la solución IaaS.

Por supuesto, hay un punto de equilibrio. Si está ejecutando una gran cantidad de transacciones, resulta más económico ejecutar sus propias máquinas. Para este ejemplo, con aproximadamente 80 millones de visitas por mes, el cambio a IaaS comenzó a parecer atractivo para Coca-Cola.

Otro detalle a destacar de este estudio de caso es cómo el servidor maneja los ciclos de vida de larga cola. Digamos que saca sus primeras diez máquinas expendedoras. Con IaaS, paga 13 mil dólares por ese clúster. ¿Qué hay del final de la vida? Cuando tenga esas últimas diez máquinas que aún no se han terminado, todavía está pagando 13 mil dólares por año por IaaS. Serverless, sin embargo, sube y baja elegantemente. Cuando llega a menos de un millón de visitas por mes, hay un ahorro del 99% en los costos.

El costo de ir sin servidor es convincente a menos que esté ejecutando grandes volúmenes. ¿Cuántos servicios está ejecutando a una tasa de volumen más baja?

Vea también