Puntos clave
- Desde hace varios años, se nos ha prometido que la informática sin servidor marcará el comienzo de una nueva era sin un sistema operativo específico para ejecutar aplicaciones. Nos dijeron que tal estructura resolvería muchos problemas de escalabilidad. De hecho, todo es diferente.
- Si bien muchos ven la tecnología sin servidor como una nueva idea, sus raíces se remontan a 2006, cuando se introdujeron Zimki PaaS y Google App Engine, los cuales utilizan una arquitectura sin servidor.
- Hay cuatro razones por las que la revolución sin servidor se ha estancado, desde el soporte limitado para lenguajes de programación hasta problemas de rendimiento.
- La informática sin servidor no es tan inútil. De ningún modo. Sin embargo, no deben verse como un reemplazo directo de los servidores. Para algunas aplicaciones, pueden ser una herramienta útil.
El servidor está muerto, ¡viva el servidor!
Este es el grito de batalla de los adeptos de la revolución sin servidor. Con un vistazo rápido a la prensa de la industria de los últimos años, es fácil concluir que el modelo de servidor tradicional está muerto y que dentro de unos años todos utilizaremos arquitecturas sin servidor.
Como todo el mundo en la industria sabe, y como también señalamos en nuestro artículo sobre el estado de la informática sin servidor , este no es el caso. A pesar de muchos artículos sobre los méritos de la revolución sin servidores , nunca se materializó . De hecho, investigaciones recientes sugieren que esta revolución puede estar estancada.
Sin duda, algunas de las promesas de los modelos sin servidor se han cumplido, pero no todas. No todo el mundo.
En este artículo, quiero considerar las razones de esta condición. Por qué la falta de flexibilidad de los modelos sin servidor sigue siendo un obstáculo para su adopción más amplia, aunque siguen siendo útiles en circunstancias específicas y bien definidas.
Lo que prometieron los defensores de la informática sin servidor
Antes de abordar los problemas de la informática sin servidor, veamos qué tenían para ofrecer. Las promesas de una revolución sin servidor fueron numerosas y, a veces, muy ambiciosas.
Para aquellos que no estén familiarizados con el término, aquí hay una definición rápida. La computación sin servidor define una arquitectura en la que las aplicaciones (o partes de aplicaciones) se ejecutan bajo demanda en entornos de tiempo de ejecución que generalmente se alojan de forma remota. Además, se pueden alojar sistemas sin servidor. Durante los últimos años, la construcción de sistemas sin servidor resistentes ha sido una de las principales preocupaciones de los administradores de sistemas y las empresas SaaS, ya que (supuestamente) esta arquitectura ofrece varias ventajas clave sobre el modelo cliente / servidor "tradicional":
- , , . , .
- ( ). , , . VM, , .
- . , .
En resumen, los modelos sin servidor ofrecen soluciones escalables, flexibles y de bajo costo. Es sorprendente que no se nos haya ocurrido esta idea antes.
¿Es esta realmente una idea nueva?
De hecho, la idea no es nueva. El concepto de permitir que los usuarios paguen solo por el tiempo que el código realmente se ejecuta ha existido desde que se introdujo como parte de Zimki PaaS en 2006, y casi al mismo tiempo, Google App Engine ofrecía una solución muy similar.
De hecho, lo que ahora llamamos el modelo "sin servidor" es más antiguo que muchas de las tecnologías que ahora se denominan "nube nativa" y que ofrecen prácticamente lo mismo. Como se señaló, los modelos sin servidor son esencialmente una extensión del modelo de negocio SaaS que ha existido durante décadas.
También vale la pena reconocer que el modelo sin servidor no es una arquitectura FaaS, aunque existe una conexión entre los dos. FaaS es esencialmente una pieza orientada a la computación de una arquitectura sin servidor, pero no representa el sistema completo.
Entonces, ¿por qué tanto alboroto? Bueno, a medida que la velocidad de penetración de Internet en los países en desarrollo continúa disparándose, la demanda de recursos informáticos está creciendo al mismo tiempo. Por ejemplo, muchos países con sectores de comercio electrónico en rápido crecimiento simplemente no cuentan con la infraestructura informática para aplicaciones en estas plataformas. Aquí es donde entran en juego las plataformas sin servidor de pago.
Problemas del modelo sin servidor
El problema es que los modelos sin servidor tienen… problemas. No me malinterpretes: no estoy diciendo que sean malos en sí mismos o que no aporten un valor significativo a algunas empresas en determinadas circunstancias. Pero la afirmación principal de la "revolución", que la arquitectura sin servidor reemplazará rápidamente a la arquitectura tradicional, nunca se materializa.
Es por eso.
Soporte limitado para lenguajes de programación
La mayoría de las plataformas sin servidor solo permiten la ejecución de aplicaciones escritas en ciertos idiomas. Esto limita severamente la flexibilidad y adaptabilidad de estos sistemas.
Se cree que las plataformas sin servidor son compatibles con la mayoría de los idiomas principales. AWS Lambda y Azure Functions también proporcionan un contenedor para ejecutar aplicaciones y funciones en idiomas no compatibles, aunque esto a menudo conlleva un costo de rendimiento. Entonces, para la mayoría de las organizaciones, esta limitación generalmente no importa mucho. Pero esta es la cuestión. Se sugiere que una de las ventajas de los modelos sin servidor es que los programas poco conocidos y poco utilizados se pueden usar más baratos porque solo paga por el tiempo de ejecución. Y los programas poco conocidos y poco utilizados a menudo se escriben en ... lenguajes de programación poco conocidos y poco utilizados.
Esto socava uno de los beneficios clave del modelo sin servidor.
Vinculación de proveedor
El segundo problema con las plataformas sin servidor, o al menos la forma en que se implementan actualmente, es que generalmente no se parecen a un nivel operativo. Prácticamente no hay estandarización en términos de funciones de escritura, implementación y administración. Esto significa que la migración de funciones de una plataforma a otra consume mucho tiempo.
La parte más difícil de pasar a un modelo sin servidor no son las funciones computacionales, que generalmente son solo fragmentos de código, sino cómo las aplicaciones se relacionan con los sistemas conectados, como el almacenamiento de objetos, la administración de identidades y las colas. Las funciones se pueden mover, pero el resto de la aplicación no. Esto es exactamente lo contrario de las plataformas flexibles y de bajo costo prometidas.
Algunos argumentan que los modelos sin servidor son nuevos y no ha habido tiempo para estandarizar su funcionamiento. Pero no son tan nuevas, como señalé anteriormente, y muchas otras tecnologías en la nube, como los contenedores, ya se han vuelto mucho más utilizables a través del desarrollo y la adopción generalizada de buenos estándares.
Actuación
El rendimiento computacional de las plataformas sin servidor es difícil de medir, en parte porque los proveedores tienden a mantener la información privada. La mayoría argumenta que la funcionalidad en plataformas remotas sin servidor es tan rápida como en los servidores internos, salvo por algunos problemas de latencia inevitables.
Sin embargo, algunos hechos sugieren lo contrario. Las funciones que no se han ejecutado anteriormente en una plataforma en particular o que no se han ejecutado durante algún tiempo, toman algún tiempo para inicializarse. Esto probablemente se deba al hecho de que su código se transfirió a un medio de almacenamiento menos accesible, aunque, como en el caso de los puntos de referencia, la mayoría de los proveedores no le informarán sobre la transferencia de datos.
Por supuesto, hay varias formas de evitar esto. Una es optimizar la funcionalidad para cualquier lenguaje de nube en el que se ejecute su plataforma sin servidor, pero eso socava un poco la afirmación de que estas plataformas son "flexibles".
Otro enfoque es asegurarse de que los programas críticos para el rendimiento se ejecuten con regularidad para mantenerlos actualizados. Este segundo enfoque, por supuesto, contradice la noción de que las plataformas sin servidor son más rentables, por supuesto, porque solo paga por el tiempo de ejecución de sus programas. Los proveedores de la nube han introducido nuevas formas de reducir los arranques en frío, pero muchos de ellos requieren "escalar a uno", lo que socava el valor original de FaaS.
El problema del arranque en frío puede resolverse parcialmente ejecutando sistemas sin servidor internamente, pero esto tiene un costo y sigue siendo una opción de nicho para equipos con recursos suficientes.
No puede ejecutar aplicaciones completas
Finalmente, quizás la razón más importante por la que las arquitecturas sin servidor no reemplazarán a los modelos tradicionales en el corto plazo: (generalmente) no pueden ejecutar aplicaciones completas.
Más precisamente, no es rentable. Su monolito exitoso probablemente no debería convertirse en un conjunto de cuatro docenas de funciones enlazadas por ocho puertas de enlace, cuarenta colas y una docena de instancias de bases de datos. Por esta razón, la tecnología sin servidor es más adecuada para nuevos desarrollos. Casi ninguna aplicación (arquitectura) existente se puede migrar. Puedes migrar, pero tienes que empezar desde cero.
Esto significa que en la gran mayoría de los casos, las plataformas sin servidor se utilizan para complementar los servidores back-end para realizar tareas computacionalmente intensivas. Esto es muy diferente de las otras dos formas de computación en la nube, contenedores y máquinas virtuales, que ofrecen una forma holística de realizar computación remota. Esto ilustra uno de los desafíos de pasar de los microservicios a los sistemas sin servidor.
Por supuesto, esto no siempre es un problema. La capacidad de utilizar recursos informáticos masivos periódicamente sin comprar su propio hardware puede traer beneficios reales y duraderos a muchas organizaciones. Pero cuando algunas aplicaciones se alojan en servidores internos y otras se alojan en arquitecturas de nube sin servidor, la gestión adquiere un nuevo nivel de complejidad.
¿Larga vida a la revolución?
A pesar de todas estas quejas, no estoy en contra de las soluciones sin servidor per se. Honestamente. Es solo que los desarrolladores deben comprender, especialmente si están explorando modelos sin servidor por primera vez, que esta tecnología no es un reemplazo directo de los servidores. En su lugar, consulte nuestros consejos y recursos para crear aplicaciones sin servidor y decida cuál es la mejor manera de aplicar este modelo.