Las arquitecturas y servicios serverless ya llevan un tiempo en el mercado, a pesar de ello, muchos no saben exactamente qué son, para qué sirven o si les son útiles para su estrategia, por lo que en este artículo trataremos de explicar la evolución de los recursos T.I. que llevaron al cómputo en la nube a la actual situación y cómo se le puede sacar ventaja a las funciones como servicio (Functions as a Service, FaaS).
Relacionado: [Webinar] Arquitectura de microservicios con Kubernetes en Amazon EKS
Evolución de los recursos de T.I.
Las arquitecturas evolucionan conforme los recursos de T.I. evolucionan, lo que ayer fueron servidores colocados en un rincón de las oficinas, hoy son instancias reservadas en la nube. La siguiente tabla muestra la manera en que los recursos han cambiado:
El centro de datos, ya sea local o proporcionado por un proveedor como un servicio, fue el primer paso hacia la nube tal y como la conocemos. Se extrajo el entorno físico de alojamiento y empezamos a escalar esos entornos con unidades de hardware. A medida que la virtualización evolucionó, comenzamos a alojar máquinas virtuales en entornos de nube. Extrajimos el hardware y utilizamos los sistemas operativos como unidad de escala. Poco después de esto, construimos entornos de alojamiento en la nube y se abstrajo el sistema operativo. Nuestra nueva unidad de escalado fue la aplicación. Pero este no fue el final del viaje, ya que ahora hemos pasado a las funciones o a la arquitectura sin servidores (Serverless).
Dependiendo del tipo de servicio de nube que contratemos, la responsabilidad sobre ciertos recursos podría recaer en nosotros o en el proveedor, es decir, que si tenemos nuestro centro de datos en localmente, la responsabilidad es completamente nuestra, pero si utilizamos IaaS, algunos recursos dejan de ser nuestro problema, para ser parte de las responsabilidades del proveedor. Con arquitecturas serverless la única preocupación que tendremos es sobre el servicio que ofrecemos y las funciones que desarrollemos, mientras que la aplicación, el sistema operativo, el servidor y la red son preocupación del proveedor.
La arquitectura serverless es posterior al SaaS, pero se coloca antes que SaaS en el gráfico porque en el caso del SaaS, los consumidores no controlan nada sobre la aplicación o su infraestructura, sólo sobre el servicio o el negocio en sí.
Arquitectura serverless.
Las funciones son la unidad de escala en una arquitectura sin servidores que abstrae el tiempo de ejecución del lenguaje. No hablamos de cuánta CPU o RAM o cualquier otro recurso que necesitemos para que una función se ejecute. Hablamos del tiempo que se tarda en ejecutar la función. Todas las demás métricas no deberían molestarnos. Escribimos nuestras funciones, las publicamos en la nube, y pagamos sólo por el tiempo que estas funciones se ejecutaron.
La arquitectura serverless no especifica estrictamente cuál debe ser técnicamente nuestra función. Es sólo una unidad de trabajo que queremos que se haga. Las funciones se pueden activar de muchas maneras. Puede ser un temporizador que ejecuta una función periódicamente, pero también puede ser una petición HTTP o algún evento en algún servicio relacionado.
Hay seis puntos relevantes a destacar en las arquitecturas serverless:
- Serverless se trata de ejecutar código back-end sin gestionar sus propios sistemas de servidor o sus propias aplicaciones de servidor.
- Los servicios serverless no requieren codificación en un framework o biblioteca específicos. Las funciones FaaS son aplicaciones habituales cuando se trata de lenguaje y entorno.
- Dado que no tenemos aplicaciones de servidor que ejecutar, la implementación es muy diferente de los sistemas tradicionales – nosotros cargamos el código al proveedor de FaaS, y éste hace todo lo demás.
- El escalamiento horizontal es completamente automático, elástico y gestionado por el proveedor.
- Las funciones en FaaS se lanzan mediante tipos de evento definidos por el proveedor.
- La mayoría de los proveedores también permiten que se activen funciones como respuesta a las peticiones HTTP entrantes, normalmente por medio de una puerta de enlace a una API.
Entonces, las funciones son ejecutadas en entornos que brinda un proveedor y las podemos ejecutar las veces que sean necesarias, sin embargo no son ideales para flujos de trabajo extendidos o tareas masivas De esto, podemos concluir que los flujos de trabajo a largo plazo y otras tareas masivas no son una buena opción para arquitecturas sin servidores.
Servicios de funciones.
Ya hay empresas que funcionan como un servicio. Aquí están algunos de ellos:
- Microsoft – Azure Functions
- Amazon Web Services – AWS Lambda
- IBM – IBM Cloud Functions
- Google Cloud – Serverless Computing
- Alibaba Cloud – Function Compute
- Auth0 – webtask
- Iron.io – IronWorker
- Planet Rational – webscript
Hay muchos otros servicios disponibles, y todos ellos se diferencian por sus capacidades técnicas e implementaciones.
Conclusiones.
La arquitectura serverless nos permite construir piezas de código que hacen algo útil, y al mismo tiempo, ejecutarse rápidamente sin consumir grandes cantidades de recursos del servidor. Esto no significa que FaaS sea útil sólo en escenarios pequeños. Aunque una función es una unidad pequeña, puede ser invocada millones de veces por segundo.
La verdadera pregunta es ¿qué funcionalidades deberíamos pasar de otros componentes, controladores o capas de nuestra aplicación a funciones serverless?
¿Tienes en mente comenzar a construir un proyecto serverless?
Inicia un chat con un especialista de Nubity, pueden ayudarte a definir una infraestructura que aproveche todas las ventajas de estar en la nube y ahorrar en el proceso. ¿Aún no estás en la nube? Nuestros especialistas pueden ayudarte a migrar arquitecturas heredadas a entornos híbridos o 100% de nube.
