Puntos clave
- Desde hace varios años se nos ha prometido que la computación sin servidor (serverless) abrirá una nueva era sin un SO específico para ejecutar aplicaciones. Nos dijeron que tal estructura resolvería muchos problemas de escalabilidad. De hecho, todo es diferente.
- Aunque muchos ven la tecnología sin servidor como una idea nueva, sus raíces se remontan a 2006 con 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 del lenguaje de programación hasta los problemas de rendimiento.
- La informática sin servidor no es tan inútil. Lejos de ahi. Sin embargo, no deben verse como un reemplazo directo de los servidores. Para algunas aplicaciones, pueden ser una herramienta útil.
El servidor está muerto, ¡larga vida al servidor!
Este es el grito de guerra de los partidarios de la revolución sin servidor. Un vistazo rápido a la prensa de la industria en los últimos años es suficiente para concluir que el modelo de servidor tradicional está muerto y que en unos años todos usaremos arquitecturas sin servidor.
Como cualquiera en la industria sabe, y como también señalamos en nuestro artículo sobre , esto está mal. A pesar de muchos artículos sobre el fondo , nunca se llevó a cabo. De hecho, que esta revolución puede haber llegado a un callejón sin salida.
Algunas de las promesas de los modelos sin servidor ciertamente se han hecho realidad, 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 adeptos a la computación sin servidor
Antes de pasar a los problemas de la informática sin servidor, veamos qué tenían para ofrecer. fueron numerosos y, en ocasiones, muy ambiciosos.
Para aquellos que no están familiarizados con el término, aquí hay una breve definición. La informática 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 normalmente se alojan de forma remota. Además, se pueden alojar sistemas sin servidor. La creación de sistemas robustos sin servidor ha sido una de las principales preocupaciones de los administradores de sistemas y las empresas de SaaS en los últimos años, ya que (se afirma) esta arquitectura ofrece varias ventajas clave sobre el modelo cliente/servidor "tradicional":
- Los modelos sin servidor no requieren que los usuarios mantengan sus propios sistemas operativos ni que creen aplicaciones que sean compatibles con sistemas operativos específicos. En su lugar, los desarrolladores crean código compartido, lo suben a una plataforma sin servidor y lo ven ejecutar.
- Los recursos en marcos sin servidor generalmente se facturan por minuto (o incluso por segundos). Esto significa que los clientes solo pagan por el tiempo que realmente ejecutan el código. Esto se compara favorablemente con la máquina virtual en la nube tradicional, donde la máquina está inactiva la mayor parte del tiempo, pero hay que pagarla.
- También se resolvió el problema de la escalabilidad. Los recursos en los marcos sin servidor se asignan dinámicamente para que el sistema pueda hacer frente fácilmente a picos repentinos de demanda.
En resumen, los modelos sin servidor brindan soluciones escalables, flexibles y de bajo costo. Me sorprende que no se nos haya ocurrido esta idea antes.
¿Es esto realmente una idea nueva?
En realidad la idea no es nueva. El concepto de permitir que los usuarios paguen solo por el tiempo que realmente se ejecuta el código ha existido desde que se introdujo bajo el en 2006, y casi al mismo tiempo, Google App Engine ideó 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 llaman "nativas de la nube" que proporcionan casi lo mismo. Como se señaló, los modelos sin servidor son esencialmente solo una extensión del modelo comercial 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 la parte centrada en la computación de una arquitectura sin servidor, pero no representa el sistema completo.
Entonces, ¿por qué todo este bombo? Bueno, a medida que la tasa de penetración de Internet en los países en desarrollo sigue aumentando, también lo hace la demanda de recursos informáticos. Por ejemplo, muchos países con sectores de comercio electrónico en rápido crecimiento simplemente no tienen la infraestructura informática para aplicaciones en estas plataformas. Aquí es donde entran las plataformas sin servidor de pago.
Problemas con los modelos sin servidor
El problema es que los modelos sin servidor tienen... problemas. No me malinterpreten: no estoy diciendo que sean malos en sí mismos o que no proporcionen un valor significativo a algunas empresas en algunas circunstancias. Pero el reclamo principal de la "revolución" (que la arquitectura sin servidor reemplazará rápidamente a la tradicional) nunca llega a buen término.
Es por eso.
Soporte limitado para lenguajes de programación.
La mayoría de las plataformas sin servidor solo permiten que se ejecuten aplicaciones escritas en ciertos idiomas. Esto limita severamente la flexibilidad y adaptabilidad de estos sistemas.
Se considera 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 admitidos, aunque esto suele tener un costo de rendimiento. Entonces, para la mayoría de las organizaciones, esta limitación no suele ser un gran problema. Pero aquí está la cosa. Se supone que uno de los beneficios de los modelos sin servidor es que los programas oscuros y de uso poco frecuente se pueden usar de manera más económica porque solo paga por el tiempo que se ejecutan. Y los programas oscuros y poco utilizados a menudo están escritos en... lenguajes de programación oscuros y poco utilizados.
Esto socava una de las ventajas clave del modelo sin servidor.
Vinculación a un proveedor
El segundo problema con las plataformas sin servidor, o al menos con la forma en que se implementan actualmente, es que generalmente no se parecen a nivel operativo. Prácticamente no hay estandarización en cuanto a funciones de escritura, despliegue y gestión. Esto significa que migrar funciones de una plataforma a otra lleva mucho tiempo.
La parte más difícil de pasar a un modelo sin servidor no son las características computacionales, que generalmente son solo fragmentos de código, sino cómo las aplicaciones se comunican 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 baratas y flexibles prometidas.
Algunos argumentan que los modelos sin servidor son nuevos y no ha habido tiempo para estandarizar su funcionamiento. Pero no son tan nuevos, como señalé anteriormente, y muchas otras tecnologías en la nube, como los contenedores, ya se han vuelto mucho más convenientes debido al desarrollo y la adopción generalizada de buenos estándares.
Rendimiento
El rendimiento informático de las plataformas sin servidor es difícil de medir, en parte porque los proveedores tienden a mantener la información en secreto. La mayoría argumenta que las funciones en plataformas remotas sin servidor se ejecutan tan rápido como lo hacen en servidores internos, excepto por algunos problemas de latencia inevitables.
Sin embargo, alguna evidencia sugiere lo contrario. Las funciones que no se han ejecutado previamente en una plataforma en particular, o que no se han ejecutado durante algún tiempo, tardan un tiempo en inicializarse. Es probable que esto se deba a que su código se transfirió a algún medio de almacenamiento menos disponible, aunque, al igual que con los puntos de referencia, la mayoría de los proveedores no le informarán sobre la portabilidad de datos.
Por supuesto, hay varias maneras de evitar esto. Una es optimizar las funciones 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 "ágiles".
Otro enfoque es garantizar que los programas críticos para el rendimiento se ejecuten con regularidad para mantenerlos "frescos". Este segundo enfoque, por supuesto, es un poco contrario a la afirmación de que las plataformas sin servidor son más rentables porque solo paga por el tiempo que se ejecutan sus programas. Los proveedores de la nube han introducido nuevas formas de reducir los lanzamientos en frío, pero muchos de ellos requieren "escala a uno", lo que socava el valor original de FaaS.
El problema del arranque en frío se puede abordar en parte mediante la ejecución interna de sistemas sin servidor, pero esto tiene su propio costo y sigue siendo una opción de nicho para los equipos con buenos recursos.
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 es que (generalmente) no pueden ejecutar aplicaciones completas.
Más precisamente, es poco práctico desde el punto de vista del coste. Su monolito exitoso probablemente no debería convertirse en un conjunto de cuatro docenas de funciones unidas por ocho puertas de enlace, cuarenta colas y una docena de instancias de bases de datos. Por esta razón, serverless es más adecuado para nuevos desarrollos. Prácticamente no se puede portar ninguna aplicación (arquitectura) existente. Puedes migrar, pero tienes que empezar de cero.
Esto significa que, en la gran mayoría de los casos, las plataformas sin servidor se utilizan como complemento de los servidores back-end para realizar tareas informáticas 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 la computación remota. Esto ilustra uno de los desafíos de migrar de microservicios a sistemas sin servidor.
Por supuesto, esto no siempre es un problema. La capacidad de utilizar periódicamente enormes recursos informáticos sin comprar su propio hardware puede brindar beneficios reales y duraderos a muchas organizaciones. Pero si algunas aplicaciones están en servidores internos y otras en arquitecturas de nube sin servidor, la administración entra en un nuevo nivel de complejidad.
¿Larga vida a la revolución?
A pesar de todas estas quejas, no me opongo a 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 para los servidores. En su lugar, consulte nuestros consejos y recursos sobre y decidir la mejor manera de aplicar este modelo.
Fuente: habr.com