Top
¿Y qué tal si no necesitáramos servidores de backend para desplegar nuestras aplicaciones? Parte I – Blog Ceiba
fade
219
post-template-default,single,single-post,postid-219,single-format-standard,eltd-core-1.1.2,flow-ver-1.4,,eltd-smooth-page-transitions,ajax,eltd-blog-installed,page-template-blog-standard,eltd-header-standard,eltd-sticky-header-on-scroll-up,eltd-default-mobile-header,eltd-sticky-up-mobile-header,eltd-menu-item-first-level-bg-color,eltd-dropdown-default,eltd-dark-header
Blog Ceiba / Arquitectura  / ¿Y qué tal si no necesitáramos servidores de backend para desplegar nuestras aplicaciones? Parte I

¿Y qué tal si no necesitáramos servidores de backend para desplegar nuestras aplicaciones? Parte I

Abstract

 

Las arquitecturas sin servidor son una tecnología naciente en los entornos de computación en la nube, más comúnmente llamada “arquitectura serverless”. Lo que se pretende es que los desarrolladores hagan una abstracción de la infraestructura con el objetivo de que se concentren mejor en la lógica empresarial.

 

Es una plataforma que nos gestiona toda la ejecución, administración y costeo de nuestras implementaciones.
La apuesta es optimizar las aplicaciones de nube y minimizar el desperdicio de la infraestructura que las aplicaciones utilizan.
Trabajar con arquitecturas serverless posee muchas ventajas y desafíos para tener en cuenta, por ejemplo: el nivel de escalabilidad que las implementaciones pueden alcanzar el modelo de facturación, pero también debemos tener en cuenta la posible alta complejidad como desafío principal.

 

 

Introducción

 

La filosofía de “pagar por los recursos que se utilizan” ha sido el caballito de batalla en la guerra comercial de las diferentes nubes – Azure, AWS, Google y Otras – Ahora, teniendo en cuenta la constante búsqueda de optimizar los recursos que las aplicaciones en nube requieren, se ha creado intrínsecamente un nuevo atributo de calidad para definir arquitecturas para estas aplicaciones.
¿A qué nos referimos?, Nos referimos a que las arquitecturas de las aplicaciones basadas en nube, aparte de ser seguras, escalables, mantenibles y muchas otras “-bilidades-” también deben ser óptimas en el uso de los recursos que utilizan para aminorar la factura en términos de dinero.

 

Miremos la evolución de este nuevo “driver” de arquitectura:

 

Recursos en datacenters:

 

Anterior a la aparición de las nubes, las aplicaciones requerían instalarse y ejecutarse en costosos centros de datos, en este escenario la escalabilidad de una aplicación estaba limitada por los recursos disponibles en el datacenter. Los costos operacionales de un datacenter son muy elevados (no es tema de este artículo los detalles de estos costos).

 

Una aplicación ejecutándose en un datacenter necesita tantos recursos como los que demande la aplicación en su tiempo más crítico de operación para no ver comprometido su rendimiento y buena ejecución, pero ¿Qué pasa el resto del tiempo? Pasa que esos recursos están ociosos, no generan valor y son muy costosos para no estar prestando ningún servicio.

 

IaaS – Infraestructura como servicio

 

No me detendré mucho en este punto, básicamente lo que ganamos con IaaS es en que podemos empezar con datacenters no muy grandes y no muy costosos, aprovisionamos recursos de una manera más fácil y rápida según las necesidades de la aplicación, y además, nos libramos de costos indirectos. ¿Ventaja? No tenemos tanto hardware ocioso y si la aplicación lo requiere lo aprovisionamos cuando se necesite y lo reintegramos cuando no. ¿Resultado? Un aumento en la relación costo-beneficio entre el hardware y la aplicación que impacta directamente el ROI de la aplicación.
Igual se sigue teniendo en buena medida, hardware ocioso, pero no tanto como en un datacenter local. El ahorro es considerable pero se sigue desperdiciando hardware.

 

PaaS – Plataforma como servicio

 

A diferencia de IaaS, en PaaS no tenemos servidores virtuales para albergar varias aplicaciones en el mismo servidor, las aplicaciones no tienen recursos compartidos, están albergadas en contenedores (no estamos hablando de contenedores docker) con unos recursos bajos, pero cuando se requiere escalabilidad, por un aumento en la carga de la aplicación, se pueden instanciar más contenedores automáticamente y la aplicación escalará horizontalmente a medida que los contenedores aumentan.

 

La idea de tener contenedores con bajos recursos es que la aplicación consuma recursos en unidades más pequeñas (un contenedor puede tener 2 procesadores y 4Gigas de memoria) y escale en esas unidades según su carga. Pero por más pequeña que sea la unidad de contenedores, si la aplicación no tiene carga, digamos entre la 1:00am y las 6:00am, igual estamos desperdiciando capacidad de cómputo, solo que en una unidad más pequeña. Sin embargo, desperdicio es desperdicio.

 

Entonces, ¿Qué podemos hacer? ¿Cómo hacemos que una aplicación consuma exactamente los recursos que necesita, y si no tiene carga no nos genere costos?
Suena un poco loco, imaginemos poder tener o construir piezas de software que se ejecuten en algún lugar y que la plataforma de nube solo nos cobre lo que efectivamente se gastó esa ejecución de esa pieza de software (gasto en procesamiento, memoria, red, etc.) ¿No sería genial? No habría tiempos ociosos de hardware ni desperdicio, ahí sí pagaríamos por lo que realmente estamos usando.

 

¿Qué son las aplicaciones con backend “serverless”?

 

Las aplicaciones serverless son una nueva categoría de aplicaciones que se están abriendo camino con la explosión computacional de la nube. Son aplicaciones que no requieren servidores de backend para procesar peticiones, su backend está constituido por piezas de software que se instancian y ejecutan al momento de llegar una petición y al momento de retornar la información terminan y los recursos utilizados por esta pieza de software son liberados o entregados a la plataforma.

 

Las piezas de software que estamos mencionando las llamaremos funciones de servidor o simplemente funciones, son totalmente sin estado (stateless), si necesitamos persistir estado entre diferentes llamadas o entre diferentes funciones debemos utilizar un intermediario que nos maneje un cache distribuido.

 

Las aplicaciones serverless son aplicaciones hiper-escalables ya que su escalabilidad no depende de infraestructura o de recursos asignados, simplemente si hay 100 peticiones a una función, la plataforma de nube nos entregará 100 instancias de la función independientemente del hardware necesario, igualmente si hay 1.000 o 10.000 peticiones sobre una determinada función, y lo mejor si no hay peticiones no pagamos por hardware ocioso o por el contrario si hay una alta actividad en la aplicación pagamos por los recursos que se necesiten y no nos debemos preocupar por aprovisionamientos que limitan la escalabilidad. Realmente se paga por lo que se usa.
“En esencia, una aplicación serverless es evolución de los servicios en la nube, basados en PaaS, que abstraen las máquinas virtuales, los marcos de trabajo de la aplicación y las dependencias externas por medio de enlaces, de modo que los desarrolladores puedan centrarse simplemente en el código para implementar la lógica empresarial”1.

 

¿Qué es FaaS (Function as a Services)?

 

FaaS es el acrónimo acuñado por la comunidad de TI para describir la plataforma en nube que nos va a soportar todo el ciclo de vida de las funciones de servidor: despliegue, pruebas, instanciación, ejecución, entrega de resultados y por último, terminación y liberación de recursos.
Cada plataforma de nube como Microsoft Azure, Amazon AWS o Google Cloud, por citar un ejemplo, tienen su propia implementación de FaaS disponible para uso en producción en modo preview.

 

Las API´s de FaaS para cada plataforma tiene implementados diferentes SDK´s que pueden ser usadas desde muchos de los lenguajes disponibles en el mercado: C#, Java, Python, Node.JS, PHP e inclusive Powershell.
Es una plataforma que se encarga de gestionar los tiempos de ejecución y las dependencias, una ventaja considerable en ambientes mixtos, una ventaja que nos va a permitir conformar equipos de alto desempeño con diferentes habilidades y preferencias a utilizar una plataforma unificada.

 

Ventajas

 

Menor Time to Market: Debido a la abstracción de la infraestructura obtenida a través de una plataforma FaaS, los desarrolladores tienen el enfoque de generar mayor valor de producto enfocándose de una manera más eficiente en la construcción de la lógica de negocio de la aplicación y hacer entregas más rápidas de piezas de software de menor acoplamiento y menor complejidad.

 

De microServicios a nanoServicios: Debido a la alta granularidad que tendremos de la funcionalidad del backend, podemos considerar la descomposición de los microservicios en nanoservicios. Esta descomposición se convierte en un muy valioso aporte a los procesos de desarrollo y pruebas de las aplicaciones, ya que los desarrolladores, y en general todo el equipo, se van a centrar en piezas de software mucho más pequeñas y simples que se administran de forma separada de otros servicios relacionados.

 

Menor Total Cost Ownership: esta es quizás una de las mejores ventajas de utilizar FaaS y radica en que, al no existir infraestructura o sistemas operativos que administra los desarrolladores, aportan mucho más valor en sus desarrollos. Por otro lado, la granularidad de las funciones permite que las inversiones en Dev-Ops y mantenimiento se reducen considerablemente permitiendo redireccionar recursos económicos enfocándolos a dar más valor empresarial a las aplicaciones. La relación costo-beneficio se incrementa en valores considerables.

 

Modelo de facturación: con el modelo de facturación solamente por ciclos de ejecución, se evidencia tanto un ahorro de costos asociados a los recursos de procesamiento como una creciente densidad funcional, esto significa más funcionalidades por los mismos recursos de proceso. Optimización de recursos, donde solo se paga por el tiempo que el código está en ejecución.

 

Escalabilidad: dado que las funciones de servidor son instanciadas, ejecutadas y liberadas según la demanda, las limitaciones de escalabilidad con casi nulas. La plataforma en nube FaaS se encarga de la gestión de los recursos usados por estas funciones y proveen la infraestructura necesaria, “sin límites”, lo que nos va a permitir que en un momento dado hayan 10, 100, 1000 o más instancias de la misma función en ejecución según la demanda de los usuarios. Así, la aplicación con un aumento inusitado en las peticiones reaccionará adecuadamente.

 

 

Desafíos

 

Complejidad: debido a la filosofía serverless, las abstracciones de la infraestructura que simplifican muchas labores a los equipos de desarrollo, también requieren que se rediseñen los ciclos de integración continua (Continuous Integration – CI) y entrega continua (Continuous Delivery – CD). Realizar ciclos de CI + CD para aplicaciones web convencionales y su correspondiente administración resulta mucho más fácil de administrar que un conjunto de funciones que fueron creadas para una responsabilidad específica y sus correspondientes dependencias. En este nuevo escenario se hace necesario la utilización de alguna herramienta que permita mejorar la administración y monitoreo de la ejecución de cada función de servidor.
Herramientas: por ser una tecnología emergente, muchas de las herramientas para el desarrollo, pruebas automatizadas, depuración, publicación, administración y monitoreo, están todavía en desarrollo en una versión preliminar. La implementación de FaaS en las diferentes ecosistemas de nube y sus correspondientes portales de administración y monitoreo, también están en su versión preliminar que permite funcionalidades básicas de seguimiento.

 

Soporte: el cambio de paradigma a soluciones sin servidor es algo que no es trivial para una organización. El auge de las tendencias en Dev-Ops sumadas a las necesidades de entrenamiento, retará los estándares actuales de las compañías, se requerirá definir planes de mejora y capacitación para hacer frente a estos nuevos retos, sobre todo en cuanto a la administrabilidad y manejo de dependencias.
Optimización del tiempo de ejecución: debido a que ya no tenemos el control de la infraestructura en la cual van a ser ejecutadas nuestras funciones, las optimizaciones de ejecución que solíamos hacer en las aplicaciones tradicionales ya no estarán disponibles. Por ejemplo: administrar la cantidad de hilos de ejecución, asignar más o menos memoria, acceso limitado a disco, etc. Por eso, debemos potenciar la creación de funciones muy simples con una única responsabilidad para mejorar los tiempos de respuesta de nuestras aplicaciones.

 

 

Recomendaciones

 

Única responsabilidad: las funciones de servidor deben tener un único propósito, debemos apelar al principio S.O.L.I.D. de single responsability, esto con el objetivo de minimizar su tiempo de ejecución, minimizar el uso de referencias externas y propiciar un aislamiento para mejorar los procesos de CI + CD.

 

Operaciones consistentes: el mismo principio de los test, a iguales parámetros de entrada igual respuesta, una función no debe depender de la cantidad de llamadas que tiene, las respuestas deben ser igual para unos mismos parámetros independientes de la cantidad de ejecuciones simultáneas que existan.

 

Tiempos cortos de ejecución: la idea es que al tener responsabilidades únicas y piezas de software muy pequeñas, vamos tejiendo una red de alta densidad funcional que es verdaderamente óptima en funcionalidad, tiempo de respuesta y utilización de recursos.
Mínimas dependencias internas: entre menor sea el número de librerías que referenciemos, entre menor sea la cantidad de llamados externos que realicemos, mantendremos a la baja la complejidad y aseguraremos una ejecución más rápida. Recordemos que el tiempo de carga de la pieza de software debe ser ligero para disminuir los tiempos de latencia de las solicitudes.

 

Integración mediante enlaces: la escritura de servicios sin estado es una ventaja ya que no se ralentizan los procesos de carga ni ejecución, esto es una característica en común de todos los servicios de alto rendimiento. Se prefiere invocar otras piezas de software Invocar.
Piezas de software pequeñas: entre más pequeñas sean las piezas de software que construyamos para exponer como funciones de servidor, mejor rendimiento obtendremos, mejor escalabilidad y mejor aislamiento de responsabilidades.

 

Conclusión

 

Las aplicaciones basadas en arquitectura ”serverless” son nuevo tipo de aplicaciones pensadas para la nube; un ambiente totalmente abstraído con escalado infinito para la ejecución de código y pago exclusivamente por tiempo de ejecución de código.

 

Una aplicación serverless es tiempo de aplicación propicia para realizar emprendimientos cuando no se sabe aún el impacto de la idea.
“El proceso sin servidor proporciona una experiencia de proceso totalmente administrada (cero tareas administrativas), con escalado inmediato e ilimitado (cero configuraciones de escala), que reacciona a eventos (procesamiento en tiempo real). Esto permite a los desarrolladores desarrollar una nueva clase de aplicaciones que se escalan por diseño y, en última instancia, son más resistentes”2.

 

Bibliografía

https://msdn.microsoft.com/en-us/magazine/mt793269.aspx
https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=AzureFunctions
http://stackoverflow.com/questions/tagged/azure-functions
1 Tomado de https://msdn.microsoft.com/en-us/magazine/mt793269.aspx
2 Tomado de https://msdn.microsoft.com/en-us/magazine/mt793269.aspx

Jorge Moreno

Escrito por: Jorge Moreno

Me gusta investigar sobre cómo utilizar los nuevos conceptos tecnológicos en la solución de problemas de negocio, aficionado al IoT y los BlockChain.

No Comments

Comentarios