Edge Computing o cómo afrontar nuevos retos en Cloud.

En los años 90 estuvieron en auge las arquitecturas de tres niveles. Durante la transición del modelo cliente servidor a arquitecturas distribuidas, los líderes de la industria defendieron un patrón donde la interfaz, la lógica de negocio y las bases de datos debían estar estructuradas en capas diferentes.

Esta es la arquitectura de tres niveles con la que hemos estado tan familiarizados en el mundo J2EE. Ahora, en el apogeo del Cloud Computing, estamos habituados a arquitecturas muy parecidas en las que los datos se transfieren a una localización centralizada donde son procesados y luego son enviados de vuelta al solicitante.

Pero existen situaciones en las que este modelo no sirve. Por ejemplo, ¿qué pasa si los datos generados que hay que transferir son muy grandes? Pues está claro que aumentará el tiempo para procesarlos y la latencia para almacenarlos o recuperarlos de la nube.

Esto, en muchos casos, puede penalizar el rendimiento de las aplicaciones impactando negativamente en el negocio.

Para dar solución a estos problemas surgen nuevos paradigmas de computación en la nube como el Edge Computing.

El principal objetivo de este modelo es acercar el procesamiento a las fuentes de datos, reduciendo la cantidad de datos transferidos. Cada localización de borde reproduce la nube pública exponiendo un conjunto de servicios compatible y unos endpoints que las aplicaciones pueden consumir.

En este tipo de arquitecturas, cada unidad de Edge Computing tiene su propio conjunto de recursos: CPU, memoria, almacenamiento y red. Con ellos realizarán una función concreta, además de encargarse de gestionar la conmutación de la red, el enrutado, el balanceo de carga y la seguridad. En este clúster de dispositivos Edge Computing se ingestarán multitud de datos provenientes de una variedad de fuentes.

Para cada dato se decidirá el camino por el que se procesa de acuerdo a un conjunto de políticas y reglas predefinidas.

Puede ser procesado localmente o enviado a la nube pública para un procesamiento posterior. Los datos “calientes” que puedan ser críticos serán analizados, almacenados y procesados inmediatamente mediante la capa de Edge Computing.

Mientras que aquellos datos más “fríos” se transfieren a la Cloud pública para realizar, por ejemplo, analítica a largo plazo.

Erróneamente se piensa que sólo está pensado para IoT. Pero Edge Computing aborda muchos de los retos a los que nos enfrentamos cuando ejecutamos cargas de trabajo en Cloud.

Nos va a permitir mantener ciertos datos sensibles on-premise mientras seguimos disfrutando de las ventajas de la elasticidad que ofrece la Cloud pública. Además, reducirá la latencia de las comunicaciones.

Por todo esto, Edge Computing es la arquitectura perfecta para la ejecución de aplicaciones inteligentes dirigidas por datos. Y además también ofrece un valor enorme para aplicaciones departamentales y líneas de negocio más tradicionales.

Cuando hablamos de Edge Computing o de localizaciones Edge, aunque se traduzcan como “de borde”, no significa que estén alejadísimas al final de la red, todo lo contrario.

En una aplicación web, el camino que recorre una petición entre el usuario final y nuestro sitio estará compuesto de una serie de saltos por diferentes redes alrededor del mundo.

En la respuesta, así como en sucesivas peticiones, el camino puede ser ese u otro completamente distinto.

Cuando hacemos uso de una localización de borde lo que queremos es simplificar y acortar ese camino, poniendo nuestra aplicación mucho más cerca del usuario final.

Para facilitarnos esta tarea, Amazon pone a nuestra disposición, entre otros muchos servicios, Lambda@Edge. Con él podremos ejecutar nuestro código en las ubicaciones de borde que tiene AWS para responder a nuestros usuarios finales con baja latencia.

Lambda@Edge se utiliza junto con el CDN de AWS para llevar la lógica de las aplicaciones a los servidores de borde de CloudFront.

Funciona de forma totalmente transparente para nosotros, sólo tendremos que cargar el código de nuestras funciones Lambda (la plataforma FaaS de Amazon) y AWS se encargará de la gestión de la replicación, el enrutado y el escalado en HA para ubicarlo en la localización de borde más cercana al usuario final.

Entre los múltiples casos de uso de Lambda@Edge cabe destacar los siguientes:

• Reducir la latencia de las comunicaciones. Como veíamos al principio es una de las principales necesidades en las arquitecturas Cloud actuales. Además, ayuda a reducir el tráfico de datos y la invocación a otros servicios, por lo que ayudará también a optimizar costes.
• Personalización del contenido dinámico del site. Con Cloudfront resulta muy sencillo distribuir contenido estático desde S3 sin tener que preocuparse de desplegarlo y configurarlo en múltiples regiones alrededor del mundo. Con Lambda@Edge sucede lo mismo que con el contenido dinámico. Además, permite personalizarlo en función de la ubicación del usuario final, generar páginas al vuelo o devolver recursos especiales en función de la petición.
• Modificar las peticiones y respuestas. Permite realizar reescritura de las urls, controlar el acceso de usuarios en el borde, hacer Tests A/B, realizar redirecciones temporales, personalizar las cabeceras http o redireccionar a los visitantes de acuerdo a los atributos de las solicitudes (cookies, encabezados, etc.). También llevarles al origen óptimo en función de la proximidad, la ubicación de los datos, la información de sesión del usuario, etc.

Productos como Lambda@Edge están generando una gran expectación por las excelentes capacidades que ofrecen.

No solo ponen la computación serverless más cerca de los usuarios, sino que resuelven muchos problemas actuales de Cloud Computing. Están facilitando que se produzca una nueva transición en el modelo de computación hacia arquitecturas basadas en Edge Computing.

En este nuevo paradigma, las nuevas arquitecturas de software no tendrán nada que ver con los antiguos patrones de diseño de los 90, sino que estará estructurada alrededor de las tecnologías Cloud más innovadoras.