Serverless Computing: la arquitectura del futuro para los líderes de IT

La arquitectura sin servidor es el futuro inevitable para los líderes de IT. El Serverless Computing está en el punto de mira de los CIO por los avances que se han producido en el ámbito del cloud y las numerosas ventajas que puede aportar. 

Los principales actores del sector tecnológico se están moviendo hacia plataformas cloud. El proveedor de la nube puede aprovisionar y administrar los principales recursos informáticos. Como toda novedad, conlleva muchas promesas de felicidad y algunos riesgos. 

Hablamos de Serverless con Vicenç García-Altés, Technical Coach en Voxel Group y con una dilatada experiencia en desarrollo de software en ámbito académico y en el mundo del negocio.  Vicenç es responsable del curso “The Serverless Course” que se impartirá el 24 y 25 de octubre en Barcelona, hosted by Runroom.

Hola Vicenç, encantados de tenerte aquí. Serverless está en boca de todos, con mucho entusiasmo y, como toda novedad disruptiva en el entorno tecnológico, algunos miedos y dudas. 

Empezamos por lo más básico: ¿qué es Serverless?

Serverless es un nuevo modelo de computación en el que delegamos mucho trabajo a nuestro proveedor cloud. Nosotros, en su mínima expresión, sólo nos encargamos de codificar nuestra lógica de negocio en una pequeña función. La plataforma se encargará de llamar a esa función cuando suceda un evento que hayamos configurado (una llamada desde una API, un nuevo fichero en el storage, un nuevo mensaje en una cola). La plataforma también se encargará de otras cosas más avanzadas como el auto escalado. Eventualmente, nuestra función puede llamar a otros servicios manejados. Nosotros no nos encargaremos de los servidores, sistemas operativos, etc, lo hará el proveedor cloud por nosotros.
 

¿Cómo y cuándo descubriste la existencia (y la importancia) de esta arquitectura? 

Yo estaba trabajando para una gran cadena de supermercados en UK. Uno de los equipos decidió que montarían un gran cluster en Kubernetes para hostear cualquier aplicación de cualquier equipo. Después de más de ocho meses no tenían nada funcionando. Nuestro equipo, en cambio, decidió explorar maneras de producir valor de forma más rápida posible y una de las cosas que exploramos fue AWS Lambda. En menos tres meses ya teníamos el primer proyecto en producción. Las últimas noticias que tengo es que ahora tienen unas 200 lambda en producción.

¿Cuáles son las ventajas de Serverless computing?

Pues la lista es larga :D Podemos separarlas entre las ventajas para el desarrollador y ventajas para el negocio. Para el desarrollador las principales ventajas son que se despreocupa de muchas cosas. Por el hecho de usar funciones se despreocupa de cosas como parchear servidores, sistemas operativos, auto escalado, capacity planning, etc. 

Desde el punto de vista del negocio, al ser una tecnología con la que desarrollamos a más velocidad, mejoramos el time to market y la facilidad de experimentación e innovación. También tiene un gran impacto en los costes, pero creo que de eso ya hablaremos luego.
 

¿Podemos decir que una arquitectura Serverless tiene un impacto menos crítico en en medioambiente? ¿Se podría plantear como una solución para los grandes clusters con un montón de servidores que requieren mantenimiento y funcionamiento constantes?

Si, claro. Lo que es interesante aquí es lo que Ben Kehoe llama el mindset Serverless. Ben imagina Serverless como una escalera en la que se pueden ir subiendo escalones indefinidamente. Pasar de máquinas virtuales on-premise a máquinas virtuales en la nube es un pasito en esa escalera. Utilizar una plataforma PaaS es otro pasito. Y así indefinidamente. Por cada decisión tecnológica que tomamos (el sistema de colas, el sistema de storage, donde hosteamos la API, etc) nos debemos plantear en qué escalón de la escalera estamos y mirar si vale la pena subir algún escalón más.

En este caso, esto se traduciría en evidentes beneficios para las empresas que lo están adoptando. ¿Es así? 

Bueno, esto depende mucho del contexto. Si les dices a los de Stack Overflow que les iría mejor prescindir de sus servidores on-premise seguramente te dirían que no. Pero como norma general, yo creo que sí. Dejemos hacer a los proveedores cloud aquello que hacen mucho mejor que nosotros y centrémonos en intentar aportar valor con nuestro código.

¿Cuál es el aspecto más crítico de prescindir de un servidor? 

Hay una cierta pérdida de control que nos puede poner un poco nerviosos. Si el cloud provider tiene un problema en el servicio que nosotros utilizamos, no podremos hacer nada para arreglarlo. En general esto no debería representar un problema porque el proveedor cloud seguramente tenga SLAs mucho mayores que las que tenemos nosotros. En cuanto a Serverless, hay cosas que, más que complicarse, se tienen que hacer diferentes, como pueden ser temas de observabilidad, chaos engineering, etc. Al final es una nueva manera de programar nuestras aplicaciones que trae algunos retos nuevos.

¿En qué tipo de proyectos podemos usar Serverless?

Quizá la pregunta debería ser: ¿en qué proyectos no podemos utilizar Serverless? Básicamente hay tres categorías de proyectos en los que no encaja tan bien. 

La primera son proyectos donde una latencia baja y constante sea vital, ya que los cold starts nos pueden jugar una mala jugada.

La segunda es proyectos donde tengamos un alto y constante throughput, porque los costes de correr la solución pueden ser bastante más altos.

Y la tercera son proyectos donde por alguna razón necesite una conexión permanente con el servidor.

¿Si como CIO o responsable del departamento de IT quiero empezar a hacer algunas pruebas, por donde empiezo? ¿Qué problema simple puedo testear para empezar a ver los beneficios del Serverless?

Hay muchas maneras, pero una bastante típica es pasar los crons que tengas a tu sistema a una lambda. Así es como empecé yo, y me parece una muy buena manera.

Hablemos de Serverless lock-in. Aparentemente el “bloqueo del servidor” se está convirtiendo en una gran preocupación entre las empresas, ya que migrar a la plataforma de otro proveedor parece conllevar un esfuerzo y costes considerables, además del miedo relacionado con el no tener la información ubicada en un servidor propio con la consecuente pérdida de control a nivel de seguridad.  ¿Crees que la preocupación es fundada? 

El vendor lock-in es algo de lo que se suele hablar, sí. Yan Cui tiene un buen artículo sobre esto. Hay muchos tipos de lock-in. Cuando escoges una tecnología, estás haciendo un lock-in sobre esa tecnología. Si utilizas Active Directory como servidor de identidad, estás haciendo un lock-in con eso. 

Como siempre, es bueno pensar en costes, y aquí hay dos costes a tener en cuenta: primero el coste de migración. ¿Cuánto me va a costar cambiar de proveedor en caso de que lo necesite? El otro coste a mirar es el coste de oportunidad. ¿Cuánto me va a hacer retrasar el intentar hacer algo lo suficientemente genérico? 

Lo malo de hacer algo válido para todos los clouds providers es que solo puedes utilizar el denominador común entre ellos, y no suele ser muy grande ya que no todos implementan los mismos servicios con las mismas características.

Por último, la gran pregunta a hacerse es: ¿Cuándo voy a necesitar cambiar de proveedor? Yo personalmente, no conozco ningún caso. Esto no quita que puedas (y debas) utilizar buenas prácticas arquitectónicas para aislar la lógica de tu negocio de la fontanería de tu plataforma.
 

A nivel de costes, Serverless es a priori más caro. ¿Crees que a la larga puede salir más rentable?

Bueno, no creo que a priori sea más caro sino todo lo contrario. Para la gran mayoría de productos será más barato. Pero hablar de costes es algo complicado y con bastantes implicaciones. Lo voy a intentar resumir lo mejor que pueda. El coste de una solución lo podemos separar entre el coste de tener la solución funcionando (lo que te va a cobrar el cloud provider), el coste de desarrollar esa solución y de mantenerla (coste de personas) y el coste de oportunidad.

Ya hemos comentado que desarrollar una aplicación Serverless puede ser, por el hecho de tener que preocuparnos de menos cosas, más rápido que otras soluciones. Por lo tanto tendremos un menor coste de oportunidad.

El hecho que la plataforma haga mucho por nosotros, hace que se necesite menos gente para desarrollar una aplicación. Seguramente verás bastante reducidos los perfiles llamados de DevOps. Esto hará que el coste en personal se vea reducido, y este es el mayor coste que va a tener un proyecto, en el 90% de las veces.

Por último está el coste de correr la solución. AWS lambda tiene una generosa capa de servicios gratuitos que harán que tus costes se vean reducidos.

Pero a parte de la reducción de costes, lo que es realmente interesante es que el modelo de pago, es de pago por uso. Nosotros solo pagaremos por lo que utilizamos, y cuando no utilicemos el servicio, no pagaremos un céntimo. Esto tiene muchas implicaciones a nivel financiero que se podrían resumir en que lo que antes eran gastos fijos pasan a ser gastos variables.

Hablemos de otra preocupación común a los departamentos de IT: el performance. ¿Cuál es tu experiencia?

Como hemos visto antes, si necesitas una latencia muy constante y muy baja, no deberías utilizar Serverless. Pero si, como en la gran mayoría de servicios, no es así, no hay ningún problema. El rendimiento de la plataforma es muy bueno y está en contínua mejora. Prueba de ello es que grandes empresas como DAZN o iRobot utilizan Serverless en muchos de sus sistemas client facing.

¿Por qué viste la necesidad de organizar The Serverless Course? ¿Qué podemos aprender en este curso?

El curso surge de la necesidad de resumir lo aprendido en estos años de estudio y desarrollo con esta tecnología para que el alumno tenga una rápida adaptación a la misma. La idea del curso es proporcionar los conocimientos y herramientas para que el día después del curso puedan iniciar un proyecto con esta tecnología y ser totalmente productivos. 

Lo que podemos aprender se podría resumir en:

• Cómo desarrollar, testear y desplegar una aplicación Serverless utilizando AWS Lambda, el framework Serverless y NodeJS
• Estrategias de testing de aplicaciones Serverless
• Logging y monitoreo
• Seguridad básica
• Integración continua
• Gestión de entornos

¡Muchas gracias, Vicenç, por tu tiempo y por dar respuesta a nuestros interrogantes sobre este tema tan complejo! 

Esperamos que esta entrevista te haya sido útil para entender las principales ventajas y riesgos sobre Serverless Computing.

Si quieres profundizar sobre este tema, The Serverless Course es tu curso.

¡Te esperamos en Runroom!