La informática sin servidor ofrece una serie de ventajas a los desarrolladores web, como escalabilidad, rapidez de comercialización y menos gastos. Sin embargo, en algunos casos estas ventajas pueden verse superadas por otras preocupaciones.
Después de leer este artículo podrás:
Contenido relacionado
¿Qué significa el término sin servidor?
Informática sin servidor vs. contenedores
Informática sin servidor y Javascript
Edge computing
Función como servicio (FaaS)
Suscríbete a theNET, el resumen mensual de Cloudflare sobre las ideas más populares de Internet.
Copiar el enlace del artículo
La informática sin servidor ofrece una serie de ventajas en comparación con la infraestructura tradicional basada en la nube o centrada en el servidor. Para muchos desarrolladores, las arquitecturas sin servidor ofrecen mayor escalabilidad, más flexibilidad y se necesita menos tiempo para el lanzamiento, todo ello con un coste reducido. Con las arquitecturas sin servidor, los desarrolladores no tienen que preocuparse de comprar, aprovisionar y gestionar servidores backend. No obstante, la informática sin servidor no es una solución mágica para todos los desarrolladores de aplicaciones web.
La informática sin servidor es una arquitectura en la que un proveedor proporciona servicios de backend a medida que se van necesitando. Para más información sobre la informática sin servidor, consulta ¿Qué es la informática sin servidor?
Aunque la informática "sin servidor" tiene lugar en los servidores, los desarrolladores nunca tienen que ocuparse de los mismos. Los gestiona el proveedor. Esto puede reducir la inversión necesaria en DevOps, lo cual reduce los gastos, y también da la posibilidad a los desarrolladores de crear y ampliar sus aplicaciones sin estar limitados por la capacidad de los servidores.
Como en un plan de teléfono de "pago por uso", a los desarrolladores solo se les cobra por aquello que usan. El código solo se ejecuta cuando las funciones de backend son necesarias para la aplicación sin servidor, y el código escala automáticamente según se vea necesario. El aprovisionamiento es dinámico, preciso y en tiempo real. Algunos servicios son tan exactos que desglosan sus cargos en incrementos de 100 milisegundos. Por el contrario, en una arquitectura tradicional "de servidores", los desarrolladores tienen que prever de antemano la capacidad de servidor que van a necesitar, y luego comprar esa capacidad, independientemente de si la acaban utilizando o no.
Imaginemos que la oficina de correos pudiera añadir y retirar de servicio mágicamente camiones de reparto a voluntad, aumentando el tamaño de su flota cuando la cantidad de correo aumentara (por ejemplo, justo antes del Día de la Madre) y reduciéndola en los momentos en los que hay que hacer menos entregas. Eso es básicamente lo que pueden hacer las aplicaciones sin servidor.
Las aplicaciones desarrolladas con una infraestructura sin servidor escalarán automáticamente a medida que crezca la base de usuarios o aumente el uso. Si una función necesita ejecutarse en múltiples instancias, los servidores del proveedor las pondrán en marcha, las ejecutarán y las finalizarán según sea necesario, con frecuencia mediante el uso de contenedores. (La función se pondrá en marcha más rápido si se ha ejecutado recientemente, ver "El rendimiento puede verse afectado" más adelante). Como resultado, una aplicación sin servidor podrá manejar un número inusualmente alto de solicitudes igual de bien que una única solicitud de un solo usuario. Una aplicación tradicionalmente estructurada, con una cantidad fija de espacio en el servidor, se puede sobrecargar si se produce un aumento repentino del uso.
Con una infraestructura sin servidor, no hace falta subir código a los servidores ni realizar ninguna configuración de backend para poder lanzar una versión funcional de una aplicación. Los desarrolladores pueden subir trozos de código muy rápido y lanzar un nuevo producto. Pueden subir el código de una sola vez o una función cada vez, ya que la aplicación no es una sola pila monolítica, sino una colección de funciones suministradas por el proveedor.
Esto también permite actualizar, parchear, arreglar o añadir nuevas funciones a una aplicación con rapidez. No es necesario hacer cambios en toda la aplicación; en su lugar, los desarrolladores pueden actualizar la aplicación de función en función.
Como la aplicación no está alojada en un servidor de origen, su código se puede ejecutar desde cualquier sitio. Por tanto, en función del proveedor utilizado, es posible ejecutar las funciones de la aplicación en servidores que están cerca del usuario final. Esto reduce la latencia, porque las solicitudes del usuario ya no tienen que viajar hasta un servidor de origen. Cloudflare Workers permite este tipo de reducción de latencia sin servidor.
Es difícil replicar el entorno sin servidor para ver cómo funcionará realmente el código una vez implementado. La depuración es más complicada, debido a que los desarrolladores no tienen visibilidad de los procesos del backend, y porque la aplicación está dividida en funciones separadas y más pequeñas. Cloudflare Workers Playground es un espacio seguro que ayuda a reducir la fricción en las pruebas y la depuración
Cuando los proveedores ejecutan todo el backend, puede que no sea posible examinar su seguridad del todo, lo cual puede suponer un problema para las aplicaciones que manejan datos personales o confidenciales.
Como a las empresas no se les asignan sus propios servidores físicos separados, los proveedores de servicios sin servidor a menudo ejecutarán el código de varios de sus clientes en un solo servidor en un momento dado. Este problema de compartir equipo con otros se conoce como "tenencia múltiple": pensemos en varias empresas que intentan alquilar y trabajar en una misma oficina a la vez. La tenencia múltiple puede afectar al rendimiento de las aplicaciones y, si los servidores de tenencia múltiple no están bien configurados, se podrían acabar filtrando los datos. La tenencia múltiple tiene poco o ningún impacto en las redes que funcionan correctamente como espacio seguro y cuentan con una infraestructura lo suficientemente potente. Por ejemplo, Cloudflare ejecuta una red de 15 Tbps con suficiente exceso de capacidad para mitigar la degradación del servicio, y todas las funciones sin servidor alojadas por Cloudflare se ejecutan en su propio espacio seguro (mediante el motor de Chrome V8).
Esto limita los tipos de aplicaciones que pueden ejecutarse de forma rentable en una arquitectura sin servidor. Ya que los proveedores de servicios sin servidor cobran por el tiempo en el que se está ejecutando el código, puede costar más ejecutar una aplicación con procesos de larga duración en una infraestructura sin servidor que en una tradicional.
Debido a que no se está ejecutando constantemente, puede que haya que arrancar el código sin servidor cuando se utiliza. Este tiempo de arranque puede degradar el rendimiento. Sin embargo, si un fragmento de código se utiliza con regularidad, el proveedor sin servidor lo tendrá listo para ser activado: una solicitud de este código listo para funcionar se denomina "arranque en caliente". Una solicitud para un código que no se haya utilizado durante un tiempo se denomina "arranque en frío".
Cloudflare Workers evita en gran medida el problema del arranque en frío al usar el motor V8 de Chrome, que en la mayoría de los casos es capaz de arrancar y ejecutar código JavaScript en menos de 5 milisegundos. Si el código ya se está ejecutando, el tiempo de respuesta es inferior a un milisegundo. Más información sobre el rendimiento de las diferentes plataformas sin servidor.
Si un proveedor proporciona todos los servicios de backend para una aplicación, aumenta de forma inevitable la dependencia de ese proveedor. Configurar una arquitectura sin servidor con un proveedor puede dificultar el cambio de proveedor cuando sea necesario, sobre todo porque cada proveedor ofrece características y flujos de trabajo ligeramente diferentes. (Es más fácil migrar a Cloudflare Workers, porque está escrito en JavaScript y en base a la ampliamente utilizada API de service workers).
Los desarrolladores que quieran reducir el tiempo que necesitan para lanzar los productos, y crear aplicaciones ligeras y flexibles que puedan ampliarse o actualizarse rápidamente, se pueden beneficiarse considerablemente de la informática sin servidor.
Las arquitecturas sin servidor reducirán los costes de las aplicaciones que tengan un uso inconsistente, con períodos de mayor uso alternados con momentos de poco o ningún tráfico. Para estas aplicaciones, comprar un servidor o un bloque de servidores que estén ejecutándose constantemente y siempre disponibles, incluso cuando no se usan, puede suponer un desperdicio de recursos. Una configuración sin servidor responderá de forma instantánea cuando se necesite y no incurrirá en costes cuando esté en reposo.
Además, los desarrolladores que quieran acercar algunas o todas las funciones de sus aplicaciones a los usuarios finales para reducir la latencia necesitarán al menos una arquitectura parcialmente sin servidor, ya que para ello es necesario mover algunos procesos fuera del servidor de origen.
Hay casos en los que tiene más sentido, tanto desde el punto de vista del coste como de la arquitectura del sistema, utilizar servidores específicos que estén autogestionados u se ofrezcan como servicio. Por ejemplo, las aplicaciones grandes con una carga de trabajo constante y predecible pueden necesitar una configuración tradicional y, en estos casos, es probable que la configuración tradicional sea menos costosa.
Además, puede ser extremadamente difícil migrar las aplicaciones heredadas a una nueva infraestructura que tenga una arquitectura totalmente diferente.
Cloudflare Workers es un producto que permite que los desarrolladores escriban funciones de JavaScript y las implementen en el perímetro de la red de Cloudflare. Esto permite ejecutar el código de la aplicación en una arquitectura sin servidor lo más cerca posible del usuario final, lo cual minimiza la latencia.