Innovaciones como las máquinas virtuales (VM), los contenedores y la nube pública han mejorado en muchos aspectos el desarrollo de las aplicaciones. Sin embargo, siguen haciendo recaer diversas decisiones acerca de la configuración, el mantenimiento y la optimización en los desarrolladores, en lugar de en la propia tecnología.
Cuanto más se dejen estas responsabilidades en manos de los desarrolladores, menos tiempo tendrán estos para crear productos y aplicaciones internas. Por desgracia, muchas tecnologías ampliamente adoptadas encargan a los desarrolladores la optimización del rendimiento, el escalado de las aplicaciones, los parches de seguridad, el equilibrio de la carga, etc. Estas responsabilidades conllevan el riesgo de tomar decisiones que disten de ser las óptimas o de errores que podrían agotar los presupuestos o causar vulnerabilidades y tiempo de inactividad.
Esta ineficacia tiene graves consecuencias. Resulta alarmante que el tiempo que los desarrolladores dedican a tareas ajenas a la codificación cueste a las organizaciones más de 85 000 millones de dólares anuales.
Por tanto, eliminar la complejidad del desarrollo de aplicaciones puede mejorar la experiencia de los desarrolladores y, al mismo tiempo, suponer a las organizaciones un importante ahorro.
La tecnología sin servidor se diseñó para resolver estos problemas, concretamente para mejorar el desarrollo de aplicaciones al reducir la carga que recae sobre los desarrolladores. Sin embargo, no todas las plataformas sin servidor son iguales. Las primeras iteraciones de las plataformas sin servidor heredaron muchos de los problemas de configuración, escalabilidad y rendimiento asociados a la tecnología sobre la que se desarrollaron: los contenedores, las regiones y la nube pública.
Así, la tecnología "sin servidor", tal como lo conocemos hoy, es a menudo una abstracción deficiente creada sobre un modelo anterior.
Las plataformas sin servidor avanzadas han superado estos problemas con varias mejoras arquitectónicas importantes. Estas mejoras eliminan del proceso de desarrollo decisiones que requieren mucho tiempo, tiempo que ganan los equipos para dedicarlo a crear fantásticos productos y aplicaciones.
Antes de la tecnología sin servidor, existían las máquinas virtuales y los contenedores. Las máquinas virtuales son ordenadores basados en software que existen en el sistema operativo de otro ordenador, y los contenedores son unidades estándar de software que contienen todos los elementos que necesita una aplicación para ejecutarse.
Ambas tecnologías permiten a los desarrolladores dedicar más tiempo a su aplicaciones y menos a la gestión del hardware. Sin embargo, las máquinas virtuales y los contenedores siguen sobrecargando a los desarrolladores con tareas de gestión y configuración que ralentizan el proceso general de desarrollo.
En distinta medida, las máquinas virtuales y los contenedores requieren que los desarrolladores y sus equipos de informática y de seguridad asociados:
Gestionen los parches de seguridad y los permisos de gestión de identidad y acceso (IAM).
Configuren el equilibrio de carga y la red.
Garanticen la disponibilidad e integren la redundancia.
Los sistemas de orquestación de contenedores como Kubernetes liberan de muchos de los requisitos de configuración asociados a los contenedores, incluida la gestión de la escala y la redundancia. Sin embargo, los equipos de operaciones de desarrollo (DevOps), que se centran en resolver problemas internos de desarrollo en lugar de aquellos que afectan a los servicios de los clientes, necesitan conocimientos de Kubernetes para gestionar eficazmente estos sistemas. Sin Kubernetes y un equipo debidamente formado, las limitaciones de los contenedores siguen presentes.
Las máquinas virtuales y los contenedores son solo una parte de un panorama más amplio. Ambas tecnologías pueden utilizarse en la nube pública, que conlleva sus propias limitaciones.
La nube pública ayuda a simplificar diversos aspectos del desarrollo, pero sigue dejando capas de configuración a la organización del cliente. Por ejemplo, seleccionar las regiones, gestionar la seguridad, diseñar las soluciones de red y garantizar la disponibilidad. La nube pública también requiere la combinación manual de múltiples servicios como bases de datos, colas de mensajes y almacenamiento. El procedimiento manual de configuración y conexión de estos servicios requiere mucho tiempo, lo que aumenta el tiempo total de implementación.
El desarrollo sin servidor se diseñó para resolver los desafíos asociados a las máquinas virtuales, los contenedores y la nube pública. Pero el éxito de los primeros métodos sin servidor solo fue parcial.
Los principales desafíos del desarrollo sin servidor de primera generación son:
Latencia y escalabilidad. Muchas de estas plataformas sin servidor operan en la nube pública, que se basa en centros de datos centralizados para reducir los costes generales. Este modelo requiere que los clientes seleccionen las regiones de implementación donde se ubicarán físicamente sus recursos. La centralización de los datos añade latencia porque el código se ejecuta lejos de los usuarios finales. Además, es posible el escalado y la implementación en varias regiones, pero su configuración es compleja.
Arranques en frío y limitación de la CPU. Las plataformas sin servidor basadas en contenedores tienen dificultades con los arranques en frío y la limitación de la unidad central de procesamiento (CPU). Los arranques en frío son los retardos de carga que se producen cuando una función sin servidor se ejecuta por primera vez. Los arranques en frío tienen lugar porque los contenedores pueden tardar algunos segundos en calentarse. Por otro lado, la limitación de CPU se produce cuando una plataforma alcanza su límite designado de instancias sin servidor y retarda las solicitudes.
Mala experiencia de los desarrolladores. A menudo, los desarrolladores tienen que gestionar tareas que llevan mucho tiempo, como configurar plantillas de orquestación, dimensionar la aplicación y determinar los niveles de memoria. Estas tareas implican la posibilidad de cometer costosos errores, y reducen el tiempo que los desarrolladores dedican a codificar, con el consiguiente coste para las organizaciones.
Observabilidad limitada. Muchas plataformas de desarrollo sin servidor son difíciles de supervisar porque no ofrecen una observabilidad adecuada. La observabilidad es el grado en que una organización puede comprender lo que ocurre en un sistema distribuido mediante métricas de rendimiento, registros de eventos, etc. Sin una observabilidad adecuada, una organización no puede diagnosticar y solucionar eficazmente los problemas de una aplicación sin servidor.
La naturaleza sin estado limita la funcionalidad de la aplicación. Las plataformas sin servidor de primera generación son efectivamente sin estado. La naturaleza sin estado facilita la escalabilidad, pero puede dificultar la creación de aplicaciones que requieran una gran coherencia o coordinación en directo entre varios clientes, como el chat interactivo, los videojuegos o las herramientas de edición colaborativa.
Coste. Muchas plataformas sin servidor en la nube están sujetas a costes adicionales y a menudo ocultos, como las tarifas de puerta de enlace de API o por "mantener calientes" los contenedores. Como resultado, el desarrollo de aplicaciones con estas plataformas de primera generación puede resultar caro, especialmente a escala.
El propósito de la tendencia de las arquitecturas sin servidor siempre ha sido facilitar el proceso de desarrollo de aplicaciones, pero las plataformas sin servidor que se ejecutan en la nube pública centralizada no cumplen plenamente esa promesa.
Las plataformas de desarrollo sin servidor de última generación han resuelto muchas de las deficiencias de las soluciones anteriores. Al no depender de infraestructuras heredadas como los contenedores y la nube pública, estas soluciones ofrecen varias mejoras y permiten a los desarrolladores disponer de más tiempo para otras tareas.
Estas mejoras incluyen:
Ejecución en el perímetro de la red. Las plataformas sin servidor más avanzadas se ejecutan en "el perímetro", es decir, en una red distribuida de muchos centros de datos. Cuanto mayor sea la red, mejor resolverá los problemas de rendimiento y escalabilidad. Esto se debe a que, en las redes perimetrales, los procesos tienen lugar en el punto de presencia más cercano al usuario final. Este enfoque distribuido reduce la latencia y es radicalmente distinto a las regiones centralizadas en la nube pública. Así, la implementación de código en una red de cientos de centros de datos ofrecerá un mejor rendimiento que una red de 20 centros de datos. Las plataformas perimetrales más avanzadas ofrecerán tiempos de ejecución de CPU largos para crear cargas de trabajo complejas.
Utilización de aislamientos en lugar de contenedores. Este enfoque elimina los problemas de la arquitectura basada en contenedores (los arranques en frío y la limitación de CPU), cuya mitigación es costosa. A diferencia de los contenedores, los aislamientos no necesitan mantenimiento en caliente, por lo que los arranques en frío no son un problema. Los aislamientos también consumen menos memoria, por lo que reducen los problemas de la sobrecarga y de la limitación de CPU.
Menos decisiones previas. Algunas plataformas perimetrales sin servidor más recientes optimizan automáticamente el rendimiento y la seguridad de las aplicaciones. Las soluciones con redes perimetrales globales tampoco requieren que los desarrolladores elijan regiones en las que alojar su carga de trabajo, puesto que implementan el código en todos los centros de datos de su red. La eliminación de estas tediosas tareas mejora la experiencia de los desarrolladores.
Análisis y registro detallados. Mientras que las plataformas sin servidor anteriores no proporcionaban mucha funcionalidad de análisis, depuración o registro, las plataformas sin servidor perimetrales avanzadas ofrecen una mayor observabilidad. Los análisis y registros detallados facilitan a los equipos de desarrollo la recopilación de la información que necesitan para solucionar los problemas. Además, algunas plataformas se integran con herramientas de supervisión más sofisticadas, que pueden requerir aplicaciones más complejas.
Coordinación y almacenamiento integrados. Esta función posibilita la arquitectura con estado en una estrategia sin servidor. La arquitectura con estado requiere un almacenamiento de datos coherente, a diferencia de las aplicaciones sin estado, en las que los datos son transitorios. No es posible crear aplicaciones interactivas en tiempo real sin una arquitectura con estado.
Rentable. Las plataformas perimetrales sin servidor ligeras, basadas en aislamientos, son menos costosas que sus predecesoras basadas en contenedores. La arquitectura de aislamientos aporta todas las ventajas de escalabilidad y flexibilidad asociadas a la nube, pero sin tarifas ocultas ni picos de coste.
Con estas mejoras, las plataformas sin servidor de última generación optimizan el proceso general de desarrollo de aplicaciones. Eliminan las tareas tediosas y permiten que los desarrolladores se centren en lo importante, mientras ofrecen un ahorro de costes a la organización.
La plataforma sin servidor adecuada elimina las limitaciones de escalabilidad, al tiempo que descarga de trabajo a los desarrolladores y mejora la eficiencia general del proceso de desarrollo de aplicaciones. Cloudflare Workers es una plataforma perimetral sin servidor que utiliza una infraestructura inteligente para liberar a los desarrolladores de muchas decisiones previas. Gracias a la infraestructura de Cloudflare, las aplicaciones creadas en Workers siempre están optimizadas en cuanto a seguridad, rendimiento y fiabilidad.
La escalabilidad no es un problema, ya que Workers se ejecuta en la red global de Cloudflare, que abarca más de 330 ciudades en más de 120 países. El código se implementa automáticamente en todas las regiones, sin necesidad de configuraciones adicionales ni costes extras. Con Workers Unbound, los equipos de desarrollo pueden crear aplicaciones avanzadas en el perímetro que requieran largos tiempos de CPU. Puesto que la plataforma Workers se ejecuta en aislamientos y no en contenedores, no hay arranques en frío ni limitación de CPU. Workers ofrece observabilidad integrada e incorpora herramientas de supervisión más avanzadas como New Relic y Sentry, así como con herramientas de depuración y registro disponibles a través de la interfaz de línea de comandos (CLI) de Workers. Durable Objects proporciona a la plataforma Workers una coordinación de baja latencia y un almacenamiento coherente, y hace así realidad las aplicaciones sin servidor con estado. Al mismo tiempo, Workers ahorra dinero a los clientes, ya que elimina las tarifas ocultas y ofrece el mejor precio del sector.
Workers permite a los equipos de desarrollo centrarse en la creación de productos en lugar de en el mantenimiento y la configuración. Por lo tanto, mejora la experiencia de los desarrolladores y beneficia económicamente a la empresa con el tiempo.
Este artículo forma parte de un conjunto de publicaciones sobre las últimas tendencias y temas que afectan a los responsables de la toma de decisiones sobre tecnología en la actualidad.
Después de leer este artículo podrás entender:
Lo que está en juego en una arquitectura de desarrollo ineficaz
Cómo han evolucionado los métodos de desarrollo hasta la informática sin servidor
Cómo las primeras iteraciones de la informática sin servidor no conseguían simplificar el desarrollo de aplicaciones
Las principales diferencias de la informática sin servidor de última generación
Más información sobre las plataformas sin servidor como Workers en el informe The Forrester New Wave: Function-as-a-Service Platforms.