Aunque todavía le queda un duro camino a recorrer, Serverless Computing acabará definiendo la forma en que las organizaciones desarrollan, despliegan e integran sus aplicaciones. Este paradigma presenta numerosas ventajas para las organizaciones al proporcionar un modelo de programación simplificado para crear aplicaciones en la nube abstrayendo la mayoría de las preocupaciones operativas.

Offering Serverless

Los principales proveedores de la nube ya tienen ofertas sobre este modelo. Además de las ofertas de Amazon Web Service y Microsoft Azure, la computación Serverless es un mercado incipiente pero prometedor para todos los proveedores de computación en la nube.

Amazon sigue siendo líder liderazgo en esta computación capturando más del 80% de la cuota de mercado en 2020, Microsoft en segundo lugar captura un 16%…

Serverless resuelve varios de los problemas de los modelos Cloud tradicionales

Al usar servicios de backend Serverless el proveedor del servicio facturará en función de su consumo de computación y no será necesario reservar y pagar por una cantidad fija de ancho de banda o número de servidores, ya que el servicio se autoescala con la demanda entrante.

Algunos aún nos acordamos cuando para ejecutar un proyecto era necesario comprar o alquilar las máquinas para ejecutar las aplicaciones, y luego había que encargarse de la operación de estas máquinas, de la red…la computación Cloud y la virtualización simplificaron todo este proceso muchísimo pero se mantenía el problema de que era necesario tener la infra necesaria para cubrir los picos de tráfico y trabajo y se desperdiciaba toda esa capacidad de proceso. Los proveedores Cloud introdujeron modelos de autoescalado para mitigar el problema, aunque este proceso era a veces caro, a veces complejo, a veces lento.

La tecnología Serverless aborda la mayoría de estas limitaciones.

¿POR QUÉ USAR SERVERLESS?

• No más gestión de servidores: Aunque la computación "Serverless" se hace en los servidores, los desarrolladores no tienen que preocuparse por su existencia en el momento del despliegue de la aplicación. Su proveedor lo gestiona en su nombre, lo que disminuye la inversión requerida en DevOps y el tiempo que los desarrolladores se toman para construir y ampliar sus aplicaciones. Las aplicaciones ya no estarían limitadas por la capacidad del servidor o la potencia de cálculo.
• Backend de pago por uso: Al igual que con un plan de datos de "pago por uso" en el que sólo se factura por la cantidad de datos consumidos, en la computación sin servidor, sólo se factura cuando se ejecuta el código de la aplicación. El código de la aplicación sólo se ejecuta cuando las funciones del backend se ejecutan en respuesta a un evento. El código se autoescala según la demanda y el aprovisionamiento sigue siendo dinámico, preciso e instantáneo.
• Computación Serverless = Escalabilidad: Las aplicaciones sin servidor aumentan y reducen su tamaño según la demanda actual. La computación sin servidor permite a las aplicaciones pasar de cientos de instancias de computación a una sola y viceversa en cuestión de segundos para adaptarse a curvas de demanda complejas. Los proveedores de la computación sin servidor emplean algoritmos para iniciar, ejecutar y finalizar esas instancias según sea necesario utilizando contenedores. En consecuencia, las aplicaciones sin servidor pueden manejar millones de solicitudes concurrentes o una sola solicitud con el mismo rendimiento.
• Despliegues y actualizaciones más rápidas: La infraestructura sin servidor no necesita complicadas configuraciones de backend para que una aplicación funcione. Una aplicación Serverless es una colección de funciones gestionadas por el proveedor en lugar de un gran bloque monolítico inmanejable de código. A la hora de lanzar actualizaciones, parches y correcciones, los desarrolladores sólo tienen que alterar las funciones afectadas. Asimismo, se pueden añadir nuevas funciones para reflejar una nueva característica de la aplicación.
• Las localizaciones reducen la latencia: Las aplicaciones Serverless no se alojan en el servidor de origen, sino en varias ubicaciones de la infraestructura del proveedor. En respuesta a la demanda, la ubicación más cercana activa el evento y la función, esto reduce la latencia porque ahora las solicitudes no tienen que ir hasta un servidor de origen.
• La computación sin servidor debería reducir el coste para la mayoría de los casos de uso: Las arquitecturas Serverless son más eficientes para reducir los costes de las aplicaciones con un uso desigual. Si la aplicación alterna periodos de gran actividad con instancias de poco o ningún tráfico, el alquiler de espacio en el servidor por un periodo de tiempo fijo no tendrá sentido. Pagar por un espacio de servidor disponible y siempre en funcionamiento no es rentable cuando sólo se va a utilizar durante una fracción del periodo de alquiler.

DESVENTAJAS DE MODELO SERVERLESS

Como sucede con el modelo de microservicios, la computación Serverless no es adecuada para todos los casos de uso y aparecen otras complejidades.

• Cargas de trabajo prolongadas: si tus aplicaciones necesitan ejecutar cargas de trabajo prolongadas como la transcodificación de vídeo, la compresión de imágenes, el vídeo bajo demanda, entrenamiento de modelos,… Estos trabajos por lotes significan que las aplicaciones estarían funcionando la mayor parte del tiempo y la computación sin servidor no será práctica y su coste será mayor en el proveedor Cloud que provisionando infraestructura.
• Dependencia de la red: construir una aplicación sobre una Arquitectura Serverless implicará en muchas ocasiones flujos de eventos que llaman a funciones que se comunican exclusivamente a través de protocolos de red estándar, lo que significa que un corte de red o una interrupción de cualquier tipo (a menudo fuera del control) interferirá con las operaciones de negocio. Y, a medida que aumenta el número de funciones desplegados, también lo hace el riesgo de una interrupción de la red, poniendo en peligro uno de estos servicios.
• Latencia: Por otro lado, la red también implica que se introduce latencia en el sistema, y eso hay que tenerlo en cuenta.
• Sobrecarga: Con una Arquitectura Serverless, se divide un producto en una constelación de funciones más pequeñas. Como resultado, hay una sobrecarga que se crea en la gestión de estas funciones, que es un motivo por el que muchas organizaciones no están preparadas para adoptar plenamente los microservicios y menos las funciones.
• Dependencias: Imagina cientos de componentes de aplicaciones que dependen de una función con un contrato establecido (especificación de la API). Y ahora imagine que el equipo de microservicios quiere rediseñar (o incluso modificar ligeramente) su especificación. La organización no sólo debe coordinar este cambio entre equipos, sino que también debe hacer un seguimiento de quién depende de quién en todo momento.
• Contratos estrictos: Hablando más del punto anterior, los desarrolladores deben tener cuidado de definir una especificación de API de la función lo suficientemente robusta como para proporcionar valor de negocio mucho después del lanzamiento inicial. Este tipo de previsión es poco frecuente, si no imposible en algunas organizaciones.
• Orquestación: en muchos escenarios será necesario orquestar diversas funciones para componer un servicio de negocio. Cada proveedor ha optado por una solución para esto.
• Transaccionalidad: el proceso de negocio que orqueste las funciones tendrá que gestionar las compensaciones antes un problema en la ejecución de una función.
• Demasiado fácil crear una función : Este es un escenario de fortaleza y también de debilidad. La capacidad de desplegar e incorporar funciones de forma tan sencilla puede llevar a un exceso de funciones.