Llegamos a ustedes gracias a:



Columnas de opinión

¿Qué sigue para la arquitectura serverless?

Por: Brecht De Rooms, desarrollador senior en Fauna

[02/03/2020] Los servicios sin servidor o serverless están en todas partes. Las ofertas serverless, que son la fuerza impulsora detrás de una evolución hacia una nueva forma de programación, vienen en todas las formas, incluyendo las plataformas de alojamiento de aplicaciones, bases de datos sin servidor, CDNs, ofertas de seguridad, etc.

Las preocupaciones de configuración, escalado y aprovisionamiento de bajo nivel han sido eliminadas por las ofertas serverless, dejando a la distribución como la última preocupación. Aquí edge serverless proporciona una solución mediante la distribución de datos y el cálculo en/a lo largo de muchos centros de datos, y reduce la latencia al acercar los cálculos al usuario.

Edge sin servidor es la culminación de una evolución de las arquitecturas de nube que comenzó con la Infraestructura como servicio hace casi 15 años. La siguiente etapa de esa evolución será impulsar aún más la distribución de "building blocks sin servidory facilitar su consumo por parte de los desarrolladores.

Miremos más detenidamente dónde hemos estado y hacia dónde nos dirigimos.

Arquitectura en capas

Infraestructura como servicio (IaaS): La revolución de la computación en la nube comenzó en serio con la llegada de la Infraestructura como servicio. Con IaaS, las empresas podían trasladar su infraestructura local a una infraestructura "en la nube alojada, operar desde allí, pagar solo por las horas de almacenamiento y cálculo utilizadas, y no tener que instalar ni administrar ningún hardware o red.

Al principio, IaaS parecía caro, pero las compañías lo adoptaron muy rápidamente porque el tiempo de actividad estaba garantizado a un nivel con el que no podían competir, mientras que el precio de comprar y mantener su propia infraestructura, en la mayor parte de casos, superaba la oferta. La ventaja más importante fue que la nube eliminó el mantenimiento y el aprovisionamiento de hardware, lo que liberó a los desarrolladores y les permitió enfocarse en el valor comercial.

Plataforma como servicio (PaaS): Luego, los proveedores llevaron la computación en la nube un paso más allá y ofrecieron la Plataforma como servicio. En lugar de alquilar solo un servidor, una solución PaaS le alquila todo lo que necesita para crear una aplicación. Esto incluye no solo el servidor, sino también el sistema operativo, el entorno del lenguaje de programación, la base de datos y las herramientas de administración de la base de datos.

Mientras que el proveedor de IaaS lo convierte en el administrador de los servidores que alquila, el de PaaS se hace cargo de las tareas de administración del servidor, tales como la instalación de software o las actualizaciones de seguridad, e intenta anticipar los requisitos ambientales de su código. El objetivo de PaaS es proporcionarle una forma sencilla de implementar su aplicación y, yendo un paso más allá que IaaS, libera a los desarrolladores de las tareas de administración del sistema y les permite concentrarse en lo que más importa -la aplicación.

AWS Elastic Beanstalk, Google App Engine y Heroku son solo algunos de los proveedores que ofrecen PaaS al público.

Software como servicio (SaaS): El software como servicio generalmente se refiere a aplicaciones alojadas en línea que están disponibles a través de una variedad de suscripciones. Las aplicaciones operan completamente en la nube, y se accede a ellas a través de Internet y un navegador. En resumen, cada aplicación que se ejecuta en la nube y tiene un modelo de precios basado en suscripción es considerada una aplicación SaaS.

Hay dos tipos de aplicaciones SaaS, las que se centran en el usuario final y las que se centran en los desarrolladores. El último tipo tiene como objetivo proporcionar una base para otras aplicaciones. Gmail, Dropbox, Jira, BitBucket y Slack son ejemplos de aplicaciones SaaS que se centran en el usuario final, mientras que Stripe y Slaask exponen APIs que le permiten integrar su solución SaaS en su propia aplicación.

Contenedor como servicio (CaaS): Las plataformas de contenedores son la última encarnación de IaaS. En lugar de ofrecer server hosts completos, los proveedores de CaaS le permiten alojar sus servicios o aplicaciones dentro de contenedores, que administran en su nombre.

Los contenedores son más eficientes que las máquinas virtuales en la utilización de recursos de host subyacentes. Uno puede pensar en los contenedores como "máquinas pequeñas". Se inician rápidamente y se pueden ejecutar varias instancias en un solo servidor.

Los proveedores de CaaS ofrecen herramientas para desplegar contenedores en servidores y aumentar o disminuir el número de instancias de contenedores. Las ofertas más avanzadas administran por completo los servidores subyacentes, lo que le permite a su empresa centrarse en el código (o contenedores) en lugar de la infraestructura.

CaaS se ha convertido rápidamente en uno de los building blocks para PaaS y SaaS, dando como resultado una arquitectura en capas. Ha habido un cambio hacia el desarrollo de aplicaciones lo más alto posible en la pirámide. Muchas aplicaciones complejas siguen siendo una combinación de SaaS, PaaS y CaaS, ya que las plataformas disponibles no son lo suficientemente flexibles como para ofrecer todo lo que una necesita.

Muchas aplicaciones complejas son una combinación de SaaS, PaaS y CaaS.

Confiando lo más posible en SaaS, se libera de las preocupaciones de aprovisionamiento y escalabilidad. Para las demás partes, las empresas suelen recurrir a la ejecución de contenedores, lo que significa que todavía tienen problemas de configuración y aprovisionamiento.

Para reducir estas preocupaciones, se creó una quinta oferta para llenar los vacíos. Nació la arquitectura sin servidor o serverless.

Arquitectura serverless

Función como servicio (FaaS): FaaS le permite cargar y ejecutar código sin siquiera pensar en servidores, contenedores o en escalar. En ese sentido, supera los principios de facilidad de uso de las ofertas anteriores, pero también tiene limitaciones que son menos notorias en PaaS.

La mayor ventaja de FaaS es la escala. El escalado de FaaS se puede realizar con un menor nivel de granularidad que el de PaaS o CaaS, y no requiere configuración. Además, no paga por lo que no usa.

Granularidad: Las aplicaciones PaaS generalmente solo se escalan por aplicación, mientras que las aplicaciones creadas en CaaS solo se escalan por contenedor. Las aplicaciones FaaS se dividen en funciones separadas y, por lo tanto, se escalan por función. La desventaja es que a menudo requiere que reconsidere la arquitectura de su aplicación. En lugar de administrar una aplicación o unos pocos contenedores, se deben administrar muchas funciones que realizan tareas más pequeñas, algo que puede introducir mucho trabajo de orquestación.

Configuración: Normalmente tendría que configurar cuándo escalar (disparadores para escalar hacia arriba y hacia abajo) o establecer manualmente cuántas instancias de una aplicación o contenedor deben ejecutarse, pero FaaS no requiere que configure el escalado o que aprovisione recursos específicos.

Pay-as-you-go: En lugar de implementar contenedores (CaaS), por el que paga si es que el código se ejecuta activamente o no, las funciones solo incurren en cargos cuando se las llama. Este modelo de precios de pago por uso se está convirtiendo lentamente en el aspecto más importante de la definición de sin servidor.

Límites: En una aplicación típica, puede definir límites de memoria o límites de tiempo de ejecución para su código. Aunque los proveedores de FaaS le permiten configurarlos, existen límites superiores para garantizar que el proveedor pueda optimizar estos recursos de manera efectiva. Uno puede imaginar que sería mucho más difícil para un proveedor estimar cuántos servidores tienen que funcionar para usar de manera óptima sus recursos si las funciones pueden ser creadas con 10GB de RAM o ejecutadas durante unas horas.

Una nueva arquitectura edge

La arquitectura serverless eliminó las preocupaciones de aprovisionamiento y escalado, pero la distribución sigue siendo un problema difícil. Lo ideal es que nuestro código se ejecute lo más cerca posible del usuario final para reducir la latencia. Existen múltiples problemas con la forma en que hemos estado creando aplicaciones hasta hace poco:

Lógica de distribución: A menos que implemente sus funciones o contenedores en diferentes regiones, y usted mismo dirija al cliente hacia la función más cercana, esta permanecerá en un solo centro de datos.

Distribución de datos dinámicos: Distribuir la lógica sin distribuir los datos no va a cosechar grandes recompensas, ya que la latencia solo ha sido trasladada a una ubicación diferente. Su usuario puede estar más cerca del back-end, pero este último todavía está lejos de la capa de datos.

Costo, configuración, monitoreo: Es raro ver una aplicación que se distribuye a más de dos o tres regiones porque hacerlo generalmente conlleva un costo o configuración adicional, y requiere que monitoree sus funciones o contenedores en múltiples regiones.

La próxima evolución en serverless es impulsar aún más la distribución y entregarla sin necesidad de configuración. Esto significa que nuestra lógica y datos serán distribuidos en muchas regiones del mundo, minimizando la latencia para nuestros usuarios finales.

CDN y Jamstack: Ya hemos estado utilizando la forma más básica de un servicio que proporciona distribución automática, se llama red de distribución de contenidos o CDN. Algunas mentes brillantes, en compañías como Netlify y Zeit, vieron que la distribución automática ya podría lograrse pregenerando su aplicación tanto como sea posible y gestionando las partes dinámicas con funciones serverless y SaaS APIs/APIs SaaS.

Este enfoque, acuñado "Jamstack" por Netlify, ha ido ganando popularidad rápidamente porque las redes de distribución de contenido ofrecen la primera experiencia de lo que podría ofrecer una arquitectura edge. Por supuesto que hay limitaciones para un Jamstack que está basado únicamente en el renderizado del lado del servidor. Por ejemplo, las compilaciones deben activarse para el nuevo contenido entrante. Esto hace que sea muy difícil aplicar este enfoque a sitios web altamente dinámicos que tienen tiempos de compilación significativos.

Los sitios web altamente dinámicos desafían los Jamstacks basados en el renderizado del lado del servidor, porque las compilaciones deben ser activadas para nuevo contenido.
Serverless

Las compilaciones incrementales y los conceptos como client-side hydrtaion ofrecen soluciones parciales a este problema, pero al fin y al cabo queremos que nuestros sitios web complejos tengan las ventajas de ambos mundos: (muy) bajas latencias para nuestros usuarios finales y nuevo contenido al que se pueda acceder de inmediato.

El auge de los servicios distribuidos: Venimos de una arquitectura en la que el front-end se comunica con el back-end y este a su vez, con la base de datos y otros servicios. El back-end y la base de datos a menudo son escalados juntos para mantener baja la latencia entre estos. La distribución es posible, pero a menudo engorrosa y, por lo tanto, limitada.

La distribución del back-end y la base de datos es posible, pero a menudo engorrosa y, por lo tanto, limitada.
Serverless

En futuras arquitecturas, las ideas de Jamstack se llevarán a un nuevo nivel mediante el uso de otros servicios distribuidos. Cada uno de estos será una red distribuida cuyos nodos no necesariamente tendrán que vivir en el mismo centro de datos que otros servicios. Para reducir la latencia a un mínimo absoluto, el modelo de seguridad debe ser repensado para permitir que el front-end se comunique con la base de datos y otras redes de servicios.

Las futuras arquitecturas de las aplicaciones aprovecharán las redes de servicios distribuidos, las redes de bases de datos distribuidas y los back-ends serverless distribuidos.
Serverless

Echemos un vistazo a los servicios que contribuyen a hacer esto posible.

Redes de servicios distribuidos: Muchas plataformas SaaS, como Algolia y SendGrid, tienen como objetivo convertirse en los building blocks para otras aplicaciones. Desarrollan servicios específicos que eliminan preocupaciones específicas de las aplicaciones típicas de back-end. Algunos de estos están evolucionando para convertirse en servicios distribuidos, como Algolia, que se autodenomina red de búsqueda distribuida (DSN). Le seguirán muchas otras plataformas SaaS y es probable que pronto hablemos de las redes de servicios distribuidos como la próxima evolución de las aplicaciones SaaS.

Bases de datos distribuidas sin servidor: Las bases de datos como Azure Cosmos DB, Google Cloud Spanner y FaunaDB están adoptando el modelo serverless de pago por uso y proporcionan una distribución lista para usar con algún tipo de garantía ACID. Algunas bases de datos ofrecen capas de seguridad y APIs GraphQL nativas que pueden ser consumidas de forma segura por las aplicaciones del cliente y que funcionan bien con un back-end serverless. Las capas de seguridad hacen posible que las interfaces de usuario interactúen directamente con la base de datos en lugar de únicamente con un back-end. Lo ideal es que una aplicación front-end pueda comunicarse con una base de datos distribuida globalmente con bajas latencias y garantías ACID, como si esta se estuviera ejecutando localmente.

Edge computing distribuidasin servidor: Nuevas funciones serverless, como Cloudflare Workers y StackPath Serverless Scripting, están empujando las funciones sin servidor al edge. Su objetivo es llevar las funciones lo más cerca posible del usuario final para reducir la latencia a un mínimo absoluto. Cloudflare Workers tienen 194 puntos de presencia, mientras que StackPath tiene más de 45 ubicaciones.

¿Por qué esta nueva arquitectura de vanguardia está cobrando impulso ahora? Cuando consideramos la evolución de esta transformación de IaaS a edge serverless, siempre nos ha frenado un obstáculo: ¿Cómo manejar los datos dinámicos? Aunque hemos tenido servicios como Amazon S3 para alojar datos relativamente estáticos, las bases de datos reales han tenido problemas para entregar una experiencia serverless. Eso se debe a que es increíblemente difícil crear un sistema distribuido que sea considerablemente consistente

Los building blocks serverless en la nube funcionan como Legos. Los desarrolladores pueden combinar los que necesitan y dejar de preocuparse por la escala o la distribución.
Serverless

Hoy en día, tenemos bases de datos serverless con seguridad incorporada que abren la puerta a una nueva generación de aplicaciones -unas que, por defecto, se escalan, de una manera globalmente distribuida. Desde que se abrió esa puerta, muchos desarrolladores han comenzado a buscar formas de reemplazar partes de su back-end con microservicios y APIs, abriendo un nuevo mercado para muchos proveedores de SaaS.

El resultado final será un ecosistema de building blocks que funcionan como Legos. Pronto los desarrolladores combinarán los que necesitan y dejarán de preocuparse por la escala o distribución.

Brecht De Rooms es desarrollador senior en Fauna. Es un programador que ha trabajado ampliamente en TI como desarrollador e investigador full-stack en los mundos de los startups y la consultoría de TI. Su misión es echar luz sobre tecnologías emergentes y potentes que faciliten a los desarrolladores la creación de aplicaciones y servicios que cautiven a los usuarios.