En publicaciones anteriores analizamos el 5G desde la perspectiva de las redes: cómo ocurrieron sus implementaciones, qué implican y también cómo el MEC (Multi-access Edge Computing, edge computing de acceso múltiple) puede ayudar a los proveedores de servicios a implementar el 5G y alcanzar los niveles de desempeño que esta tecnología propicia.
Sin embargo, la forma en que la mayoría de las personas disfrutará del 5G no tiene que ver solo con las capacidades que sus redes teóricamente ofrecen, sino con el desempeño de las aplicaciones y dispositivos que se ejecutan en ellas.
Hoy cambiaremos de perspectiva y veremos el 5G desde el punto de vista de las aplicaciones.
Este artículo explorará varios aspectos de las llamadas aplicaciones modernas: ¿Qué significa ejecutarlas en el edge? ¿Cómo se crean? ¿Cuáles son sus posibilidades de implementación? ¿Cómo se ejecutan las aplicaciones serverless en la plataforma Azion a través de Edge Functions y de nuestra tecnología principal, Azion Cells?
Ejecución de aplicaciones en el edge
Hoy en día las aplicaciones y dispositivos nativos están impulsando ciudades, redes eléctricas y casas inteligentes, lo que ayuda a transformar sectores como el de la manufactura, el retail, la sanitaria o la automovilística, y el 5G está listo para atenderlos.
Una de las razones por las que las edge computing y el 5G funcionan tan bien juntos es su propósito de resolver los mismos problemas:
• Atender al batallón cada vez mayor de dispositivos móviles y de IoT, que no paran de crecer.
• La necesidad de intercomunicación entre las máquinas.
• El deseo de aplicaciones con cada vez menos latencia y más velocidad de carga.
Al llevar cargas de trabajo de la cloud al edge los desarrolladores pueden estar seguros de que sus aplicaciones y dispositivos podrán acceder a los datos con la máxima eficiencia, velocidad y rentabilidad.
Sin embargo, implementar la edge computing no significa sustituir a la cloud computing. El informe State of the Edge 2020 publicado por Linux Foundation prevé que habrá un gasto de capital de unos 700 000 MUSD durante la próxima década para crear centros de datos e instalaciones de edge y que hasta el 2028 se espera que el consumo energético colectivo de estas instalaciones alcance los 102 000 MW, siendo que dichos megavatios no estarán ubicados centralizadamente como en las empresas de cloud.
Las infraestructuras de edge y los centros de datos priorizarán la proximidad por encima de la dimensión, al repartir el poder de cómputo y el almacenamiento por medio de los centros de datos distribuidos globalmente para llegar más rápido a los usuarios finales.
Sin embargo, la edge computing no reemplaza la computación en la nube sino que la complementa.
Evolución del desarrollo de las apps
En el pasado si querías construir una aplicación necesitabas tener tus propios servidores y, dado que no había forma de hacer que estos delimitaran diferentes aplicaciones, alojar varias de ellas en el mismo servidor era una pesadilla a la hora de controlar sus recursos y reforzar su seguridad. Por eso cada aplicación necesitaba su propio servidor, lo que era increíblemente caro y además dejaba muchos recursos ociosos.
La virtualización resolvió este problema al aislar las aplicaciones en MV (Virtual Machines, máquinas virtuales), permitiendo que múltiples aplicaciones se ejecutaran en la misma CPU del servidor y llevando a un mejor aprovechamiento de los recursos, menos costos de hardware y más escalabilidad.
Las MV son emulaciones de sistemas informáticos. Cada MV contiene no solo una aplicación sino también, de modo separado, varios sistemas operativos propios.
Para ahorrar energía y costos —dos de las grandes preocupaciones con relación a las aplicaciones 5G— las MV se detienen cuando la aplicación no está en ejecución y se reactivan cuando se vuelve a ejecutar.
Por otro lado, reactivar una MV lleva apenas unos minutos. Esto significa una gran mejora comparado con los meses que se tarda en poner a funcionar un nuevo servidor, pero hacer funcionar MV solo es efectivo para escalar y manejar patrones de uso de grandes dimensiones, hacer esto entre cada solicitud sería desastroso.
Los usuarios de hoy abandonan una página web que tarde unos segundos más que otra en cargar, y no hablemos ya de la gran necesidad de baja latencia que exigen las aplicaciones de última generación. Además, las MV no se han creado para manejar la complejidad de las aplicaciones modernas, que dividen las funcionalidades en componentes pequeños e independientes llamados microservicios.
Cada microservicio se diseña con un solo propósito. Por ejemplo, Facebook tiene diferentes microservicios tales como chats, grupos o proveedores externos de pago. De ese modo, sin ocupar demasiado espacio en un único servidor las empresas pueden:
- Distribuir el trabajo de modo más efectivo.
- Agregar recursos.
- Corregir problemas rápidamente.
- Separar procesos en varios servidores.
Por otro lado, debido a que las MV están estrictamente segmentadas entre sí, cada microservicio debe alojarse en una MV separada, lo que genera los mismos problemas de dimensionamiento y uso de recursos que ellas mismas deberían resolver.
Aunque, en definitiva, para construir, implementar y dimensionar aplicaciones de manera eficiente y rentable para 5G los desarrolladores deben recurrir a otras soluciones modernas y ágiles como los contenedores o las arquitecturas serverless.
Arquitectura basada en contenedores
Los contenedores son un medio más ágil de utilizar la virtualización. También son mucho más rápidos de implementar que las MV y tardan segundos en ejecutarse, no minutos.
En lugar de empaquetar cada aplicación (o peor aún, cada microservicio) en su propio sistema operativo, los contenedores tienen propiedades de aislamiento que viabilizan la distribución de sistemas operativos en compartimentos.
Cada microservicio obtiene una parte separada de la CPU, la memoria y el espacio en disco, lo que resulta en una unidad completamente funcional que se puede implementar y gestionar de forma independiente. Sin embargo, la gestión de contenedores es una tarea complicada que sería muy frustrante e ineficaz si se quiere realizar manualmente.
Para evitar estos dolores de cabeza, muchos desarrolladores usan Kubernetes, una plataforma abierta para gestionar cargas de trabajo y servicios contenedorizados. Este orquestador de contenedores garantiza que las aplicaciones funcionen correctamente aun cuando se agregan o sustituyen microservicios.
Arquitectura serverless
Las aplicaciones serverless son mucho más livianas que los contenedores, ya que distribuyen las aplicaciones en funcionalidades alojadas por un proveedor (irónicamente, en servidores).
En vez de hospedar el código y todas sus dependencias solo se almacena el código en sí y tampoco tiene que ejecutarse constantemente.
Las funciones se activan solo cuando es necesario, se implantan en milisegundos y el proveedor se encarga de todos los servicios de back-end y se cobra a los desarrolladores mediante un modelo de pago por uso (pay-as-you-go).
Este modelo es radicalmente diferente del modelo comercial de los contenedores o de otros métodos de implementación que necesitan de desarrolladores para aprovisionar los recursos.
Aunque los contenedores se pueden mover fácilmente e implementar en una nueva máquina en segundos, los desarrolladores deben determinar ellos mismos dónde se necesitan los recursos y pagar por ellos por adelantado.
En el lado opuesto, las funciones serverless no se dedican a un servidor en particular, de modo que el proveedor las puede aprovisionar de forma dinámica, ejecutando funcionalidades según la necesidad.
Serverless versus contenedores
Tanto los contenedores como las arquitecturas serverless son útiles para MEC porque requieren mucha menos infraestructura en comparación con las MV, lo que reduce los costos y aumenta la eficiencia. Además, ambas arquitecturas son útiles para las aplicaciones actuales ya que se dividen en componentes menores. Sin embargo, cuando se trata de escalabilidad, eficiencia, costo, facilidad de uso y seguridad, existen varias diferencias entre ellos.
Serverless
Las arquitecturas serverless son más livianas que los contenedores, lo que permite fragmentar aún más las aplicaciones en funcionalidades individuales.
Su implementación es más rápida, ya que lleva milisegundos en vez de segundos, lo que permite a los desarrolladores escalar o atender grandes picos de solicitudes instantáneamente, al crear nuevas funcionalidades y parches de inmediato, lo que conserva recursos por el hecho de poder iniciar y detener funcionalidades para entregar las solicitudes solo cuando sea necesario.
Además, su gestión de back-end la efectúa el proveedor serverless, lo que permite a los desarrolladores concentrarse en la utilidad de la aplicación y asegurar que no pagarán por lo que no usen.
Por último, los costos iniciales se ven significativamente reducidos, ya que los desarrolladores no tienen que pagar por los recursos utilizados antes de su implementación.
Contenedores
En relación con la arquitectura serverless, los contenedores brindan a los desarrolladores más control.
Una vez que el código está empaquetado con todas sus respectivas dependencias es posible determinar idiomas y bibliotecas por cuenta propia, lo que facilita la migración de aplicaciones de proveedores de cloud.
Este control sobre los servicios de back-end también evita la posibilidad de ser bloqueado por algún proveedor en específico.
Y a diferencia de las funciones serverless, los contenedores se ejecutan de modo constante, lo que los hace mejores para procesos largos. De ese modo, dependiendo del proveedor se puede asegurar un desempeño más confiable para algunos casos de uso específicos. Finalmente, los contenedores pueden brindar más seguridad que la arquitectura serverless si el proveedor está hospedando códigos de múltiples clientes en un mismo servidor y no adopta medidas para evitar la exposición de datos entre ellos.
Soluciones serverless para la próxima generación de aplicaciones
Con relación a la próxima generación de aplicaciones, cuando comparamos los beneficios entre contenedores y la arquitectura serverless, es importante considerar lo que se necesita para el MEC y el 5G.
Las aplicaciones deben ser extremadamente livianas para que puedan ejecutarse en infraestructuras de edge y centros de datos.
A su vez, las aplicaciones para 5G requieren alta movilidad y ser ejecutables con baja latencia y desempeño constante desde cualquier lugar. Además deben operar y escalar con bajo costo, considerando la gran cantidad de datos que se procesarán y transmitirán.
La seguridad también es un factor extremadamente importante, ya que sectores como el de la salud se beneficiarán del 5G y el MEC lo que permite, por ejemplo, el intercambio de datos médicos entre pacientes y profesionales de salud de modo instantáneo.
Al tener en cuenta estas consideraciones, la tecnología serverless ofrece también varias ventajas sobre los contenedores: consume menos recursos, es más rentable y funciona en todas partes, con una implementación y escalado en milisegundos. Sin embargo, comparada también con los contenedores, la tecnología serverless puede experimentar caídas de desempeño con arranques en frío y cuando se aloja más de un código de cliente en el mismo servidor puede generar problemas de seguridad.
Arquitectura serverless sin desventajas
Nuestra solución serverless Edge Functionsde Azion brinda las ventajas de la tecnología serverless sin sus desventajas de arquitectura.
Prevenimos problemas de seguridad serverless a través del sandboxing, que proporciona un entorno seguro para ejecutar funciones incluso cuando hay muchos inquilinos alojados en el mismo servidor (por ejemplo, más de un cliente).
Los procesos que pasan por sandbox operan por separado para que cada fragmento de código no afecte ni interactúe con los demás. Además, nuestro stack de software utiliza Chrome V8, el motor de JavaScript de código abierto de Google que optimiza la ejecución de JavaScript y garantiza que el sandboxing no afecte el desempeño.
Y más: nuestra principal tecnología Azion Cells bloquea el arranque en frío, lo que garantiza que el código se ejecute sin problemas en todo momento.
En la próxima publicación veremos a fondo el stack de software de Azion para mostrarte las decisiones que tomamos para asegurar que nuestra plataforma serverless brinde más desempeño, seguridad y flexibilidad.
