Un enfoque serverless

“En el futuro todo el código que escribiremos será lógica de negocio – Werner Vogels, CTO de Amazon”

¿Qué es serverless?

Detrás de este término con tan poca substancia se esconde uno de los últimos paradigmas revolucionarios en las tecnologías de la información. Se trata de un modelo de computación en la nube, y a la vez estilo de arquitectura, en el que los proveedores se hacen cargo del aprovisionamiento, escalado y gestión de gran parte de los recursos de infraestructura en el servidor. Y lo hacen como servicio.

Serverless – que todavía no tiene traducción aceptada en castellano – se diferencia de otras formas más tradicionales de computación en la nube como IaaS (Infrastructure as a Service) en que estos nuevos servicios gestionados abarcan varios niveles adicionales en la característica pila de infraestructura tecnológica. De esta forma, los proveedores se encargan de la gestión no solo del hardware y la virtualización, sino también de los sistemas operativos e incluso de los entornos de ejecución de las aplicaciones. Como resultado, sus usuarios solo tienen que escribir la lógica pertinente a su negocio.

Podemos ver serverless como una forma de outsourcing donde los recursos de computación para ejecutar aplicaciones (servidores, entornos de ejecución, middleware, bases de datos, colas de mensajes, etc.) son tratados como servicios básicos; casi como materias primas. Y lo más importante es que se paga solo por consumo.

Con serverless, la nube se convierte en un activo y el código de las aplicaciones en un pasivo. Una vez que abrimos una cuenta con un proveedor, tenemos a nuestra disposición un vasto catálogo de servicios que solo hacen incrementar en el tiempo. El conjunto de funcionalidades que nos ofrecerán estos servicios mañana será más amplio que el que te pueden ofrecer hoy, y lo hacen sin coste alguno para los clientes ya que el proveedor se encarga de evolucionarlos. Sin que los usuarios tomen acción alguna, una cuenta con un proveedor de servicios en la nube se comporta como un fondo de inversión de funcionalidades. Sin embargo, los costes de subscripción y pago por uso de estos servicios solo entrarían en acción cuando el código de las aplicaciones se ejecuta. Esto es así porque en un entorno serverless, el código es deuda. No solo deuda técnica, simplemente pura deuda.

La mayoría de los proveedores de servicios en la nube como Alibaba Cloud, AWS, Google Cloud o Microsoft Azure ya incluyen una importante selección de innovaciones serverless en su catálogo de servicios gestionados. Todos ellos ofrecen un amplio conjunto de funcionalidades para que los ingenieros de software construyan aplicaciones de una forma más ágil, en parte gracias a una mayor industrialización de la computación y a que, de alguna manera, estos proveedores se encargan del trabajo sucio de gestionar las infraestructuras. Los desarrolladores obtienen así un entorno de preocupación mínima y con apenas operaciones o intervenciones requeridas para crear aplicaciones, por lo que podrán centrarse en construir un software que impacte a sus clientes.

Llegados a este punto es importante mencionar que referirse a este tipo de tecnologías como cloud-native (nativas de la nube) es inexacto. Si miramos con atención, no hay nada nuevo en ellas que las haga innatas a la nube. Al contrario, están basadas en estándares de la industria ampliamente usados y aceptados durante años como pueden ser HTTP, SFTP, DNS, o MQTT. Es precisamente el uso de estos estándares lo que les ha permitido convertirse en servicios básicos. Es por ello por lo que los servicios serverless de estos proveedores siempre tendrán un equivalente fuera de la nube.

Los costes ocultos de no adoptar estos servicios

Una vez dicho esto, tenemos que empezar a ver las plataformas de servicios en la nube como un sistema que está listo para ser programado. Esto es, entender la computación en la nube moderna no como un centro de datos ajeno donde los ingenieros pueden crear máquinas virtuales y alojar sus cargas de trabajo, sino como una plataforma distribuida de servicios. Esta plataforma permite a los desarrolladores escribir código muy ligero que se encarga de integrar todos esos servicios dando lugar a un sistema totalmente funcional.

Esto supone un cambio de mentalidad absoluta para muchos ingenieros de software que están acostumbrados a llevar consigo un bagaje de experiencia práctica lleno de herramientas y frameworks que típicamente necesitaban en entornos de servidor. Aunque estas abstracciones y herramientas ya no son necesarias en entornos serverless, muchos ingenieros de software se muestran contrarios a deshacerse de estas prácticas ya que las ven como una medicina contra el famoso vendor lock-in. También, se suelen utilizar como un método defensivo ante una más que improbable necesidad de portabilidad de las aplicaciones a otra plataforma.

¿Por qué es improbable la necesidad de portabilidad?

Como refleja Gartner en su artículo, Why Adopting Kubernetes for Application Portability Is Not a Good Idea, la probabilidad de que las aplicaciones cambien de infraestructura a lo largo de su vida útil es muy baja. Una vez desplegadas en una plataforma, suelen quedarse ahí. Por lo tanto, el requerimiento de portabilidad suele ser una ilusión. Incluso aunque no sea así y dicha portabilidad sea un requerimiento real, la migración de aplicaciones entre las diferentes plataformas de servicios en la nube puede ser afrontada desde una perspectiva serverless. Como se ha mencionado anteriormente, serverless está basado en tecnologías estándar (incluso open source) lo cual facilita la interoperabilidad entre proveedores.

Sin embargo, y a pesar de ello, muchas compañías siguen invirtiendo en complejos esquemas de despliegue multi-cloud. La razón radica en que, hasta ahora, ha sido más fácil gestionar la deuda técnica que atacarla de raíz. La complejidad introducida por estas tecnologías (p.e. Kubernetes) conllevan esfuerzos extra y problemas de gestión que a la larga acabarán siendo más caros que escribir el código de las aplicaciones dos veces por lo que los desarrolladores están incurriendo en un sobrecoste el cual no existiría si hubiesen programado las aplicaciones aprovechando los estándares y servicios gestionados en la nube.

Pablo Bermejo, distinguished Technologist, DXC Technology, Iberia