No es oro todo lo que reluce en serverless

Hoy en día la filosofía serverless (que reemplaza servidores por código) se ha convertido en una palabra pegadiza que utilizamos prácticamente para cualquier servicio, y que muchas veces (no siempre) se puede incluir dentro de PaaS (plataforma como servicio). La primera vez que se utilizó este término fue en 2012 en un  artículo  de Ken Fromm, vicepresidente de una empresa de business intelligence, así que curiosamente no proviene de ningún hiperescalar. A partir de entonces la popularidad del concepto fue creciendo y en 2014 se hizo viral, gracias al bombo que le dio Amazon en el lanzamiento de AWS Lambda, un FaaS (function as a service). ¿Fue Lambda el primer servicio serverless? No, el mérito le corresponde a Google gracias al servicio de alojamiento web App Engine, que lanzó en 2008 y fue anterior incluso al término que lo definía.  

A principios de año hablábamos de cómo el serverless iba a ser una de las tendencias clave de este 2019, y es que la sencillez que una empresa obtiene al delegar completamente la infraestructura y centrarse en la aplicación es digna de destacar. Durante los últimos años hemos visto esta palabra asociada a toda clase de servicios porque, aunque a priori se relacionaba con los FaaS  o funciones como servicio, su ámbito se ha ampliado a otros como bases de datos e incluso entornos completos para el entrenamiento de modelos neuronales en el ámbito de la inteligencia artificial.  

La filosofía serverless siempre se ha asociado a la nube pública y es que la promesa de poder escalar casi hasta el infinito sin tener que pagar mientras no haya “visitas” se orienta mucho a ello. En lo que muchos no habían reparado es que un servicio serverless no se asocia solo a la nube pública, sino a una nube pública en concreto.  

Mientras la tecnología IaaS y algunos PaaS disponen de mecanismos para evitar el temido vendor lock-in, en el mundo serverless este asunto no parece tan prioritario y vemos cómo la posible migración de una nube pública a otra supone una gran inversión al menos en tiempo, sin olvidar que en caso de querer llevarnos el proceso a una cloud privada habría que reconstruirlo.  

Portabilidad entre diferentes FaaS

Esta preocupación ha llevado a pesos pesados del mundo de la computación como Google, IBM o VMware a crear un estándar para facilitar la portabilidad entre diferentes FaaS. Este estándar se ha bautizado como Knative y se trata de un ambicioso proyecto abierto que seguro que dará mucho que hablar en los próximos años.  

Knative lleva la filosofía FaaS al sistema Kubernetes, lo que facilita enormemente la migración entre diferentes nubes. Se debe introducir todo el código necesario para una aplicación en un contenedor, configurar las reglas del juego a Knative y, a partir de ese momento, él se encarga de que el proceso esté siempre disponible, de escalarlo e incluso apagarlo cuando no exista tráfico.  

Knative es una tecnología bastante reciente pero ya cuenta con el apoyo de un servicio que lo utiliza íntegramente: Cloud Run de Google, que ofrece la despreocupación del mundo serverless y la ausencia de lock-in, ya que uno en cualquier momento puede coger el contenedor y el código Knative y llevárselo al Kubernetes de cualquier otra nube, incluso privada.  

Cuenta con un apoyo de la comunidad cada vez mayor, por lo que no sería extraño ver pronto una compatibilidad en los servicios de AWS y Microsoft Azure, entre otros. 

Imagen: Steve Corey