Cuando se trata de compilar aplicaciones, los desarrolladores suelen tener una serie de otras tareas de administración de servidores que deben realizar a fin de implementar su código, como definir recursos para el procesamiento y el almacenamiento, la aplicación de parches, el balanceo de cargas y más. Todos estos elementos adicionales generan tiempos de aprovisionamiento más largos y una sobrecarga operativa adicional que, en última instancia, ralentiza los equipos de desarrollo. 

La computación sin servidores intenta proporcionar una experiencia invisible “sin servidores” a los desarrolladores, lo que elimina la necesidad de pensar en los servidores o en algo que una aplicación podría necesitar para ejecutarse. En cambio, el proveedor de servicios hace todo el trabajo en segundo plano a fin de garantizar que tengas los recursos para ejecutar tu código y cumplir con los requisitos sin que se te cobre por la capacidad inactiva. 

Piensa en el modelo sin servidores como llevar agua a tu casa. Podrías excavar bien, probar la calidad del agua e instalar y mantener todas las tuberías externas necesarias para llevarla a la casa. También puedes conectarte a la red principal de agua de tu ciudad. Solo debes abrir la llave y obtener la cantidad que quieras exactamente cuando la necesites, y la ciudad te enviará una factura mensual por la cantidad exacta de agua que consumas. 

Del mismo modo, los proveedores de servicios en la nube inician automáticamente los recursos de infraestructura y los entornos de ejecución necesarios para ejecutar tus apps sin servidores y reducir la escala verticalmente a cero automáticamente cuando se complete la ejecución. Por lo general, se te cobrará en función de los recursos durante el tiempo de ejecución. Sin embargo, esto puede variar según el servicio y el proveedor. 

Pero espera, ¿no hay otros tipos de computación en la nube que proporcionan recursos a pedido y con modalidad de pago por uso? Es cierto que los modelos de servicio en la nube, por ejemplo, infraestructura como servicio (IaaS) y plataforma como servicio (PaaS) también proporcionan acceso según demanda a los recursos de procesamiento. 

Sin embargo, la infraestructura de nube que se te asignó permanece activa incluso si no la estás usando. También es tu responsabilidad escalar la capacidad del servidor o configurar tus aplicaciones para escalar verticalmente o reducir la escala en respuesta a la demanda del usuario. 

Las arquitecturas sin servidores se basan en eventos. Con este modelo, el proveedor solo te brinda recursos cuando un evento activa la ejecución de tu código y escalará instantáneamente y automáticamente a las solicitudes.

Una de las mayores desventajas de la computación sin servidores es que sigue siendo una tecnología relativamente nueva. Como resultado, aún no es adecuado para todos los casos de uso posibles. 

También está claro que algunas de las debilidades actuales que existen se resolverán con el tiempo a medida que la computación sin servidores continúe evolucionando. En particular, ya se está trabajando en implementaciones de código abierto de servidores sin servidores y en la búsqueda de formas de hacer que los servicios en la nube sean más abiertos a fin de que las soluciones sean portátiles entre diferentes plataformas y entornos. 

• Adecuación limitada para casos de uso: Las arquitecturas sin servidores no siempre son adecuadas para aplicaciones con requisitos específicos, como procesos de larga duración o necesidades de latencia muy baja.
• Restricciones de rendimiento: Las funciones sin servidores pueden experimentar inicios en frío (ejecución inicial retrasada) y pueden tener limitaciones en el tiempo de ejecución y la memoria.
• Dependencia de un solo proveedor: Migrar aplicaciones sin servidores entre proveedores de servicios en la nube puede ser complejo debido a las diferencias en las APIs y configuraciones.
• Visibilidad reducida del servidor: Los desarrolladores tienen una visibilidad limitada de la infraestructura subyacente, lo que dificulta solucionar problemas de rendimiento o la optimización de la utilización de recursos.
• Inicio lento: Las funciones sin servidores a veces pueden experimentar un “inicio en frío” en el que hay un retraso en la invocación de la función, lo que puede afectar la latencia.