Serverless la promesa de un futuro sin ataduras para el IT

Serverless la promesa de un futuro sin ataduras para el IT

Todavía recuerdo la primera vez que escuche hablar de este término en un evento de Amzonn Web Services, hará ya hace unos 4 años. El concepto me resulto fabuloso, sobre todo desde el punto de vista de parametrización y desarrollo desde cero de aplicaciones.

Los nombres que se le pueden dar a este tipo de arquitecturas son múltiples, arquitectura basada en eventos, serverless, function as a service, ect. Pero en el fondo todas radican en la misma filosofía, disponer de un patrón de arquitectura de software que permite eliminar la necesidad de aprovisionamiento y gestión de la infraestructura física, y que en base a eventos o acciones desencadena los procesos de computo e invoca a otros servicios mediante API para complementar su funcionalidad, este tipo de servicios se administran mediante API y SLA, en lugar de infraestructuras físicas.

La verdad es que las promesas de este tipo de servicios son amplias, os imagináis la posibilidad de disponer de un proceso de negocio, programado como una función en este tipo de servicios sin necesidad alguna de preocuparte sólo del código, sin pensar en la complejidad de las comunicaciones, accesos, seguridad, compatibilidad de versiones, ect. Os imagináis poder definir las métricas de uso y el presupuesto para implementar ese proceso de negocio con las mismas métricas que el equipo de marketing o el interlocutor de negocio, pues no, no imaginéis tanto ya que como decía Julio Verne, “Todo lo que una persona puede imaginar, otros pueden hacerlo realidad”.

Todo lo que una persona puede imaginar, otros pueden hacerlo realidad

Julio Verne, escritor y visionario

Recuerdo hace años precisamente cuando en el mundo del outsourcing se pusieron de moda los modelos comerciales disruptivos o llamémosle innovadores, llego un momento donde los clientes buscaban fórmulas de revenue share donde les ayudases a compartir riesgos y ellos en contrapartida te decían parte de su beneficio, recuerdo en concreto una reunión en cliente centrado en el sector de turismo, por aquel momento nosotros llevábamos la administración de su página web y otra empresa se dedicaba a desarrollar la aplicación y el código que corría en la misma. Fueron largos años de batalla entre los departamentos de sistemas y aplicaciones (en este caso externalizados a otras dos empresas) que terminaron por acabar con la paciencia del equipo de marketing de este cliente, fue curioso cuando a la hora de renovar el contrato su aproximación fue la de un BPO (Business Proccess Outsourcing) en lugar del tradicional ITO (IT Outsourcing) en ese momento quedamos totalmente fuera de la licitación, ya que en mi casa nadie quería asumir un contrato basado en consumo y beneficios compartidos por el cliente, y segundo porque nuestro negocio estaba en la venta y administración de infraestructuras, no en el desarrollo y optimización de procesos de negocio.

Desde mi humilde opinión, precisamente en esas mismas premisas radica la ventaja competitiva de cualquier aproximación serverless o function as a service, como punto de partida para desarrollar un proceso de negocio o aplicación. Se basa en el riego compartido, el proveedor asume que mientras no hay demanda no va a cobrar, eso sí tiene que tener el volumen suficiente para disponer de las infraestructuras mínimas para que cuando la necesidad surja poder responder. Todos pensareis que más o menos es el mismo caso que en los servicios de infraestructura (IaaS) y plataforma (PaaS), pues sí, pero no, porque una vez que alguien decide desplegar un servidor en la nube, al igual que en su data center pocas veces lo llega a apagar, ¿cuantos data center conocéis que se apaguen el fin de semana?

El único caso similar que conozco es el cálculo del distrito único de las universidades de Madrid, el cual se ejecuta en un equipo Digital (si hablamos ya de la prehistoria de la computación) corriendo sobre True64 como sistema operativo, este programa sólo se ejecuta una vez al año para calcular las notas de selectividad y asignación de las universidades a los alumnos, en función de los parámetros de elección de estos. ¿Os imagináis los sudores fríos de la persona que tenga que encender todos los años ese servidor del pleistoceno informático?, pues ese para mí es un caso de uso de FaaS o serverless de libro.

Beneficios de una arquitectura serverless

Los beneficios son más que obvio, y sobre todo el primero de ellos y es que no hay que operar los servidores. También la escalabilidad de las aplicaciones desarrolladas bajo este paradigma es más fácil de escalar, ya que el desarrollador no necesita codificar en la lógica dicha capacidad de escalado, sino que reduce la complejidad de la aplicación y se apoya en la capacidad de la plataforma para realizar esta función. Como resultado, esto simplifica el empaquetado y la implementación de la aplicación. El tiempo de desarrollo también es reduce, lo que significa que los nuevos productos llegan al mercado más rápido. Además, y debido a que hay menos consumo de recursos inactivos, el consumidor no tiene que pagar por el uso de esos recursos y/o aplicación debería de ser mucho menor comparado con una aproximación basa en un despliegue 100% IaaS o PaaS.

Sin embargo, no todo es oro lo que reluce, como ya mencionaba anteriormente este tipo de servicios hacen un uso intensivo de las API públicas del proveedor donde vayamos a alojar nuestra aplicación, así que por el contrario los grados de libertad y la posibilidad de quedarnos atados a ese proveedor (otra vez el tan temido vendor lock-in) puede hacernos que la capacidad de migrar nuestra aplicación a un tercero no sea tan sencilla a priori como pudiésemos pensar.

Cuáles son los requerimientos de mi aplicación

Pues el más claro y evidente el lenguaje de programación, no todos los lenguajes están soportados, ni tampoco todos los eventos que imaginéis serán capaces de lanzar vuestra aplicación, y como muestra un botón si nos vamos a la web de AWS, estos son los criterios de Lambda a tener en cuenta a la hora de desarrollar vuestra aplicación.

  • AWS Lambda es compatible con código escrito en Node.js (JavaScript), Python, Java (compatible con Java 8), C# (.NET Core) y Go.
  • El trigger de la aplicación suele ser otro servicio de AWS o inclusive se puede conectar a una aplicación ya disponible cuyo proceso de salida sea invocar a la API del servicio Lambda.

Y vosotros, ¿ya estáis trabajando con arquitecturas serverless?, ¿veis que el futuro del desarrollo de aplicaciones pase por esta serie de servicios?, ¿o pensáis que es una moda y quedará como algo pasajero? Me gustaría escuchar vuestras opiniones y proyectos, así que te animo a dejar un comentario en este post y podamos hablar sobre este tema más en profundidad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *