Computación sin servidor, hasta el final de la lógica de la nube
La informática sin servidor es un principio que ha aparecido recientemente en la escena de las TI. Es una especie de búsqueda de lo absoluto por parte de los CIO, y quizá aún más por parte de los CFO. Trata de responder a la pregunta más primitiva de la Nube: ¿podemos prescindir de los servidores?
Cuando nació el Cloud Computing, se trataba de reducir el coste de la inversión en infraestructuras informáticas. Y, por extensión, de liberarnos progresivamente de todas las limitaciones impuestas por estas infraestructuras.
Echemos un vistazo más de cerca a serverless: ¿cómo se define? ¿Cuáles son los beneficios más tangibles y demostrables y, sobre todo, cuáles son los inconvenientes y los riesgos? Como verá en las respuestas que ofrecemos a continuación, no hay nada mágico en serverless. Pero sí una mezcla eficaz de tecnologías y modelos de negocio para responder lo mejor posible a las demandas cambiantes de las empresas.
Sin servidor: definición de la informática sin servidor
¿Qué es la computación sin servidor?
El término " serverless" se refiere a la ejecución del código de una aplicación sin necesidad de un servidor. No existe una infraestructura local o en la nube dedicada específicamente a una organización o aplicación determinada.
En otras palabras, en una arquitectura sin servidor, no sólo la ejecución del código, sino también el mantenimiento de los servidores, es gestionado por el proveedor de la nube.
La llegada de FaaS, Function as a Service (función como servicio)
Conviene hacer una aclaración: detrás de este llamativo nombre se esconden, a pesar de las apariencias... servidores.
Porque la tecnología aún no ha llegado a la fase en la que la informática será totalmente virtual, impalpable, libre de toda restricción física. Existen, por supuesto, recursos y servidores en los que se ejecutará el código.
Este enfoque es bastante similar al de los microservicios. La diferencia es que la arquitectura sin servidor está naturalmente vinculada a un proveedor de servicios en la nube (CSP). Mientras que los microservicios se basan en contenedores que pueden desplegarse en diferentes hostings.
A menudo se utiliza el término FaaS, o Function As A Service (función como servicio). La idea es ejecutar una función bajo demanda, cada vez que se necesite, solicitándolo a un proveedor Cloud remoto:
- El desarrollador sólo tiene que proporcionar su código;
- el proveedor devolverá el resultado cada vez que se solicite.
Así que, ante todo, buscamos reducir los costes de infraestructura, y ser altamente adaptables.
Ventajas y limitaciones de serverless
Ventajas financieras... pero no sólo
El modelo de facturación suele ser el de "pago por uso": la empresa paga por la memoria, el almacenamiento y la potencia de cálculo utilizados durante la ejecución, en función de su uso, y por tanto en función del tiempo de servidor utilizado:
- el serverless permite reducir los costes de un servicio que se utiliza muy poco;
- en cualquier caso, la facturación es una especie de culminación del concepto de Cloud Computing: es un reflejo estricto del uso que se hace del servidor remoto;
- si no se ejecuta una función o un código, el coste puede ser cero.
Otra ventaja es la velocidad de desarrollo. Para pasar del proyecto a la producción, ya no hay que preocuparse por la infraestructura: la potencia de cálculo estará inevitablemente disponible, como y cuando la necesite.
La flexibilidad también es una ventaja indudable. Si no quiere perder tiempo dimensionando o probando recursos de hardware, transfiera la carga al CSP. Siempre podrá proporcionarle la potencia que necesite, cuando la necesite: eso forma parte del contrato.
Sin servidor, pero no sin limitaciones
A pesar de las apariencias, esta arquitectura impone ciertas reglas.
Una de ellas es el reducido número de proveedores. Los 3 más importantes son :
- AWS (Amazon Web Service), y en particular AWS Lambda, que es el actor histórico,
- Microsoft Azure Functions,
- y Google Functions.
El método de facturación implica la necesidad de diseñar código que no consuma mucho tiempo de computación:
- en cualquier caso, el tiempo de ejecución asignado a la función suele ser limitado;
- no se puede sobrepasar, o se cobrará de más.
👉 Por ejemplo, AWS, que lanzó este concepto en 2014, da las siguientes cifras:
- la mediana del tiempo de ejecución de una función en sus servidores es de 800 ms,
- solo una cuarta parte supera los 3 segundos
- y el 12% se ejecuta durante más de 10 segundos.
En general, la codificación está limitada por los lenguajes (o la lengua) admitidos por el proveedor de servicios en nube. La facturación también se basa en la memoria necesaria para ejecutar el código.
Así pues, aunque la arquitectura sin servidor es muy flexible y puede hacer frente a grandes aumentos de la carga de trabajo, debe mantenerse bajo control en términos de coste. Incluso puede ser más cara que una arquitectura tradicional en las instalaciones o en la nube.
Sin servidor también implica un enfoque específico de la seguridad
Debido a su naturaleza muy específica, el paradigma sin servidor destaca en varios aspectos cuando se trata de la seguridad:
- los proveedores de la nube gestionan el sistema operativo, la seguridad en tiempo de ejecución y los parches. Esto es una garantía, dada la escala de los proveedores actuales;
- la naturaleza efímera y sin estado de la computación sin servidor hace la vida más difícil a los atacantes. El hecho de que las funciones sin servidor vayan y vengan, sin memoria, reduce el riesgo de ataques a largo plazo;
- el pequeño tamaño de los bloques de código facilita su análisis por las herramientas de seguridad CSP.
Por otro lado, esta arquitectura también crea vulnerabilidades. Cada función se convierte en un punto potencial de ataque, lo que dificulta a los proveedores la supervisión de sus servidores. También es más complicado, tanto para el CSP como para el codificador, observar múltiples procesos y múltiples puntos de entrada/salida.
Las aplicaciones tradicionales tienen un perímetro más claro, con el exterior y el interior claramente diferenciados. Pueden instalarse elementos de seguridad tradicionales como WAF, cortafuegos e IDS.
Por último, cabe señalar que las aplicaciones nativas en la nube pueden utilizar numerosos módulos y bibliotecas con código de diversas fuentes de terceros. Los atacantes potenciales podrían entonces intentar incluir código malicioso en proyectos comunes.
Sin servidor, ¿una arquitectura a adoptar con urgencia?
Como suele ocurrir con las tecnologías y conceptos emergentes, debemos dar un paso atrás antes de decidir si adoptarlos o rechazarlos. Sólo tiene sentido en un contexto determinado.
Más allá del simple aspecto técnico, su uso también puede repercutir en los recursos humanos de su organización. Le obliga a contar con un sólido equipo de codificadores, que tal vez necesite reforzar.
Al mismo tiempo, puede suponer una reducción de los recursos dedicados a la infraestructura y su gestión.
Así que, de hecho, aunque parezca diseñado para permitirle tomar decisiones puntuales, al impulsar determinados proyectos, puede transformar profundamente su Departamento de TI y los servicios vinculados a él.
Artículo traducido del francés