En la actualidad, las infraestructuras necesarias para la realización de grandes proyectos se han vuelto muy complejas, requiriendo un amplio conocimiento y un gran esfuerzo para una correcta instalación, configuración, gestión y mantenimiento.

Por ello, en esta nueva entrega de Inspiring Technology, nuestros Hunters se adentran en arquitectura serverless. Esta nueva forma de desarrollo de software utilizando servicios en la nube, centra el desarrollo de las partes específicas de la aplicación sin tener que preocuparse por gestionar una infraestructura de servidores con todo lo que ello conlleva.

Diversos proveedores de servicios en la nube, como AWS, Google y Azure, ofrecen todo tipo de servicios de forma totalmente gestionada. Un ejemplo son las bases de datos como servicio, en las cuales es el propio proveedor de servicios el que gestiona todos los aspectos necesarios para su funcionamiento: instalación, configuración, alojamiento, seguridad, mantenimiento... De esta manera, se permite su utilización para el desarrollo de aplicaciones sin tener que preocuparse por la infraestructura.

Además, también se ofrece la ejecución de funciones como servicio, de forma que una vez suministrado el código al proveedor de servicios, dicho código puede ser ejecutado cuando sea necesario. Gracias a esto los desarrolladores únicamente tienen que centrarse en desarrollar las partes específicas de su aplicación, lo cual lleva a una mayor velocidad en el desarrollo y eficiencia.

Ventajas e inconvenientes de la arquitectura serverless

Escalabilidad

Una de las mayores ventajas que ofrece la arquitectura serverless es que permite una gran escalabilidad horizontal. Ante un gran número de peticiones, el proveedor de servicios instancia más nodos de trabajo de forma paralela y automática. Pese a esto, hay que tener en cuenta que dependencias en servicios externos de terceros podrían suponer un cuello de botella.

Adicionalmente, permite la escalabilidad a cero, es decir: cuando no se usa un servicio en concreto no se mantiene en ejecución ninguna instancia del mismo, evitando el consumo innecesario de recursos.

Pago por uso

Otra gran ventaja es que, como los servicios únicamente se instancian cuando se utilizan, los proveedores de servicio facturan según el uso que se ha realizado.

De esta manera, si un mes no se ejecuta la aplicación, esta no generará ningún gasto. Sin embargo, si un mes ha habido un uso muy elevado, el coste aumentará conforme el uso, siendo más costoso que una solución on-premise cuando el uso es muy elevado.

Esto resulta especialmente beneficioso para aplicaciones que por su naturaleza poseen una carga de trabajo reducida durante ciertos periodos de tiempo.

Vendor lock-in

Un aspecto importante a tener en cuenta cuando se considera desarrollar una aplicación serverless es el de vendor lock-in. Este término hace referencia a la dependencia que se genera con un proveedor concreto.

Generalmente, cada proveedor de servicios ofrece sus propios servicios, teniendo cada uno de ellos funcionamientos, capacidades y configuraciones específicas. Al realizar un desarrollo con los servicios de un proveedor se genera una dependencia con los mismos, causando una gran complicación en el caso que se desee cambiar a otro.

Rendimiento

Mientras que el escalado a cero permite ahorrar costes, también puede llegar a ocasionar un gran impacto en el rendimiento en ciertas situaciones.

Cada vez que se ejecuta un servicio que no dispone de ninguna instancia en ejecución es necesario inicializarlo, instanciando, descargando el código necesario y preparando el entorno de ejecución, lo que aumentará considerablemente el tiempo de respuesta. Este problema se conoce como cold start.

Figura 1: Esquema de un cold start.

Para evitar este problema, realizamos ejecuciones secuenciales, que reutilizan el mismo contenedor, así esto solo afecta al tiempo de la primera ejecución dentro en un contenedor.

Figura 2: Esquema de prevención de un cold start.

OpenWhisk

OpenWhisk es una plataforma de código abierto que ofrece la ejecución de funciones serverless con una configuración mínima. Esta plataforma ofrece la opción de alojamiento on-premise mediante orquestadores de contenedores como podrían ser Kubernetes, OpenShift, y Docker Compose.

Figura 3: Logotipo Apache OpenWhisk.

Gracias a que cuenta con un alojamiento on-premise se obtiene un mayor control sobre el coste, junto con una gran independencia de los proveedores de servicios, permitiendo cambiar entre dichos proveedores sin complicaciones (se puede incluso no tener ningún proveedor si se tienen todos los servicios on-premise).

OpenWhisk requiere una infraestructura base para la gestión de la plataforma en sí, la cual consumirá una cantidad de recursos relativamente constante. No obstante, el consumo de recursos por parte de la carga de trabajo en sí será variable.

Figura 4: Diagrama de infraestructura OpenWhisk.

OpenWhisk funciona mediante un sistema orientado a eventos:

Desde un feed externo se genera un evento, como podría ser desde una petición HTTP, la modificación de una entidad en una base de datos o un mensaje en un bróker Kafka.

Este evento dispara una regla, la cual tiene asociadas unas acciones que se ejecutarán y generarán una respuesta en formato JSON.

Figura 5: Diagrama del sistema orientado a eventos de OpenWhisk.

OpenWhisk permite la definición de acciones en multitud de lenguajes de una forma sencilla. Respecto a la implementación de estas, se define una función que recibe un objeto JSON con los argumentos de entrada y devuelve otro objeto con el resultado de este.

Figura 6: Ejemplo de función con objeto JSON.

Para ejecutar una acción, se instancia un contenedor con el runtime asociado, donde se ejecuta, desechándose cuando esta haya finalizado. Así, únicamente se utilizan los recursos necesarios en cada momento. Además, permite la definición de acciones compuestas, formada por una serie de acciones que se ejecutarán de forma secuencial, donde los datos de salida de la función previa serán los datos de entrada de la siguiente.

Figura 7: Esquema de composición de OpenWhisk.

OpenWhisk puede escuchar multitud de feeds externos, ejecutando acciones definidas en respuesta a por ejemplo un commit en GitHub o un mensaje en Slack.

Figura 8: Diferentes funcionalidades de OpenWhisk

En este vídeo veremos como funciona OpenWhisk como una opción serverless:

¿Quieres saber más sobre Hunters?

Ser un hunter es aceptar el reto de probar nuevas soluciones que aporten resultados diferenciales. Únete al programa Hunters y forma parte de un grupo transversal con capacidad de generar y transferir conocimiento.

Anticípate a las soluciones digitales que nos harán crecer. Consulta más información sobre Hunters en la web.

Joan Galiana

Técnico de Software en Altia