Edge vs Cloud Computing: Guía para desarrolladores modernos

La evolución de las redes de distribución de contenidos (CDN)

Inicialmente centradas en el almacenamiento en caché y la protección de los servidores de origen, las CDN empezaron a evolucionar con el auge de la informática sin servidores. Una nueva idea se popularizó rápidamente: los desarrolladores podían definir una "función" atómica que se ejecutara a demanda en respuesta a un evento, como la subida de una nueva imagen o un nuevo registro de la base de datos, sin tener que poseer y mantener la infraestructura física o virtual subyacente.

AWS Lambda fue el primer ejemplo de este nuevo paradigma en 2015. AWS Lambda@Edge le siguió en 2016, permitiéndote adoptar el mismo enfoque con funciones que se ejecutan sobre Amazon CloudFront, el servicio CDN de AWS.

Las CDN más populares siguieron su ejemplo, introduciendo servicios como CloudFlare Workers en 2017, Fastly Compute@Edge en 2019 y Akamai EdgeWorkers en 2019.

¡Y no se detuvieron ahí! Como decíamos al principio de este artículo, el edge computing no consiste sólo en llevar las capacidades de computación al borde. En la mayoría de los casos, también necesitas algún tipo de almacenamiento de datos. Así que las CDN siguieron evolucionando y lanzaron nuevos servicios de vanguardia, como almacenes de valores clave, almacenamiento de objetos, bases de datos SQL, redimensionamiento de imágenes, inferencia de IA, ¡y mucho más!

Por ejemplo:

• La plataforma de desarrollo de CloudFlareincluye servicios deborde como Workers KV para almacenamiento de valores clave, D1 para bases de datos relacionales SQL con recuperación puntual, R2 para almacenamiento de objetos sin cuota de salida y Queues para ejecución de tareas asíncronas. 
• Del mismo modo, en Fastly encontrarás KV Store para almacenar pares clave-valor, secretos y datos de configuración, y Fanout para pub/sub asíncrono bidireccional en el borde.
• Y lo has adivinado, Akamai ofrece EdgeKV.
• Amazon CloudFront introduced its CloudFront KeyValueStore in 2023.

Hoy en día, las CDN ofrecen servicios que normalmente esperarías que sólo se ejecutaran en una región de la nube (o centro de datos), desde funciones sin servidor hasta almacenes de valores clave, almacenamiento de objetos, colas y bases de datos relacionales. Casualmente, las colas, el almacenamiento de objetos y la capacidad de cálculo fueron los primeros servicios en la nube anunciados allá por 2006, que ahora debutan en el borde de forma globalmente distribuida.

Bajo el capó, estas nuevas plataformas de computación de borde utilizan tecnologías diferentes y admiten lenguajes de programación distintos. Por ejemplo, CloudFlare utiliza el motor V8 de Chrome, que inicialmente sólo admitía JavaScript, pero que empezó a incorporar WebAssembly en 2018. Por otro lado, Fastly decidió utilizar WebAssembly desde el principio para el sandboxing de su entorno, con el fin de evitar algunas de las limitaciones de latencia de arranque de V8. Esto permite que Fastly sea compatible con muchos lenguajes de programación, como TypeScript, Rust, Go, .NET, Ruby y Swift.

Abramos un rápido paréntesis sobre WebAssembly.

WebAssembly en el borde

WebAssembly (o Wasm, abreviado) podría ser el desarrollo más interesante en este espacio. Desde que se anunció en 2017 y luego se convirtió en una recomendación del W3C en 2019, mucha gente habla de ella para la ejecución de binarios Wasm en el navegador, pero también tiene mucho potencial para la ejecución en el lado del servidor, incluido el borde.

Wasm te permite escribir lógica empresarial en varios lenguajes compatibles y compilarla en un archivo binario que se ejecuta en tiempos de ejecución Wasm, como el wasmtime de Bytecode Alliance.

Junto con WASI (WebAssembly System Interface), te permite componer software escrito en distintos lenguajes con una interfaz estandarizada por el W3C.

Si esto te suena a algo muy popular en el mundo de la nube, echa un vistazo a este tuit de 2019 del fundador de Docker:

Por tanto, las expectativas para Wasm + WASIson muy altas. Te animo encarecidamente a que estés atento a la Bytecode Alliance y a sus esfuerzos por crear compiladores, tiempos de ejecución y herramientas seguros y abiertos para WebAssembly. La organización sin ánimo de lucro fue fundada en 2019 por Mozilla, Fastly, Intel y Red Hat. En la actualidad, entre sus miembros se encuentran otros actores de la nube y los bordes, como Amazon, Arm, Cisco, Docker, Fermyon, Microsoft, Nginx, Shopify, Siemens y VMware.

Comparación entre Edge y Cloud Computing

Ahora, volvamos a nuestra exploración de la computación de borde.

Una de las diferencias más interesantes y notables con respecto a la computación en nube es que el borde está globalmente distribuido por diseño. Tu código y el almacenamiento de datos se ejecutan de forma nativa en cientos de servidores de borde. Es una gran diferencia en comparación con las arquitecturas de nube que suelen empezar como aplicaciones centralizadas que se ejecutan en un único centro de datos (o en 2-3 zonas de disponibilidad dentro de una región de nube).

Aunque muchas aplicaciones pueden ejecutarse fácilmente de forma centralizada, si estás construyendo un sitio web o un producto con una audiencia global, tu arquitectura implicará sin duda algún tipo de almacenamiento en caché y distribución de contenidos. Y con la computación de borde que se produce automáticamente, tu aplicación de borde se distribuye globalmente con un clic (o comando CLI) y se ejecuta lo más cerca posible de tus usuarios para optimizar la latencia.

Así que aquí viene la pregunta retórica.

¿Sigues necesitando la nube?

En otras palabras, ¿sigue siendo la nube la mejor opción para diseñar y crear aplicaciones bien diseñadas y escalables en 2024?

¡Pues sí!

La realidad es que para la mayoría de los casos de uso, el borde sigue necesitando algún tipo de origen del que depender. El origen es donde se ejecuta la lógica empresarial del código, ya sea el backend de tu sitio web u otras cargas de trabajo complejas que deban permanecer centralizadas (por comodidad, limitaciones técnicas o coste).

Veamos qué cargas de trabajo es probable que permanezcan en la nube (por ahora):

• API de backend + RDMS - Normalmente el núcleo de tus bases de datos de origen y producción (sólo en AWS hay al menos 10 servicios de bases de datos diferentes).
• Almacenamiento masivo - La nube ofrece formas de reducir costes mediante el almacenamiento en frío.
• Análisis de datos - Tu típico almacén de datos, lago de datos y canalizaciones de datos necesitan un repositorio de datos centralizado para ejecutar consultas y elaborar informes.
• IA/ML - Entrenar de forma eficaz y rentable requiere conjuntos de datos masivos (mientras que la inferencia ya puede ejecutarse en el borde).
• HPC/Simulaciones - La informática de alto rendimiento está distribuida por diseño, pero normalmente dentro del mismo centro de datos o región para reducir la sobrecarga de la red.
• Canalizaciones CI/CD - Éstas podrían ejecutarse en cualquier lugar, pero probablemente sea más cómodo y barato utilizar la nube (incluidas las canalizaciones para desplegar tus servicios de borde).

En resumen, la nube destaca en los servicios de uso general, ya que admite casi todos los tipos posibles de cargas de trabajo que existen, con almacenamiento prácticamente infinito y escalabilidad horizontal (dentro de una región o a través de un pequeño número de regiones para la resiliencia y la recuperación ante desastres).

Por el contrario, el borde simplifica los despliegues globales, mejora la seguridad y permite el almacenamiento en caché para los orígenes en la nube, al tiempo que admite funciones optimizadas para la latencia sin añadir complejidad a tu aplicación principal.

En otras palabras, la computación en nube y la computación de borde se complementan. Seguirán coexistiendo y resolviendo problemas técnicos diferentes.

Arquitecturas conscientes de los costes

Otro ángulo interesante a considerar es el coste. Como suele ocurrir con los servicios gestionados, la disyuntiva está entre utilizar una solución estándar o diseñar, construir y mantener tu propia solución distribuida globalmente.

Como el borde está optimizado para la distribución global de contenidos, suele reducir los costes de las tarifas de salida. Sin embargo, el almacenamiento de datos en el borde debe distribuirse entre cientos de servidores de borde, lo que hace que el almacenamiento y las operaciones de datos parezcan más caros que los servicios regionales en la nube, que suelen replicar los datos sólo en 2 ó 3 zonas de disponibilidad.

Veamos algunas cifras, centrándonos en el almacenamiento clave-valor para 3 servicios de borde (CloudFlare Workers KV, Fastly KV, CloudFront KeyValueStore) y 2 servicios en la nube (Redis sin servidor en AWS y DynamoDB bajo demanda en AWS):

* para cada KB 

** los primeros 25 GB son gratuitos

Algunas diferencias y observaciones interesantes:

1. CloudFlare no cobra por la transferencia de datos, pero las operaciones de borrado cuestan lo mismo que las de escritura.
2. Fastly no cobra por las operaciones de borrado, pero estás limitado a 250.000 escrituras y 5 millones de lecturas al mes (a menos que pagues por un complemento).
3. CloudFront KeyValueStore parece locamente optimizado para las lecturas, pero las escrituras son increíblemente caras en comparación con las otras opciones.
4. Redis parece bastante barato, pero tienes que tener en cuenta que cuesta 0,0038 $ por KB, así que si estás leyendo o escribiendo 5 KB, será 5 veces más caro (lo cual sigue siendo bastante barato).
5. DynamoDB no es sólo un almacén de valores clave, pero sin duda puede utilizarse de ese modo, y sigue pareciendo un orden de magnitud más barato que los servicios de borde.

Aunque los servicios en la nube puedan parecer más baratos, es crucial tener en cuenta que no funcionan por defecto a escala mundial. Puedes activar DynamoDB Global Tables o Amazon ElastiCache Global Datastore (aunque no es compatible con ElastiCache sin servidor, por lo que también tendrás que administrar varios clústeres).

Por ejemplo, si activas las Tablas Globales de DynamoDB en 10 regiones, el coste de escritura y almacenamiento se multiplica por 10, por lo que se convierte en 7,60 $ por 1M de escrituras y 3 $ por 1GB/mes. Eso ya es más caro que las alternativas de borde y sólo para 10 regiones (en comparación con los cientos de servidores de borde).

Casos prácticos reales de Edge Computing

Entonces, ¿qué se puede hacer realmente en el borde? Hay muchos casos de uso interesantes, y espero que este artículo te ayude a determinar cuál tiene sentido para tu producto.

Algunos ejemplos:

• Autenticación: Implementar CAPTCHA basado en el borde, autenticación sin contraseña o validación JWT puede reducir la carga del origen al realizar operaciones sin estado en el borde que no requieren acceso a la base de datos u otros recursos del origen.
• Recogida de datos: Intégrate con fuentes o destinos de datos externos, descargando el seguimiento del lado del cliente y del lado del servidor al borde para evitar pesados SDK en los navegadores o cuellos de botella de rendimiento en el servidor.
• Enriquecimiento geográfico: Mejora tu sitio web con contenido "cerca de ti" almacenado en el borde, implementa redireccionamientos localizados (/en -> /fr ), geofencing o estrangulamiento por país utilizando APIs de geolocalización.
• Personalización de contenidos: Almacena y muestra en el borde artículos vistos recientemente o productos recomendados, implanta muros de pago para contenidos premium, o utiliza pruebas A/B para ofrecer contenidos personalizados y contextualizados, minimizando la complejidad en el origen.
• Optimizaciones SEO: Manipula las cabeceras HTTP y las respuestas HTML directamente en el borde para aplicar políticas personalizadas de almacenamiento en caché, cosido de contenidos o algoritmos de compresión ad hoc.
• Seguridad: Integra WAFs (Web Application Firewalls) personalizados o implanta cabeceras secretas y lógica de control de acceso personalizada.

O podrías diseñar un producto completo o un conjunto de productos que funcionen casi totalmente en el borde, exactamentelo que estamos haciendo en Edgee.

Para llevar

Espero que este artículo haya aclarado que las CDN ya no se limitan al almacenamiento en caché y a la protección DDoS: ahora proporcionan una gran cantidad de servicios valiosos para los desarrolladores. El borde es una nueva forma de crear aplicaciones o integrar nuevas funciones manteniendo el origen rápido y sencillo.

WebAssembly tiene mucho potencial, no sólo para el navegador, sino también para la ejecución binaria del lado del servidor y del borde. 

La nube está aquí para quedarse, y el borde complementa sus limitaciones permitiendo la creación de aplicaciones distribuidas globalmente con latencia y coste optimizados. Mi recomendación personal es diseñar y construir arquitecturas que tengan en cuenta los costes, ya que es una habilidad clave para convertirse en un desarrollador o arquitecto más eficaz.