Cómo la tecnología sin servidor cambia la forma en que los desarrolladores construyen y prueban

Serverless sigue creciendo en importancia, pero según algunos expertos, requiere una forma diferente de diseñar y probar los sistemas.

Según algunas medidas, más de la mitad de las empresas han adoptado serverless. Si está en el lado «todavía no» de esa ecuación, la ingeniera principal de la comunidad de Prefect, Anna Geller, ha ofrecido múltiples formas en que la computación sin servidor no solo ayuda a las empresas a construir de manera más efectiva, sino que también alienta a los desarrolladores a codificar de manera más productiva.

Y, sin embargo, como ha señalado el cofundador de Serverless Days, Paul Johnston, muchos desarrolladores se equivocan al abordar la tecnología sin servidor y tropiezan en el proceso.

Como señaló: «Si trata un sistema sin servidor como un sistema de software y trata de construirlo de esa manera, es mucho más probable que tenga dificultades para obtener el mejor resultado».

Pero, ¿qué quiere decir y cómo pueden los desarrolladores evitar esta trampa?

VER: AWS Lambda, un marco informático sin servidor: una hoja de trucos (PDF gratuito) (Tecnopedia)

¿Por qué ir sin servidor?

Una de las mejores cosas de serverless, según Geller, es que fomenta prácticas de ingeniería útiles. Por ejemplo, si podemos estar de acuerdo en que «es beneficioso construir componentes de software individuales de tal manera que sean responsables de una sola cosa», entonces la tecnología sin servidor ayuda porque «fomenta el código que es fácil de cambiar y sin estado».

Además, continuó, sin servidor casi obliga a un desarrollador a crear código reproducible.

“Serverless no solo lo obliga a hacer que sus componentes sean pequeños, sino que también requiere que defina todos los recursos necesarios para la ejecución de su función o contenedor”, dijo Geller.

Al requerir tales servicios autónomos, serverless alienta a los desarrolladores a preocuparse por «la coreografía sobre la orquestación, con cada componente desempeñando un papel más consciente de la arquitectura», como ha postulado Mike Roberts de Symphonia.

Esta idea de arquitectura impulsada por eventos es poderosa, pero también en la que muchos desarrolladores se descarrilan.

Construyendo con la coreografía en mente

“Los sistemas sin servidor deben considerarse (pero rara vez lo son) como una gran cantidad de sistemas desacoplados pero muy pequeños, que son completamente independientes entre sí, conectados por eventos”, señaló Johnston.

Bueno, así es como funciona el software, ¿verdad?

“Sí”, agregó, “eso es ‘software’ en el sentido general. Pero eso no es ‘software’ en el sentido en que la mayoría de los desarrolladores o gerentes lo piensan”.

Parte de esta disonancia entre el pensamiento sin servidor y los sistemas de software se reduce a la seguridad (sin servidor requiere que un desarrollador confíe algunas preocupaciones de seguridad al proveedor de la nube subyacente) y una pérdida general de control porque, nuevamente, aunque el desarrollador se enfoca en su aplicación Lógicamente, el proveedor de la nube sigue administrando servidores en su nombre. Pero es realmente en el área de las pruebas donde se expone la necesaria diferencia de enfoque.

“El alto elemento de desacoplamiento dentro de un sistema sin servidor significa que no tiene el mismo requisito para probar en todos los equipos”, enfatizó Johnston. “Cada elemento individual necesita pruebas (esto no cambia), pero debido a que cada elemento está desacoplado (o debería estarlo) y es pequeño (o debería estarlo), entonces debería haber un acoplamiento casi nulo entre los equipos y entre los elementos. Si hay un acoplamiento cercano a cero entre los equipos y los elementos de un sistema, entonces… solo tiene que probar los elementos (excepto cuando hay acoplamiento donde tiene que probar)”.

Las pruebas unitarias siguen siendo relativamente sencillas, pero las pruebas de integración se vuelven más difíciles e incluso más importantes.

“Parte de la razón por la que considerar las pruebas de integración es un gran problema es que nuestras unidades de integración con Serverless FaaS son mucho más pequeñas que con otras arquitecturas”, escribió Roberts. “Confiamos en las pruebas de integración mucho más que con otros estilos arquitectónicos”.

Esto se complica por la necesidad de confiar en las nubes para tales pruebas, lo que puede ser un salto incómodo.

“Confiar en entornos de prueba basados ​​en la nube en lugar de ejecutar todo localmente en mi computadora portátil ha sido un shock para mí”, dijo Roberts.

Y luego está el enfoque de la arquitectura (y las pruebas) que difiere.

“Entonces, el proceso de desarrollo [in the serverless world] se trata de construir una gran cantidad de elementos pequeños y desacoplados, y probarlos”, dijo Johnston. “El proceso de gestión más amplio se trata de comprender cómo encajan esos elementos pequeños y desacoplados”.

Coreografía, no orquestación, en otras palabras.

¿Un cambio insuperable en el pensamiento? Difícilmente. Pero es diferente, y como argumentan Johnston, Roberts y otros, descubrir esas diferencias y construir en consecuencia es clave para lograr un servidor sin servidor correcto.

Divulgación: trabajo para MongoDB, pero las opiniones expresadas aquí son mías.