Sin servidor no se trata de la ausencia física de servidores. Esto no es un "asesino" de contenedores y no es 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 sin servidor, veremos qué papel juegan el proveedor de servicios sin servidor y los proyectos de código abierto. Al final, hablaremos de Serverless.
Quiero escribir el lado del servidor de la aplicación (sí, incluso una tienda en línea). Puede ser un chat, un servicio para publicar contenido o un equilibrador de carga. En cualquier caso, habrá muchos dolores de cabeza: tendrá que preparar la infraestructura, determinar las dependencias de la aplicación y pensar en el sistema operativo host. Luego, debe actualizar los componentes pequeños que no afectan el trabajo del resto del monolito. Bueno, no nos olvidemos de escalar bajo carga.
Pero, ¿qué pasa si tomamos contenedores efímeros en los que las dependencias requeridas ya están preinstaladas y los contenedores están aislados entre sí y del sistema operativo host? Dividiremos el monolito en microservicios, cada uno de los cuales se puede actualizar y escalar independientemente de los demás. Después de haber colocado el código en dicho contenedor, puedo ejecutarlo en cualquier infraestructura. Ya mejor.
¿Y si no quieres configurar contenedores? No quiero pensar en escalar la aplicación. No quiero pagar por contenedores inactivos cuando la carga en el servicio es mínima. Quiero escribir codigo Concéntrese en la lógica empresarial y los productos de mercado a la velocidad de la luz.
Tales pensamientos me llevaron a la informática sin servidor. Sin servidor en este caso
no significa la
ausencia física de servidores, sino la ausencia de un dolor de cabeza para administrar la infraestructura.La idea es que la lógica de la aplicación se descomponga en funciones independientes. Tienen una estructura de eventos. Cada una de las funciones realiza una "microtask". 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 del evento. El código se ejecutará a pedido en un contenedor preparado automáticamente, y pagaré solo por el tiempo de ejecución.
Veamos cómo se verá el proceso de desarrollo de aplicaciones.
Del desarrollador
Anteriormente, comenzamos a hablar sobre la aplicación para la tienda en línea. En el enfoque tradicional, la lógica principal del sistema se realiza mediante una aplicación monolítica. Y el servidor con la aplicación se ejecuta constantemente, incluso si no hay carga.
Para cambiar a serverless, dividimos la aplicación en microtasks. Debajo de cada uno de ellos escribimos nuestra propia función. Las funciones son independientes entre sí y no almacenan información de estado. Incluso se pueden escribir en diferentes idiomas. Si uno de ellos falla, la aplicación completa no se detendrá. La arquitectura de la aplicación se verá así:
La división en funciones en Serverless es similar al trabajo con microservicios. Pero un microservicio puede realizar varias tareas, e idealmente, una función debe realizar una. Imagine que la tarea es recopilar estadísticas y mostrarlas a petición del usuario. En el enfoque de microservicio, la tarea la realiza un servicio con dos puntos de entrada: escribir y leer. En la informática sin servidor, estas serán dos funciones diferentes que no están interconectadas. Un desarrollador ahorra recursos informáticos si, por ejemplo, las estadísticas se actualizan con más frecuencia que las descargadas.
Las funciones sin servidor deben ejecutarse en un corto período de tiempo (tiempo de espera), que es determinado por 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 (de larga duración) tendrán que cambiarse para cumplir con los requisitos: este servidor sin servidor difiere de otras tecnologías populares hoy en día (contenedores y plataforma como servicio).
Asignamos un evento a cada función. Un evento es un desencadenante de una acción:
Los eventos pueden ser solicitudes HTTP, transmisión de datos, colas de mensajes, etc. Las fuentes de eventos son el cambio o la apariencia de los datos. Además, las funciones se pueden ejecutar por temporizador.
La arquitectura funcionó y la aplicación casi se quedó sin servidor. A continuación vamos al proveedor de servicios.
Del proveedor
La informática sin servidor generalmente es ofrecida por proveedores de servicios en la nube. Lo 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,
- Descargue el archivo con el código,
- trabajar con repositorios git públicos o privados.
Aquí configuramos los eventos que llaman a la función. Diferentes proveedores pueden tener diferentes conjuntos de eventos.
El proveedor en su infraestructura ha construido y automatizado el sistema de Función como Servicio (FaaS):
- El código de función llega al repositorio en el lado del proveedor.
- Cuando ocurre un evento, los contenedores con el 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, calculada, devuelve el resultado.
- La cantidad de eventos paralelos está creciendo, la cantidad de contenedores está creciendo. El sistema se escala automáticamente. Si los usuarios no acceden a la función, estará inactiva.
- El proveedor establece el tiempo de inactividad de los contenedores; si durante este tiempo las funciones no aparecen en el contenedor, se destruye.
Entonces sacamos Serverless de la caja. Pagaremos el servicio de acuerdo con el modelo de pago por uso y solo por las funciones que se usan, y solo por el tiempo en que se usaron.
Para presentar el servicio a los desarrolladores, los proveedores ofrecen hasta 12 meses de pruebas gratuitas, pero limitan el tiempo total de cálculo, la cantidad de solicitudes por mes, el dinero o el consumo de energía.
La principal ventaja de trabajar con un proveedor es la capacidad de no preocuparse por la infraestructura (servidores, máquinas virtuales, contenedores). Por su parte, el proveedor puede implementar FaaS tanto en sus propios desarrollos como en el uso de herramientas de código abierto. Hablaremos más sobre ellos.
De código abierto
En los últimos años, la comunidad de código abierto ha estado trabajando activamente en herramientas sin servidor. En particular, los principales actores del mercado contribuyen al desarrollo de plataformas sin servidor:
- Google ofrece a los desarrolladores su herramienta de código abierto: Knative . Su desarrollo involucró a IBM, RedHat, Pivotal y SAP;
- IBM trabajó en la plataforma OpenWhisk Serverless, que luego se convirtió en el proyecto de la Fundación Apache;
- Microsoft abrió parcialmente el código de la plataforma Azure Functions .
También se están llevando a cabo desarrollos en la dirección de marcos sin servidor.
Kubeless y
Fission se implementan en grupos de Kubernetes preparados previamente,
OpenFaaS trabaja con Kubernetes y Docker Swarm. El marco actúa como una especie de controlador: a pedido, prepara el tiempo de ejecución dentro del clúster y luego ejecuta una función allí.
Los marcos dejan espacio para la configuración de herramientas para satisfacer sus necesidades. Entonces, en Kubeless, el desarrollador puede establecer el tiempo de espera para que se ejecute la función (el valor predeterminado es 180 segundos). La fisión en un intento por resolver el problema del arranque en frío ofrece mantener parte de los contenedores en funcionamiento todo el tiempo (aunque esto conlleva el costo del tiempo de inactividad). Y OpenFaaS ofrece un conjunto de disparadores 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 implica un poco más de habilidades que trabajar con un proveedor: esta es al menos la capacidad de iniciar un clúster de Kubernetes a través de la CLI. Máximo, incluya otras herramientas de código abierto (por ejemplo, el gestor de colas de Kafka).
Independientemente de cómo trabajemos con Serverless: a través de un proveedor o usando código abierto, obtenemos una serie de ventajas y desventajas del enfoque Serverless.
Desde la perspectiva de las ventajas y desventajas.
Serverless desarrolla las ideas de infraestructura de contenedor y enfoque de microservicio, en el que los equipos pueden trabajar en modo multilingüe, sin estar vinculados a una plataforma. La construcción de un sistema se simplifica y la corrección de errores se vuelve más fácil. 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.
Sin servidor reduce aún más el tiempo de desarrollo al permitir que el desarrollador se centre únicamente en la lógica y la codificación empresarial de la aplicación. Como resultado, se reduce el tiempo de comercialización para el desarrollo.
Como beneficio
adicional, obtenemos escala automática a la carga, y pagamos solo por los recursos utilizados y solo en el momento en que se utilizan.
Como cualquier tecnología, Serverless tiene desventajas.
Por ejemplo, tal inconveniente podría ser un tiempo de inicio en frío (hasta 1 segundo en promedio para lenguajes como JavaScript, Python, Go, Java, Ruby).Por un lado, de hecho, el tiempo de un arranque en frío depende de muchas variables: el idioma en el que se escribe 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). Debido a que el desarrollador controla estas variables, puede acortar el tiempo de inicio. Pero, por otro lado, el desarrollador no puede controlar el tiempo de lanzamiento del contenedor; todo depende del proveedor.
Un arranque en frío puede convertirse en uno caliente cuando la función reutiliza el contenedor lanzado por el evento anterior. Esta situación ocurrirá en tres casos:
- si los clientes a menudo usan el servicio y el número de llamadas a la función está creciendo;
- si el proveedor, la plataforma o el marco le permiten mantener parte de los contenedores ejecutándose todo el tiempo;
- si el desarrollador ejecuta funciones de temporizador (por ejemplo, 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 inicio retrasado por un segundo no siempre es crítico para una aplicación comercial, pero puede volverse crítico para los servicios médicos. Probablemente, en este caso, el enfoque sin servidor ya no será adecuado.
El siguiente inconveniente de Serverless es la corta vida útil de la función (el tiempo de espera para el que debe ejecutarse la función).Pero, si tiene que trabajar con tareas de larga duración, puede usar una arquitectura híbrida: combine Serverless con otra tecnología.
No todos los sistemas podrán funcionar de acuerdo con el esquema sin servidor.Algunas aplicaciones aún almacenarán datos y estado en tiempo de ejecución. Algunas arquitecturas seguirán siendo monolíticas, y algunas funciones serán de larga duración. Sin embargo (como solían ser 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 al tema de la aplicación del enfoque sin servidor.
En el lado de la aplicación
En 2018, el porcentaje de uso sin servidor
aumentó una vez y media . Entre las compañías que ya han implementado la tecnología en sus servicios, hay gigantes del mercado como Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Al mismo tiempo, debe comprender que Serverless no es una panacea, sino una herramienta para resolver un cierto rango de tareas:
- Reduzca los recursos de tiempo de inactividad. No es necesario mantener constantemente la máquina virtual bajo servicios a los que no se accede mucho.
- El proceso "al vuelo" procesa los datos. Comprima imágenes, recorte el fondo, cambie la codificación de video, trabaje con sensores IoT, realice operaciones matemáticas.
- Pegue otros servicios. Repositorio de Git con programas internos, chat bot en Slack con Jira y con un calendario.
- Balancear la carga. Aquí nos detenemos con más detalle.
Digamos que hay un servicio al que acuden 50 personas. Debajo hay una máquina virtual con hardware débil. Periódicamente, la carga en el servicio aumenta significativamente. Entonces el hierro débil no puede hacer frente.
Puede incluir un equilibrador en el sistema que distribuirá la carga, por ejemplo, a tres máquinas virtuales. En esta etapa, no podemos predecir con precisión la carga, por lo que mantenemos una cierta cantidad de recursos ejecutándose "en reserva". Y pagar de más por el tiempo de inactividad.
En esta situación, podemos optimizar el sistema a través de un enfoque híbrido: para el equilibrador de carga, dejamos una máquina virtual y ponemos un enlace a Serverless Endpoint con funciones. Si la carga excede el umbral, el equilibrador inicia instancias de funciones que toman parte del procesamiento de la solicitud.
Por lo tanto, Serverless se puede usar donde no es muy frecuente, pero para procesar una gran cantidad de solicitudes 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, lo primero que debe hacer antes de implementarla es evaluar la lógica de la aplicación y comprender qué tareas Serverless puede resolver en un caso particular.
Sin servidor y Selectel
En Selectel, ya hemos
hecho que trabajar con Kubernetes en una
nube privada virtual sea más fácil a través de nuestro panel de control. Ahora estamos construyendo nuestra propia plataforma FaaS. Queremos que los desarrolladores puedan resolver sus problemas con Serverless a través de una interfaz conveniente y flexible.
¿Quiere seguir el proceso de desarrollo de la nueva plataforma FaaS? Suscríbase al boletín de Selectel "Funciones de la nube"
en la página de servicio . Hablaremos sobre el proceso de desarrollo y anunciaremos el lanzamiento cerrado de Cloud Functions.
Si tiene alguna idea de cuál debería ser una plataforma FaaS ideal y cómo desea utilizar Serverless en sus proyectos, compártala en los comentarios. Tendremos en cuenta sus deseos al desarrollar la plataforma.
Materiales utilizados en el artículo: