Serverless no se trata de la ausencia física de servidores. Esto no es un asesino de contenedores ni una tendencia pasajera. Este es un nuevo enfoque para construir sistemas en la nube. En el artículo de hoy tocaremos la arquitectura de las aplicaciones Serverless, veamos qué papel juegan el proveedor de servicios Serverless y los proyectos de código abierto. Finalmente, hablemos de los problemas del uso de Serverless.
Quiero escribir un servidor como parte de una aplicación (o incluso una tienda en línea). Podría ser un chat, un servicio de publicación de contenidos o un equilibrador de carga. En cualquier caso, habrá muchos dolores de cabeza: habrá que preparar la infraestructura, determinar las dependencias de la aplicación y pensar en el sistema operativo anfitrión. Luego necesitarás actualizar pequeños componentes que no afecten el funcionamiento del resto del monolito. Bueno, no nos olvidemos del escalado bajo carga.
¿Qué pasa si tomamos contenedores efímeros, en los que las dependencias necesarias ya están preinstaladas y los propios contenedores están aislados entre sí y del sistema operativo anfitrión? Dividiremos el monolito en microservicios, cada uno de los cuales podrá actualizarse y escalarse independientemente de los demás. Al colocar el código en dicho contenedor, puedo ejecutarlo en cualquier infraestructura. Ya mejor.
¿Qué pasa si no quieres configurar contenedores? No quiero pensar en escalar la aplicación. No quiero pagar por contenedores en funcionamiento inactivos cuando la carga del servicio es mínima. Quiero escribir código. Céntrese en la lógica empresarial y lleve productos al mercado a la velocidad de la luz.
Estos pensamientos me llevaron a la informática sin servidor. Sin servidor en este caso significa no la ausencia física de servidores, sino la ausencia de dolores de cabeza en la gestión de la infraestructura.
La idea es que la lógica de la aplicación se divida en funciones independientes. Tienen una estructura de evento. Cada función realiza una “microtarea”. Todo lo que se requiere del desarrollador es cargar las funciones en la consola proporcionada por el proveedor de la nube y correlacionarlas con las fuentes de eventos. El código se ejecutará a pedido en un contenedor preparado automáticamente y solo pagaré por el tiempo de ejecución.
Veamos cómo será ahora el proceso de desarrollo de aplicaciones.
Del lado del desarrollador
Anteriormente empezamos a hablar de una aplicación para una tienda online. En el enfoque tradicional, la lógica principal del sistema la realiza una aplicación monolítica. Y el servidor con la aplicación está funcionando constantemente, incluso si no hay carga.
Para pasar a sin servidor, dividimos la aplicación en microtareas. Escribimos nuestra propia función para cada uno de ellos. Las funciones son independientes entre sí y no almacenan información de estado (sin estado). Incluso pueden estar escritos en diferentes idiomas. Si uno de ellos “cae”, toda la aplicación no se detendrá. La arquitectura de la aplicación se verá así:
La división en funciones en Serverless es similar a trabajar con microservicios. Pero un microservicio puede realizar varias tareas y, idealmente, una función debería realizar una. Imaginemos que la tarea es recopilar estadísticas y mostrarlas a petición del usuario. En el enfoque de microservicio, una tarea la realiza un servicio con dos puntos de entrada: escritura y lectura. En la informática sin servidor, serán dos funciones diferentes que no están relacionadas entre sí. El desarrollador ahorra recursos informáticos si, por ejemplo, las estadísticas se actualizan con más frecuencia de las que se descargan.
Las funciones sin servidor deben ejecutarse en un corto período de tiempo (tiempo de espera), que lo determina el proveedor del servicio. Por ejemplo, para AWS el tiempo de espera es de 15 minutos. Esto significa que las funciones de larga duración deberán modificarse para adaptarse a los requisitos; esto es lo que distingue a Serverless de otras tecnologías populares en la actualidad (contenedores y plataforma como servicio).
Asignamos un evento a cada función. Un evento es un desencadenante de una acción:
Evento
La acción que realiza la función.
Se ha subido una imagen del producto al repositorio.
Comprimir la imagen y subirla a un directorio.
La dirección de la tienda física ha sido actualizada en la base de datos.
Cargar una nueva ubicación en mapas
El cliente paga por la mercancía.
Iniciar procesamiento de pago
Los eventos pueden ser solicitudes HTTP, transmisión de datos, colas de mensajes, etc. Las fuentes de eventos son cambios o apariciones de datos. Además, las funciones pueden activarse mediante un temporizador.
Se resolvió la arquitectura y la aplicación casi se volvió sin servidor. A continuación nos dirigimos al proveedor del servicio.
Del lado del proveedor
Normalmente, los proveedores de servicios en la nube ofrecen informática sin servidor. Se llaman de manera diferente: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Utilizaremos el servicio a través de la consola o cuenta personal del proveedor. El código de función se puede descargar de una de las siguientes maneras:
- escribir código en editores integrados a través de la consola web,
- descargar el archivo con el código,
- trabajar con repositorios git públicos o privados.
Aquí configuramos los eventos que llaman a la función. Los conjuntos de eventos pueden diferir para diferentes proveedores.
El proveedor construyó y automatizó el sistema de Función como Servicio (FaaS) en su infraestructura:
- El código de función termina almacenado en el lado del proveedor.
- Cuando ocurre un evento, los contenedores con un entorno preparado se implementan automáticamente en el servidor. Cada instancia de función tiene su propio contenedor aislado.
- Desde el almacenamiento, la función se envía al contenedor, se calcula y devuelve el resultado.
- El número de eventos paralelos está creciendo, el número de contenedores está creciendo. El sistema escala automáticamente. Si los usuarios no acceden a la función, ésta quedará inactiva.
- El proveedor establece el tiempo de inactividad de los contenedores; si durante este tiempo las funciones no aparecen en el contenedor, se destruye.
De esta manera sacamos Serverless de fábrica. Pagaremos el servicio mediante el modelo de pago por uso y sólo por aquellas funciones que se utilicen, y sólo por el tiempo en que se utilizaron.
Para presentar el servicio a los desarrolladores, los proveedores ofrecen hasta 12 meses de pruebas gratuitas, pero limitan el tiempo total de cálculo, el número de solicitudes por mes, los fondos o el consumo de energía.
La principal ventaja de trabajar con un proveedor es la posibilidad de no preocuparse por la infraestructura (servidores, máquinas virtuales, contenedores). Por su parte, el proveedor puede implementar FaaS tanto utilizando desarrollos propios como utilizando herramientas de código abierto. Hablemos más de ellos.
Desde el lado del código abierto
La comunidad de código abierto ha estado trabajando activamente en herramientas sin servidor durante los últimos años. Los mayores actores del mercado también contribuyen al desarrollo de plataformas sin servidor:
- Google ofrece a los desarrolladores su herramienta de código abierto - . En su desarrollo participaron IBM, RedHat, Pivotal y SAP;
- IBM trabajó en una plataforma sin servidor , que luego se convirtió en un proyecto de la Fundación Apache;
- Microsoft abrió parcialmente el código de la plataforma .
También se están realizando avances en la dirección de frameworks sin servidor. и implementado dentro de clústeres de Kubernetes preparados previamente, Funciona tanto con Kubernetes como con Docker Swarm. El marco actúa como una especie de controlador: previa solicitud, prepara un entorno de ejecución dentro del clúster y luego lanza una función allí.
Los marcos dejan espacio para configurar la herramienta según sus necesidades. Entonces, en Kubeless, un desarrollador puede configurar el tiempo de espera de ejecución de la función (el valor predeterminado es 180 segundos). Fission, en un intento por solucionar el problema del arranque en frío, sugiere mantener algunos contenedores funcionando todo el tiempo (aunque esto conlleva costes de inactividad de los recursos). Y OpenFaaS ofrece un conjunto de activadores para todos los gustos y colores: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT y otros.
Las instrucciones para comenzar se pueden encontrar en la documentación oficial de los marcos. Trabajar con ellos requiere tener un poco más de habilidades que cuando se trabaja con un proveedor; esta es al menos la capacidad de iniciar un clúster de Kubernetes a través de la CLI. Como máximo, incluya otras herramientas de código abierto (por ejemplo, el administrador de colas Kafka).
Independientemente de cómo trabajemos con Serverless, a través de un proveedor o utilizando código abierto, obtendremos una serie de ventajas y desventajas del enfoque Serverless.
Desde el punto de vista de ventajas y desventajas.
Serverless desarrolla las ideas de una infraestructura de contenedores y un enfoque de microservicio, en el que los equipos pueden trabajar en modo multilingüe sin estar atados a una plataforma. La construcción de un sistema se simplifica y los errores son más fáciles de corregir. La arquitectura de microservicio le permite agregar nuevas funciones al sistema mucho más rápido que en el caso de una aplicación monolítica.
Serverless reduce aún más el tiempo de desarrollo, permitiendo al desarrollador centrarse únicamente en la lógica empresarial y la codificación de la aplicación. Como resultado, se reduce el tiempo de comercialización de los desarrollos.
Como beneficio adicional, obtenemos escalado automático de carga, y pagamos sólo por los recursos utilizados y sólo en el momento en que se utilizan.
Como cualquier tecnología, Serverless tiene desventajas.
Por ejemplo, una desventaja puede ser el tiempo de inicio en frío (en promedio hasta 1 segundo para lenguajes como JavaScript, Python, Go, Java, Ruby).
Por un lado, en realidad, el tiempo de inicio en frío depende de muchas variables: el idioma en el que está escrita la función, la cantidad de bibliotecas, la cantidad de código, la comunicación con recursos adicionales (las mismas bases de datos o servidores de autenticación). Dado que el desarrollador controla estas variables, puede reducir el tiempo de inicio. Pero, por otro lado, el desarrollador no puede controlar el tiempo de inicio del contenedor; todo depende del proveedor.
Un inicio en frío puede convertirse en un inicio en caliente cuando una función reutiliza un contenedor iniciado por un evento anterior. Esta situación se dará en tres casos:
- si los clientes utilizan con frecuencia el servicio y aumenta el número de llamadas a la función;
- si el proveedor, plataforma o marco le permite mantener algunos contenedores ejecutándose todo el tiempo;
- si el desarrollador ejecuta funciones con un temporizador (digamos cada 3 minutos).
Para muchas aplicaciones, un arranque en frío no es un problema. Aquí debe basarse en el tipo y las tareas del servicio. Un retraso de inicio de un segundo no siempre es crítico para una aplicación empresarial, pero puede volverse crítico para los servicios médicos. En este caso, el enfoque sin servidor probablemente ya no sea adecuado.
La siguiente desventaja de Serverless es la corta vida útil de una función (tiempo de espera durante el cual se debe ejecutar la función).
Pero, si tiene que trabajar con tareas de larga duración, puede utilizar una arquitectura híbrida: combine Serverless con otra tecnología.
No todos los sistemas podrán funcionar con el esquema Serverless.
Algunas aplicaciones seguirán almacenando datos y estados durante la ejecución. Algunas arquitecturas seguirán siendo monolíticas y algunas características durarán mucho tiempo. Sin embargo (al igual que las tecnologías en la nube y luego los contenedores), Serverless es una tecnología con un gran futuro.
En este sentido, me gustaría pasar sin problemas a la cuestión del uso del enfoque sin servidor.
Desde el lado de la aplicación
Para 2018, el porcentaje de uso sin servidor . Entre las empresas que ya han implementado la tecnología en sus servicios se encuentran gigantes del mercado como Twitter, PayPal, Netflix, T-Mobile y Coca-Cola. Al mismo tiempo, debe comprender que Serverless no es una panacea, sino una herramienta para resolver una determinada variedad de problemas:
- Reducir el tiempo de inactividad de los recursos. No es necesario mantener constantemente una máquina virtual para servicios que tienen pocas llamadas.
- Procese datos sobre la marcha. Comprima imágenes, recorte fondos, cambie la codificación de video, trabaje con sensores de IoT, realice operaciones matemáticas.
- “Pegue” otros servicios. Repositorio Git con programas internos, chat bot en Slack con Jira y calendario.
- Equilibra la carga. Echemos un vistazo más de cerca aquí.
Digamos que hay un servicio que atrae a 50 personas. Debajo hay una máquina virtual con hardware débil. De vez en cuando, la carga del servicio aumenta significativamente. Entonces el hardware débil no puede hacer frente.
Puede incluir un equilibrador en el sistema que distribuirá la carga, por ejemplo, entre tres máquinas virtuales. En esta etapa, no podemos predecir con precisión la carga, por lo que mantenemos una cierta cantidad de recursos funcionando "en reserva". Y pagamos de más por el tiempo de inactividad.
En tal situación, podemos optimizar el sistema mediante un enfoque híbrido: dejamos una máquina virtual detrás del equilibrador de carga y colocamos un enlace al Serverless Endpoint con funciones. Si la carga excede el umbral, el equilibrador lanza instancias de función que se hacen cargo de parte del procesamiento de la solicitud.
Por lo tanto, Serverless se puede utilizar cuando sea necesario procesar una gran cantidad de solicitudes no con demasiada frecuencia, pero sí de manera intensiva. En este caso, ejecutar varias funciones durante 15 minutos es más rentable que mantener una máquina virtual o un servidor todo el tiempo.
Con todas las ventajas de la informática sin servidor, antes de la implementación, primero debe evaluar la lógica de la aplicación y comprender qué problemas puede resolver Serverless en un caso particular.
Sin servidor y selectel
En Selectel ya estamos a través de nuestro panel de control. Ahora estamos construyendo nuestra propia plataforma FaaS. Queremos que los desarrolladores puedan resolver sus problemas utilizando Serverless a través de una interfaz cómoda y flexible.
Si tiene ideas sobre cuál debería ser la plataforma FaaS ideal y cómo desea utilizar Serverless en sus proyectos, compártalas en los comentarios. Tendremos en cuenta sus deseos al desarrollar la plataforma.
Materiales utilizados en el artículo:
Fuente: habr.com