Header Ads Widget

Ticker

6/recent/ticker-posts

Los beneficios de un backend de API sin servidor


 Imagínese si su backend no tuviera infraestructura. Sin servidor permanente, sin ningún lugar al que su API pueda llamar hogar. Suena un poco triste, ¿no? Resulta que los backends sin servidor podrían ser el próximo gran avance para implementar una arquitectura de nube verdaderamente escalable.

¿Cómo se puede hacer que una interfaz de programación de aplicaciones sea liviana en el lado del cliente y, al mismo tiempo, escalable a las mayores demandas de tráfico? Los proveedores de SaaS han estado migrando a una arquitectura sin servidor para resolver este dilema, así como muchos otros problemas operativos que se encuentran en el alojamiento de sus aplicaciones web.

En este artículo, identificaremos cuál es la moda sin servidor y por qué algunos proveedores pueden querer considerar tener un backend de API sin servidor . Dirigidos por Rich Jones de Gun.io, definiremos lo que entendemos por arquitectura sin servidor, proporcionaremos un ejemplo de una práctica en la actualidad y nuestro objetivo es esbozar algunos de los posibles beneficios y trampas de adoptar este enfoque.

¿Qué significa "sin servidor"?

El alojamiento en la nube tradicional es permanente. Al igual que en, usted elige un proveedor de servidor y ellos ejecutan su software en múltiples servidores en todo el mundo. Existen ubicaciones físicas precisas y recurrentes donde se almacenan sus datos y se procesan sus funciones.

La computación sin servidor es una desviación estratégica de este modelo: es una configuración impulsada por eventos sin infraestructura permanente . Esto no significa que los servidores ya no estén involucrados, más bien, significa que los servidores se crean automáticamente según las necesidades para escalar a las demandas de su aplicación.

Pero para los desarrolladores, lo que realmente significa sin servidor es menos tiempo dedicado a las operaciones, ya que ya no tienen que preocuparse por el mantenimiento tradicional del servidor. Los beneficios de una infraestructura sin servidor realmente se suman:

  • No más problemas de capacidad
  • Los servidores tienen escala automática
  • No pagas por el tiempo de inactividad
  • Fiabilidad y disponibilidad constantes
  • Sin equilibrio de carga, sin parches de seguridad

En general, sin servidor simplemente equivale a tranquilidad  (pero tal vez no para algunos, ya que  Operaciones puede necesitar encontrar otro trabajo por completo).

Esta publicación se inspiró en una charla de Rich Jones de Gun.io en la Cumbre de la Plataforma 2016:

De entornos tradicionales a entornos sin servidor

Para comprender las sutilezas entre los enfoques tradicionales y sin servidor, veamos una implementación básica de muestra paso a paso de cada uno.

Solicitud web tradicional

Una interacción con un servidor web tradicional se producirá a menudo en un formato similar a este:

  1. Un servidor web Apache o NGINX escucha los eventos a medida que llegan.
  2. A continuación, el servidor lo convierte en un entorno de interfaz de puerta de enlace de servidor web (WSGI).
  3. Esto se envía a una aplicación para procesar la solicitud.
  4. Luego, el servidor web envía la respuesta al cliente.
  5. El servidor web reanuda la escucha.

Hay algunos inconvenientes de este enfoque. Por un lado, si encuentra un gran aumento en el tráfico, este sistema se encargará de las solicitudes a medida que ingresan. Si el usuario final no está adelantado en la cola, es probable que experimente un tiempo de espera y la página se verá como si estuviera abajo. Los visitantes de la cola de mediana a tarde se enfrentan a velocidades muy lentas. En segundo lugar, cuando no está procesando una solicitud, el servidor web se deja en un estado inactivo para sondear, desperdiciando recursos valiosos que podrían usarse en otros lugares.

Solicitud web sin servidor

Dentro de una infraestructura sin servidor, cada solicitud corresponde a su propio servidor. Una vez que el servidor procesa la función, se destruye inmediatamente. Por ejemplo, así es como Jones's Zappa maneja una solicitud web:

  1. La solicitud llega a través de una puerta de enlace API.
  2. La solicitud de la API se asigna a un diccionario mediante Velocity Template Language (VTL).
  3. Se crea un servidor.
  4. Luego, el servidor convierte el diccionario a un Python WSGI estándar y lo introduce en la aplicación.
  5. La aplicación lo devuelve y lo pasa a través de API Gateway.
  6. El servidor está destruido.

Sorprendentemente, todo esto ocurre en menos de 30 milisegundos, de modo que " para cuando el usuario realmente ve el [contenido aparecer en la] página, el servidor ha desaparecido ... lo que en realidad es algo bastante zen si lo piensas ", dice Jones.

Entonces, ¿cuáles son las ventajas de generar servidores en un momento? Para Jones, la principal razón es la escalabilidad . Dado que una sola solicitud coincide con la creación de un solo servidor, esta relación se puede escalar indefinidamente, en una escala de literalmente billones de eventos por año.

El segundo es el ahorro de costes . Pagar por milisegundos significa que solo está gastando dinero en el procesamiento real del servidor. AWS Lambda cobra alrededor de $ 0.0000002 por solicitud. Pero dado que Lambda tier ofrece 1 millón de solicitudes gratuitas por mes, esto significa que podría permanecer gratis para proyectos pequeños o nuevas empresas .

Esta escalabilidad infinita hace que la infraestructura sin servidor sea una bendición tanto para proyectos pequeños como microservicios, API, proyectos de IoT o chatbots, como también para sistemas de gestión de contenido empresarial tradicionales más grandes como Django .

Lea también: Diseño de una verdadera máquina de estados REST

Cómo empezar: comprensión de los proveedores sin servidor

¿Suena interesante? Una forma fácil de comenzar es con un marco sin servidor como Zappa , Serverless Framework o Apex ( más información aquí ). Con algunos marcos, como Zappa, puede adoptar la informática sin servidor con bastante facilidad para sus API existentes. Los tres se basan en AWS Lambda , el servicio de computación en la nube de Amazon, pero otros importantes proveedores de computación sin servidor se encuentran dentro de las ofertas de Microsoft Azure Functions , Google Cloud Functions e IBM Bluemix OpenWhisk . Sin embargo, según Jones:

“AWS Lambda es, con mucho, el líder en el espacio ... es mucho más capaz en prácticamente todos los aspectos. Los demás todavía están tratando de ponerse al día ".

Diseño de aplicaciones sin servidor impulsadas por eventos

Dentro de un entorno sin servidor, un elemento de diseño principal que resultará novedoso para los recién llegados es que el código se ejecutará solo en respuesta a eventos . Dado que construir una aplicación robusta y basada en eventos significa diseñar en respuesta a eventos, ¿qué podemos definir como nuestras fuentes de eventos ?

Un evento puede estar relacionado con operaciones de archivos ; por ejemplo, digamos que un usuario carga una imagen y la aplicación necesita cambiar el tamaño de una imagen grande a un avatar pequeño. Con una arquitectura sin servidor, puede hacer que un servicio de miniaturas ejecute una respuesta de forma asincrónica y sin bloqueo. En lugar de configurar un sistema de cola completo, tener una cola alojada en la nube nativa puede manejar esto.

Las notificaciones de soporte, como recibir un correo electrónico, un mensaje de texto o un mensaje de Facebook, también se pueden interpretar como eventos. En lugar de realizar una encuesta para recibir nuevos correos electrónicos, se podría ejecutar una acción específicamente en respuesta a estos. Donde se vuelve realmente interesante es cómo puede tratar las solicitudes HTTP como un evento. Esto, junto con otros tipos de desencadenadores de eventos, generalmente se denomina arquitectura híbrida .

La actividad de la base de datos también podría usarse como un desencadenante de eventos. Un cambio en la fila de una tabla podría desencadenar una acción, por ejemplo. Sin embargo, Jones nos recuerda que tratemos la “API como la principal fuente de verdad en su aplicación” - no realice llamadas SQL dentro de sus funciones de eventos, más bien, canalice esto a través de su API.

Jones nos recuerda que el tiempo también es un factor importante que puede utilizarse como fuente de eventos y será necesario para iniciar tareas o actualizaciones periódicas. A través de estas fuentes de eventos variables, en lugar de crear máquinas que sondean constantemente sus recursos en busca de cambios, esencialmente está configurando activadores dentro de sus aplicaciones para ejecutar una respuesta.

Relacionado: Por qué debería crear aplicaciones con un backend de API - BaaS

5 consejos profesionales sin servidor:

Todo esto suena increíble, pero ¿cuáles son las desventajas de crear aplicaciones con backends sin servidor? En su presentación, Jones cubre algunos aspectos de los posibles inconvenientes, cómo evitarlos y algunos consejos generales para aprovechar al máximo un arreglo sin servidor:

  • Evite el bloqueo de proveedores : esto puede ser un gran problema al adoptar cualquier tecnología nueva. Para evitar el bloqueo del proveedor, Jones recomienda integrar software que proporcione ofertas compatibles de código abierto y desacoplar las interacciones del proveedor de su aplicación. En lugar de codificar las interacciones, Jones recomienda desacoplar esta lógica: crear un despachador dentro de una función para agregar un elemento a la cola es una forma de hacerlo.
  • Simulacros de las llamadas de su proveedor para realizar pruebas : al escribir una aplicación simulada o de muestra que se comporta como si estuviera sincronizada con la nube, es posible que desee probar sus funciones en la nube. Placebo es un paquete interesante que registrará sus acciones con AWS y las reproducirá como si estuviera interactuando con el servidor.
  • Piense "sin servidor " y evite la infraestructura : puede llevar un tiempo desarrollar la mentalidad sin servidor. Al desarrollar, considere si realmente necesita una base de datos o si se puede adoptar una cola en su lugar.
  • Establezca diferentes entornos : al realizar pruebas y realizar pruebas, Jones recomienda utilizar CI para múltiples entornos de producción (implementación azul / verde).
  • Implementar globalmente : el uso de una disposición de servidor distribuida geográficamente puede aumentar la velocidad y la seguridad. Los servicios de AWS Lambda pueden hospedarse en 11 regiones, de modo que en cualquier lugar del planeta se puede alcanzar un ping de 20 milisegundos.

Ejemplo: Kickflip SDK

Kickflip es un ejemplo de un SDK sin servidor que proporciona transmisión de video en vivo

Entonces, ¿cómo construimos una API autenticada, con baja latencia, bajo costo, que sea infinitamente escalable, sin tener que preocuparse en absoluto por las operaciones del servidor? Pasemos a un ejemplo de implementación sin servidor en acción.

Kickflip es un SDK que ofrece transmisión de video en vivo a aplicaciones móviles. Una " transmisión en vivo " es esencialmente una combinación de archivos MP4 separados, junto con un manifiesto que determina el orden de los videos. Dado que un servicio de transmisión de video en tiempo real no necesitaría mantener grandes cantidades de datos de video para su uso posterior, es una aplicación ideal para un entorno sin servidor.

Kickflip utiliza una arquitectura híbrida de fuentes de eventos HTTP y no HTTP para activar la creación del servidor a partir de una carga de teléfono móvil, que actualiza el archivo de manifiesto para que los usuarios finales vean los últimos fragmentos de video. Para hacer todo esto, Kickflip utiliza una combinación de servicios: API Gateway para autenticación, una API construida con Lambda, Zappa y Flask , almacenamiento de archivos usando S3 y CloudFront para la entrega de contenido global. El flujo simplificado es el siguiente:

  1. El cliente se autentica con la API . Kickflip utiliza el servicio de generación de claves API de autenticación de Amazon, pero un controlador de gestión de acceso de identidad personalizado también podría funcionar aquí.
  2. La API devuelve un token de acceso de federación de corta duración que solo se puede usar para cargar un archivo en un bucket de S3 específico.
  3. El cliente recibe el token y lo usa para subir el video.
  4. Se ejecuta un servidor AWS Lambda en respuesta a la nueva carga de video y se actualiza el manifiesto de transmisión. Esta carga actúa como fuente de eventos.
  5. El contenido se sirve en la red de entrega de CloudFront para una latencia baja.
  6. Los usuarios ven la última transmisión de video en su dispositivo.
  7. El servidor se destruye y el token de acceso temporal se revoca.

Jones demuestra que con la combinación estratégica de tecnologías, se puede desarrollar un servicio de transmisión de video sin servidor en solo 42 líneas de Python.

Creación de backends de API sin servidor

El movimiento sin servidor representa un profundo cambio de paradigma en nuestra capacidad para crear servicios web impresionantemente escalables. Repensar cómo los eventos pueden provocar iteraciones temporales del servidor puede ser una solución extremadamente rentable para microservicios y grandes proyectos por igual.

Con todos los pequeños servicios conectados que se implementan de esta manera, la disposición sin servidor también reitera el surgimiento de empresas componibles que dependen de muchos servicios diferentes para prosperar; consolidando la posición de la API web como un engranaje importante en la comunicación web moderna y futura.

Recursos adicionales

Publicar un comentario

0 Comentarios