Puntos clave
- Durante varios años, nos han prometido que la computación sin servidor (serverless) abrirá una nueva era sin un sistema operativo específico para ejecutar aplicaciones. Se nos ha dicho que esta estructura resolverá numerosos problemas de escalabilidad. Sin embargo, la realidad es diferente.
- Aunque muchos ven la tecnología sin servidor como una idea nueva, sus raíces se pueden rastrear hasta 2006, cuando surgieron Zimki PaaS y Google App Engine; en ambos casos se utiliza una arquitectura sin servidor.
- Hay cuatro razones por las que la revolución sin servidor se ha estancado: desde el soporte limitado de lenguajes de programación hasta problemas de rendimiento.
- La computación sin servidor no es tan inútil. De ninguna manera. Sin embargo, no debe considerarse como un reemplazo directo de los servidores. Para algunas aplicaciones, puede ser una herramienta conveniente.
¡El servidor ha muerto, larga vida al servidor!
Ese es el grito de guerra de los defensores de la revolución sin servidor. Basta con echar un vistazo a la prensa del sector de los últimos años para llegar a la conclusión de que el modelo de servidor tradicional está muerto y que, en pocos años, todos estaremos usando arquitecturas sin servidor.
Como sabe cualquiera en el sector, y como también señalamos en nuestro artículo sobre , no es así. A pesar de los numerosos artículos sobre las ventajas de , esta nunca se ha materializado. De hecho, , que esta revolución puede estar estancada.
Algunas de las promesas para los modelos sin servidor se han cumplido, pero no todas. Lejos de ser todas.
En este artículo, quiero explorar las razones de esta situació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 claramente definidas.
Lo que prometieron los defensores de la computación sin servidor
Antes de abordar los problemas de la computación sin servidor, veamos qué se suponía que debían ofrecer. fueron numerosas y, a veces, muy ambiciosas.
Para aquellos que no están familiarizados con el término, aquí hay una breve definición. La computación sin servidores define una arquitectura en la que las aplicaciones (o partes de aplicaciones) se ejecutan bajo demanda en entornos de ejecución que generalmente se alojan de forma remota. Además, los sistemas sin servidores pueden ser alojados localmente. Durante los últimos años, la creación de sistemas sin servidores sostenibles ha sido la principal preocupación de los administradores de sistemas y las empresas de SaaS, ya que (se afirma) esta arquitectura ofrece varias ventajas clave en comparación con el modelo «tradicional» cliente-servidor:
- Los modelos sin servidores no requieren que los usuarios mantengan sus propios sistemas operativos ni que creen aplicaciones compatibles con sistemas operativos específicos. En su lugar, los desarrolladores crean código general, lo suben a una plataforma sin servidores y supervisan su ejecución.
- Los recursos en los marcos sin servidores generalmente se facturan por minutos (o incluso por segundos). Esto significa que los clientes solo pagan por el tiempo en que su código se está ejecutando realmente. Esto es ventajoso en comparación con una VM en la nube tradicional, donde la máquina está inactiva la mayor parte del tiempo, pero se debe pagar por ella.
- El problema de la escalabilidad también ha sido abordado. Los recursos en los marcos sin servidores se asignan de forma dinámica, lo que permite que el sistema maneje fácilmente picos repentinos en la demanda.
En resumen, los modelos sin servidores ofrecen soluciones flexibles, económicas y escalables. Es sorprendente que no hayamos pensado en esta idea antes.
¿Es realmente una idea nueva?
En realidad, la idea no es nueva. La concepción que permite a los usuarios pagar solo por el tiempo en que el código se ejecuta realmente existe desde que fue introducida en el marco de en 2006, y aproximadamente al mismo tiempo Google App Engine ofreció una solución muy similar.
De hecho, lo que ahora llamamos un modelo «sin servidores» es más antiguo que muchas tecnologías que ahora se denominan «nativas en la nube», y que ofrecen casi lo mismo. Como se ha mencionado, los modelos sin servidores son esencialmente solo una extensión del modelo comercial de SaaS, que ha existido durante varias décadas.
También hay que reconocer que el modelo sin servidor no es una arquitectura FaaS, aunque existe una relación entre ambos. FaaS es, en esencia, la parte centrada en el cálculo de la arquitectura sin servidor, pero no representa todo el sistema en su totalidad.
¿Cuál es todo el alboroto? Bueno, dado que la velocidad de penetración de internet en los países en desarrollo continúa creciendo rápidamente, también aumenta la demanda de recursos computacionales. Por ejemplo, en muchos países con sectores de comercio electrónico en rápido crecimiento, simplemente no existe la infraestructura computacional para las aplicaciones en estas plataformas. Ahí es donde entran las plataformas sin servidor de pago.
Problemas de los modelos sin servidor
El problema es que los modelos sin servidor tienen... problemas. No me malinterpretes: no digo que sean intrínsecamente malos o que no proporcionen un valor significativo para ciertas empresas en ciertas circunstancias. Pero la afirmación central de la 'revolución' —que la arquitectura sin servidor reemplazará rápidamente a la tradicional— nunca se materializará.
Aquí está el porqué.
Soporte limitado para lenguajes de programación
La mayoría de las plataformas sin servidor permiten ejecutar solo aquellas aplicaciones que están escritas en lenguajes específicos. Esto limita gravemente la flexibilidad y adaptabilidad de estos sistemas.
Se considera que las plataformas sin servidor soportan la mayoría de los lenguajes principales. AWS Lambda y Azure Functions también proporcionan un shell para ejecutar aplicaciones y funciones en lenguajes no soportados, aunque esto a menudo implica costos en rendimiento. Así que para la mayoría de las organizaciones, normalmente esta limitación no importa demasiado. Pero aquí está el asunto. Se supone que una de las ventajas de los modelos sin servidor es que los programas poco conocidos o poco utilizados se pueden ejecutar de manera más económica, dado que solo pagas por el tiempo que están activos. Y los programas poco conocidos o poco utilizados suelen estar escritos en... lenguajes de programación poco conocidos o poco utilizados.
Esto socava una de las ventajas clave del modelo sin servidor.
Dependencia del proveedor
El segundo problema con las plataformas sin servidor, o al menos con la forma en que se implementan actualmente, es que generalmente no son similares entre sí a nivel operacional. Prácticamente no hay estandarización en la escritura de funciones, despliegue y gestión. Esto significa que la migración de funciones de una plataforma a otra toma un tiempo extremadamente largo.
La parte más difícil de la transición a un modelo sin servidor no son las funciones computacionales, que generalmente son solo fragmentos de código, sino cómo las aplicaciones están conectadas a sistemas externos, como el almacenamiento de objetos, la gestión de identidades y las colas. Las funciones se pueden mover, pero el resto de la aplicación no. Esto es lo opuesto a las plataformas prometidas que son baratas y flexibles.
Algunos argumentan que los modelos sin servidor han surgido recientemente y que no ha habido tiempo para estandarizar su funcionamiento. Pero no son tan nuevos, como ya he señalado, y muchas otras tecnologías en la nube, como los contenedores, ya se han vuelto mucho más accesibles gracias al desarrollo y la amplia adopción de buenos estándares.
Rendimiento
La capacidad de cómputo 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 afirma que las funciones en plataformas remotas y sin servidor funcionan tan rápido como en los servidores locales, excepto por algunos problemas inevitables de latencia.
Sin embargo, ciertos hechos sugieren lo contrario. Las funciones que no se ejecutaban previamente en una plataforma específica o que no se han ejecutado durante un tiempo requieren algo de tiempo para inicializarse. Probablemente esto se deba a que su código se ha trasladado a algún medio de almacenamiento menos accesible, aunque, como en el caso de los benchmarks, la mayoría de los proveedores no te informarán sobre la transferencia de datos.
Por supuesto, hay varias formas de sortear esto. Una de ellas es optimizar las funciones para cualquier lenguaje de nube en el que opere tu plataforma sin servidor, pero esto socava un poco la afirmación de que estas plataformas son 'flexibles'.
Otro enfoque consiste en asegurar que los programas críticos para el rendimiento se ejecuten regularmente para que se mantengan "frescos". Este segundo enfoque, por supuesto, contradice un poco la afirmación de que las plataformas sin servidor son más económicas, ya que solo pagas por el tiempo de ejecución de tus programas. Los proveedores de la nube han implementado nuevas formas de reducir los inicios en frío, pero muchos de ellos requieren "escalado a uno" (scale to one), lo que socava el valor inicial del FaaS.
El problema del "inicio en frío" se puede resolver parcialmente ejecutando sistemas sin servidor internamente, pero esto conlleva costos propios y sigue siendo una opción de nicho para equipos bien dotados de recursos.
No puedes ejecutar aplicaciones completas
Finalmente, quizás la razón más importante por la cual las arquitecturas sin servidor no reemplazarán los modelos tradicionales en el corto plazo es que (por lo general) no se pueden ejecutar aplicaciones completas sobre ellas.
Más bien, no es viable desde el punto de vista de costos. Es probable que tu exitoso monolito no valga la pena transformarlo en un conjunto de cuatro docenas de funciones, conectadas por ocho gateways, cuarenta colas y una docena de instancias de bases de datos. Por esta razón, las soluciones sin servidor son más adecuadas para nuevos desarrollos. Prácticamente ninguna aplicación existente (arquitectura) se puede trasladar. Puedes migrar, pero tendrás que comenzar desde cero.
Esto significa que, en la gran mayoría de los casos, las plataformas sin servidor se utilizan como complemento a los servidores internos para realizar tareas que requieren un alto poder de cómputo. Esto las distingue enormemente de las otras dos formas de tecnologías en la nube: contenedores y máquinas virtuales, que ofrecen un enfoque integral para la ejecución de cálculos remotos. Esto ilustra una de las dificultades de la transición de microservicios a sistemas sin servidor.
Por supuesto, esto no siempre representa un problema. La capacidad de utilizar recursos computacionales enormes de manera ocasional, sin tener que comprar hardware propio, puede aportar beneficios reales y duraderos a muchas organizaciones. Sin embargo, si algunas aplicaciones se encuentran en servidores internos y otras en arquitecturas de nube sin servidor, la gestión alcanza un nuevo nivel de complejidad.
¿Viva la revolución?
A pesar de todas estas quejas, no tengo nada en contra de las soluciones sin servidor como tales. Lo juro. Simplemente, los desarrolladores deben entender — 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 sobre y decida la mejor manera de aplicar este modelo.
Fuente: habr.com
