Oleksii - stock.adobe.com
Las plataformas sin servidor limitan las opciones de lenguajes de programación
La computación sin servidor puede reducir los costos de infraestructura y agilizar los procesos de desarrollo, pero no asuma que el lenguaje de programación que elija estará disponible.
En el desarrollo de software, el cielo es a menudo el límite cuando se trata de pilas de tecnología para un nuevo proyecto. Sin las restricciones de código de aplicación preexistente, los desarrolladores generalmente pueden elegir los lenguajes, marcos, infraestructura y herramientas para resolver mejor el problema en cuestión. Pero con las plataformas sin servidor, este no es siempre el caso.
Para ser rápidos y eficientes, la mayoría de los proveedores sin servidor limitan su número de tiempos de ejecución de programación admitidos a solo las tecnologías más rentables o compatibles. Esto les permite centrarse en las mejoras de sus plataformas sin servidor, sin la complejidad añadida que conlleva la compatibilidad con varios idiomas. Pero también limita las opciones para los desarrolladores cuando intentan pasar a un entorno sin servidor y significa que la elección del idioma puede dictar el proveedor sin servidor que elijan.
¿Qué hay en un idioma?
AWS Lambda, la primera plataforma sin servidor en la nube, inicialmente solo admitía Node.js. Esto marcó la pauta para otros servicios, como Google Cloud Functions y Microsoft Azure Functions, que también se lanzaron con soporte nativo para Node.js y no mucho más. Si bien la mayoría de los proveedores sin servidor han ampliado su soporte de tiempo de ejecución para incluir otros lenguajes de programación populares más allá de Node.js, ningún proveedor admite todos los lenguajes.
Algunas plataformas y servicios sin servidor, como OpenWhisk de IBM, ofrecen soporte no estándar para lenguajes arbitrarios a través de contenedores Docker, mientras que otras, como AWS Lambda, requieren una implementación menos tradicional para utilizar un tiempo de ejecución de lenguaje no compatible. Pero la complejidad de administrar un entorno de ejecución personalizado contrarresta los beneficios.
Por lo general, el primer instinto de los desarrolladores es utilizar tecnologías familiares para resolver problemas rápidamente, sin sacrificar la calidad. En la informática sin servidor, los desarrolladores se orientan hacia proveedores en los que confían y luego seleccionan un lenguaje de programación de su lista mucho más pequeña de tecnologías disponibles. Puede resultar incómodo, pero potencialmente inevitable.
Conocer las advertencias del idioma
Antes de que los desarrolladores elijan un lenguaje de programación sin servidor, deben conocer sus pros y sus contras. Al igual que con el desarrollo de aplicaciones tradicionales, existen claras ventajas y desventajas de un lenguaje compilado frente a uno interpretado. Dependiendo de la plataforma sin servidor, los lenguajes interpretados pueden sufrir arranques en frío un poco más largos. Sin embargo, también es posible acelerar el desarrollo y la productividad a través de pruebas creadas con lenguajes interpretados.
Recordar la biblioteca estándar
Considere cuán extensible es un lenguaje disponible. Por ejemplo, si bien JavaScript puede ser un lenguaje apropiado para desarrollar funciones sin servidor, es posible que un proveedor no admita compilaciones de TypeScript. Esto podría ser un factor decisivo dentro de las organizaciones que valoran o hacen cumplir los lenguajes fuertemente escritos. Además, las funciones sin servidor están diseñadas para ser pequeñas y rápidas, por lo que un lenguaje con una biblioteca estándar sólida y eficiente marcará una diferencia significativa en el tiempo de activación de sus funciones.
Ser bilingue
En muchos casos, es posible que los desarrolladores no puedan elegir un tiempo de ejecución sin servidor con el que estén familiarizados. Los lenguajes tradicionales, como C y C++, están subrepresentados en el dominio de la informática sin servidor, mientras que otros lenguajes populares, como PHP y Ruby, tienen un soporte relativamente limitado. En este caso, es importante considerar no solo la facilidad de mantenimiento y aprendizaje de los idiomas disponibles, sino también la comerciabilidad de cada uno. Siempre tenga en cuenta el crecimiento, ya que la elección incorrecta podría dificultar la contratación y la capacitación a largo plazo.