Después de los microservicios, la próxima revolución en la arquitectura de software es el Serverless. Ya hay muchas publicaciones de blog excelentes sobre este tema y algunas las mencionamos al final. Sin embargo, en Orion te damos algunas de nuestras impresiones.
Algo de historia
Como sabemos, los servidores son solo otras computadoras. Al igual que las computadoras de escritorio, tienen el procesador, la memoria RAM, fijos en la placa base, la cual necesita energía. Es posible que no tengan un teclado o un monitor, sino que se pueden controlar de forma remota. Estas máquinas de servidores físicos normalmente tendrán una configuración de hardware alta que no es necesaria para las cargas de trabajo normales. Por lo tanto, sus recursos se comparten alojando varias máquinas pequeñas en su interior, las cuales llamamos máquinas virtuales (VM). Otra razón para las máquinas virtuales es que podemos administrarlas fácilmente por software. Por ejemplo, podemos eliminar una VM de Windows y crear una VM de Linux completa a través del software de administración de máquinas virtuales. Además, podemos ajustar fácilmente la memoria RAM, el disco duro, etc. de la máquina virtual.
En un centro de datos interno tradicional, nosotros, como equipo de infraestructura/ingeniería de operaciones, debemos asegurarnos de que haya suficientes servidores físicos que puedan responder a las necesidades dinámicas de las máquinas virtuales de diferentes aplicaciones. En un momento dado, la mayoría de las máquinas estarán infrautilizadas, considerando su capacidad. Desde la perspectiva del desarrollador de software, deben asegurarse de que estas máquinas tengan el software adecuado instalado y tuvieron que escalar hacia arriba, hacia abajo o hacia afuera, según el uso. El entorno de nube de la generación anterior, es decir, IaaS, resuelve fácilmente este problema de aprovisionamiento de máquinas. Aunque el equipo de operaciones de infraestructura estaba contento con IaaS, el lado del software de aplicación no lo estaba porque sus funciones no se redujeron. Es por eso que la nube ha seguido evolucionando hacia niveles más abstractos, como PaaS, SaaS, etc. En cada nivel superior, se agrega más abstracción y el desarrollador debe pasar del hardware a concentrarse en el aspecto del software del sistema.
Entra a PaaS
En PaaS, los desarrolladores no necesitan preocuparse por la plataforma y escalar es menos doloroso que en IaaS. Usando un control deslizante o un comando, pueden controlar la escala. Algunos proveedores de la nube proporcionan un escalado automático en este nivel, pero los desarrolladores tuvieron que escribir código para determinar cuándo escalar. Esto realmente resuelve cualquier problema que pueda surgir cuando el software se va a implementar como un paquete que realiza una tarea relacionada. ej: un sitio web o APIs expuestas vía web.
En PaaS, dado que la unidad de implementación es el paquete, la escala se aplica a todas las tareas en él, independientemente del uso de la tarea individual. Por ejemplo: tenemos 10 API en una implementación de WebAPI y solo 5 tienen mucho tráfico. Pero cuando escalamos, se escala toda la implementación de WebAPI.
FaaS (Función como servicio)
Vimos que escalar era un punto débil en PaaS. Una forma de escalar individualmente cada tarea es dividir el paquete de implementación a nivel de tarea para que cada paquete de implementación tenga solo un trabajo/tarea. Esto es algo que Microservices trató de lograr. Dividir la aplicación tanto como sea posible.
Esto todavía necesita monitoreo. Alguien tiene que monitorear y ajustar la escala según el uso. Los desarrolladores perezosos también quieren salir de eso y entrar a FaaS. Aquí, cada función se convierte en una unidad de despliegue. En lo que respecta a FaaS, los proveedores de la nube pudieron proporcionar un escalado automático real. El desarrollador no necesita monitorear nada. El proveedor lo hace.
¿Qué es Serverless?
Si examinamos la PaaS, los proveedores de la nube comenzaron a administrar el servidor. Solo se tiene que dar un paquete de implementación y el proveedor se encarga del resto. Pero hay vigilancia. Cuando se trataba de FaaS, los proveedores de la nube comenzaron a tomar la propiedad total de los servidores, pero esos no fueron solo los factores para el surgimiento de Serverless.
Ejecución gratuita del lado del servidor de alto rendimiento
Además de quitarles el hardware a los desarrolladores, muchos proveedores de la nube comenzaron a ofrecer niveles gratuitos. Dado que es por función, el costo de iniciar un negocio basado en la nube se volvió mucho menor, en este punto casi 0, por lo que, obviamente, las nuevas empresas lo seleccionaron para probar sus ideas en este modelo sin mucha inversión. Podrían comercializar cosas muy rápido e incluso si falla, pudieron administrar la pérdida financiera. Anteriormente, había muy pocas opciones para obtener la ejecución gratuita del código del lado del servidor de grado industrial.
Alojamiento HTML de grado industrial gratuito
Otro impulso es la disponibilidad de proveedores de alojamiento web HTML gratuitos. Aunque estuvieron presentes desde el principio, no estaban preparados para albergar sitios de alto tráfico. Pero ese no fue el caso con las páginas de git, el alojamiento de amazon S3. Ahora, con un costo de alojamiento de $0, cualquiera puede iniciar un negocio en línea. Lo único que necesitan saber es cómo hacer la codificación básica de HTML+JS y las habilidades de integración. La habilidad de integración no es más que llamar a las API del lado del servidor gratuitas mencionadas anteriormente a través de XmlHttpRequest o simplemente AJAX.
SaaS Freemium
Otro beneficio que surgió en la situación es la disponibilidad de muchos servicios freemium para realizar inquietudes transversales o capacidades compartidas. Si queremos proporcionar integración de inicio de sesión con Google, Facebook, etc., ahora está disponible en cuestión de horas.
Éxito de la web estandarizada y disponibilidad de Internet móvil y de alta velocidad
Estas son algunas cosas positivas adicionales que sucedieron que impulsan la evolución de Serverless. Si los diferentes navegadores se comportaran de manera diferente, jQuery y AngularJS no se hubieran inventado; Internet estaba dando acceso telefónico, es posible que la palabra sin servidor no se haya escuchado. En general, la comunidad de startups lo encontró rentable y, dado que son los impulsores de la innovación y las conferencias, Serverless se convirtió en la próxima palabra de moda. Obviamente con el apoyo de los verdaderos gigantes o los proveedores de la nube. Muy pronto las empresas también seguirán el mismo camino.
¿Realmente no hay servidores?
El término es un poco confuso. Hay servidores pero completamente administrados por el proveedor de la nube o el proveedor de SaaS. Sin servidor, es decir, algunas computadoras de gama alta o hardware en general, no podemos ejecutar nuestros softwares basados en la web, excepto de igual a igual, como torrents.
Estoy usando FaaS. ¿Estoy en Serverless?
Tenemos que entender primero que las aplicaciones web tienen 2 fines. Uno es el front-end que se ejecuta en el navegador, servido desde un servidor web. El otro es el back-end, donde viven los datos y se realiza el cálculo. Back-end podemos dividirlo nuevamente en capa de computación (capa comercial) y capa de datos. El uso de FaaS garantiza que nuestro cálculo no tenga servidor. Pero, ¿qué pasa con la capa de datos y el front-end? Si el front-end se sirve desde un centro de datos interno o desde una máquina virtual IaaS, no podemos decir que la aplicación no tiene servidor. Esto también es aplicable a bases de datos o archivos en la capa de datos. Entonces, si no nos preocupamos en absoluto por ningún servidor, podemos decir que nuestra aplicación es Serverless.
Serverless es un patrón de arquitectura y no significa que sea gratuito. Pero si elegimos esta arquitectura, podemos tener la aplicación en funcionamiento sin tarifas de alojamiento. El costo de desarrollo siempre está ahí. La mayoría de las personas comienzan en el nivel gratuito y se actualizan a pago una vez que tienen éxito. Ese movimiento no suele implicar ningún cambio de código.
¿Serverless requiere un diseño de arco inicial?
Serverless proporciona una gran flexibilidad para el desarrollo similar a los Microservicios. Podemos elegir varios idiomas que se adapten al servicio/función. Se puede deshacer fácilmente de la deuda técnica reescribiendo funciones activas. La arquitectura se puede cambiar fácilmente ya que solo se encuentra en el nivel de integración.
Pero eso exige una buena visión arquitectónica de la integración. De lo contrario, las funciones no trabajarán juntas para producir el comportamiento deseado.
¿Habrá un desastre de funciones?
Sí, si la gestión y el seguimiento de las funciones no se realizan correctamente. Si permitimos que cada Tim y Harry comiencen a escribir funciones sin un mecanismo de monitoreo, pronto terminaremos en tantas funciones en el entorno de producción que nadie sabrá por qué existen.
¿El arco sin servidor requiere canalización de CI, CD?
Aunque arquitectónicamente no es necesario, se recomienda configurar una canalización de CI y CD adecuada para aprovechar este modelo. Esto también es aplicable en Microservicios para evitar esfuerzos de integración innecesarios.
¿Debería cambiar a Serverless mañana?
Cuando se anunció la nube, muchas industrias no estaban listas para aceptar y la preocupación era la seguridad. Pero ahora podemos ver que las opiniones cambian. Incluso los bancos están tratando de usar la nube tanto como pueden. No hay duda de que Serverless será el futuro similar a como lo están haciendo los microservicios ahora.
Como siempre, antes de convertir nuestra aplicación existente o iniciar la siguiente aplicación usando Serverless, tenemos que comparar los pros y los contras.
La siguiente comparación asume que Serverless usa FaaS junto con SaaS. Entonces, algunos factores pueden parecer adecuados para FaaS o SaaS.
Ventajas
- Responsabilidad única a nivel de función: esto es algo que estábamos tratando de lograr desde el comienzo del desarrollo de software, pero como estaba a merced de los desarrolladores, lograrlo fue muy difícil. Con Serverless, la arquitectura impone la responsabilidad.
- Costo: en teoría, debería ser menor, ya que solo pagamos por lo que usamos. Pero este factor cambiará con más informes de uso de alto volumen en tiempo real.
- Escalar la codificación: la codificación se puede escalar de manera eficiente y realizarse incluso en el navegador. Idealmente, debería combinarse con un plan de integración de alto nivel adecuado.
- Facilidad de gestión de código: podemos deshacernos fácilmente de la deuda técnica reescribiendo funciones.
- Más selección de idiomas: podemos seleccionar diferentes idiomas para diferentes funciones similares a los microservicios. Pero esto es una espada de doble filo.
- Fácil cambio de proveedor: dado que la implementación es a nivel de función, podemos cambiar de proveedor gradualmente función por función.
Contras
- Muchos puntos de falla: dado que nuestra aplicación puede depender de muchos SaaS, si uno de ellos está inactivo, podría provocar el colapso de toda nuestra aplicación. De lo contrario, tenemos que utilizar mecanismos alternativos.
- No todos los SaaS están disponibles por igual en todo el mundo: si usamos Facebook como el único proveedor de inicio de sesión, las personas de países donde Facebook está prohibido no pueden usar nuestro software. Además, cualquier país o región puede bloquear cualquier cosa. Así que necesito monitorear el mundo.
- Rendimiento: el usuario final no necesita preocuparse de que la aplicación no tenga servidor y que el impacto en el rendimiento se deba al proveedor de la nube X SaaS o Y. Para ellos, el sitio/aplicación es una sola unidad y garantizar el rendimiento es el deber del desarrollador.
- Complejidad de integración: la complejidad comercial total de la aplicación no se puede cambiar, pero se puede mover. En Serverless, simplemente pasó del nivel de componente a un nivel de integración más alto.
- Rendimiento de llamadas encadenadas: si el negocio requiere una cadena de procesamiento compleja, puede afectar el rendimiento. Sería mejor ponerlos en cola.
- Desempeño de la activación de la instancia de servicio: tras un desencadenante, se espera que el tiempo de ejecución en la nube seleccione uno de los existentes o inicie un nuevo entorno de tiempo de ejecución para la función antes de la ejecución. El tiempo para configurar ese entorno afecta el rendimiento. Esto depende de la implementación del tiempo de ejecución de FaaS específico del proveedor.
- Menos control: si tenemos un escenario inevitable de servicio de larga duración, el proveedor puede eliminar nuestra instancia de servicio debido a los tiempos de espera. Aunque no es una desventaja a nivel de arquitectura, depende del proveedor.
- Falta de herramientas: esta es una desventaja temporal. Más herramientas, IDE y soluciones de prueba fuera de línea evolucionarán con el tiempo.
- El desarrollador olvida el hardware: esto puede verse tanto como una ventaja como una desventaja.
Serverless hace que los desarrolladores se alejen del hardware
Esto es discutible. Pero sea cual sea el debate que hagamos, una buena parte de los desarrolladores se están alejando del hardware. Pero, ¿empezó esto con Serverless? No.
El movimiento comenzó cuando se inventó el lenguaje ensamblador. En lugar de 1 y 0, la gente comenzó a usar Mov A, B o PUSH B, etc. Los compiladores lo llevaron más adelante. Más tarde, las plataformas administradas se incluyeron con máquinas virtuales. Todos esos estaban alejando a los desarrolladores de las máquinas bare metal.
La gran brecha de los desarrolladores
Pase lo que pase, hay un hardware que entiende 0s y 1s. ¿Quién controla la máquina? Obviamente, los escritores de compiladores y los codificadores de tiempos de ejecución. Todavía están con la máquina y requieren habilidades superiores a las de los desarrolladores de aplicaciones comerciales. Ahora podemos vincular a los desarrolladores de tiempo de ejecución en la nube en el mismo grupo. Esas habilidades no son reemplazables con IA. Pero el desarrollador de negocios tarde o temprano será reemplazado por IA. Otro grupo de desarrolladores que se unirá al sistema y a los creadores de la nube son los autores de algoritmos de IA. Ya existen sitios como Algorithmia que facilita Algorithms as a Service.
Esto es más como la evolución natural. Se necesita una cantidad considerable de tiempo para ver 2 especies de desarrolladores. Nuevamente, es un tema propio que se discutirá en una publicación separada y no estoy seguro de que el término «La gran división de desarrolladores» se adapte al fenómeno.