Ha surgido un nuevo modelo de lenguajes de programación declarativos para construir infraestructura como código, que promete más simplicidad y seguridad que los lenguajes imperativos.
por Matt Asay
En los últimos doce años más o menos, hemos sido testigos de un cambio drástico de las bases de datos de propósito general (Oracle, SQL Server, etc.) a las bases de datos diseñadas específicamente ( 360 de ellas y contando). Ahora los lenguajes de programación parecen ir en la misma dirección.
A medida que los desarrolladores pasan a una infraestructura altamente elástica impulsada por API (donde los recursos pueden vivir durante días en lugar de años), están construyendo infraestructura como código (IaC). Pero cómo construir IaC sigue siendo una pregunta abierta. Por una variedad de razones, el lugar obvio para comenzar era con lenguajes imperativos como C o JavaScript, diciéndole a un programa cómo lograr un estado final deseado.
Pero ha surgido un nuevo modelo de lenguajes declarativos, como HCL de HashiCorp o Polar de Oso , en el que el desarrollador le dice al programa cuál es el estado final deseado, sin preocuparse demasiado por cómo llega a ese estado. De los dos enfoques, la programación declarativa podría ser la mejor opción, lo que da como resultado un código más sencillo y seguro. Veamos por qué es así.
El por qué de la programación declarativa
Cuando le pregunté a Sam Scott, cofundador y CTO de Oso, si realmente necesitábamos otro lenguaje de programación, su respuesta fue “sí”. La versión más larga: “Con los lenguajes imperativos, a menudo hay un desajuste entre el lenguaje y su propósito; es decir, estos lenguajes fueron diseñados para que las personas creen aplicaciones y scripts desde cero, en lugar de definir configuraciones, políticas, etc. “
La introducción de nuevos lenguajes declarativos como Polar de Oso en realidad puede salvarnos de la proliferación del lenguaje, continuó Scott: “No se trata solo de introducir otro lenguaje para resolver un conjunto específico de problemas. Más bien, se trata de crear algo para evitar que las personas tengan que inventar su propio lenguaje una y otra vez para hacer algún tipo de lógica incorporada “.
Tomemos, por ejemplo, el código JSON escrito para la autorización de AppSync:
{ " Versión " : " 2017 - 02 - 28 ", " operación " : " PutItem ", " clave " : { " postId " : $ util . dynamodb . toDynamoDBJson ( $ context . argumentos . id ) }, " attributeValues " : { " Autor " : $ util . dynamodb
. toDynamoDBJson ( $ contexto . identidad . nombre de usuario ) #foreach ($ entrada en $ context.arguments.entrySet ()) #if ($ entrada.key! = "id") , ” $ { entrada . tecla } ” : $ util . dynamodb . toDynamoDBJson ( $ entrada . valor ) #end #end }, " condition " : { " expression " : " attribute_not_exists ( postId )" }
}
Para lograr un equilibrio entre los datos y la lógica, el desarrollador ha escrito permisos de estilo comentario en línea en Apache Velocity Template Language. Este es solo un ejemplo del proceso por el que pasan los desarrolladores de gimnasia para intentar expresar la lógica de autorización (“authZ”) mediante una combinación de configuración estática y plantillas.
Pero, en realidad, no se trata de si debemos usar programación imperativa, enfatizó Jared Rosoff de VMware en una entrevista. En cambio, “es una cuestión de ‘Actualmente no usamos un lenguaje de programación para expresar reglas de autorización, pero tal vez deberíamos …'”. Después de todo, usamos datos, no un lenguaje de programación, para expresar reglas de autenticación. Esto está bien, señala Rosoff, cuando sus reglas de autenticación son bastante simples. Básicamente, tiene una tabla de búsqueda que consulta cuando llega una solicitud para decidir si está autorizada o no.
Pan comido.
El imperativo puede no ajustarse a IaC
Pero el ejemplo de AppSync anterior muestra cómo el enfoque imperativo orientado a datos se complica rápidamente. “Lo que comenzó como un documento JSON relativamente simple se convirtió en algo con ramificaciones, condicionales y variables”, continuó Rosoff. Al adoptar este enfoque, el desarrollador está tratando de recrear la semántica similar a un lenguaje dentro de la sintaxis de datos estáticos, lo que resulta en un “lenguaje de programación de mierda que tiene una sintaxis terrible, sin bibliotecas, sin depuradores, etc.” No es lo ideal.
Tampoco es conciso, dice Scott. “Es difícil codificar su lógica de autorización en lenguajes tradicionales”, señala. “Hacerlo en un lenguaje declarativo de propósito especial como Polar es más expresivo y más conciso”.
Como Scott explicó además, hay muchos dominios problemáticos donde si un desarrollador intentara codificar un proceso en Java o Python, requeriría miles de líneas de código, lo cual es un problema en sí mismo, pero se vuelve más problemático en que oscurece la lógica empresarial real. Por el contrario, un lenguaje declarativo puede realizar el mismo trabajo pero en decenas de líneas de código.
Entonces, en lugar de cambiar la sintaxis de configuración a lenguajes imperativos, dice Rosoff, deberíamos usar pequeños programas para manejar authZ y funciones relacionadas. Hay muchos problemas de programación hoy en día en los que usamos datos para configurar un sistema, pero podría tener más sentido usar un programa, según Rosoff. Para nombrar unos pocos:
- Autorización
- Plantillas de implementación (por ejemplo, Terraform, Ansible, etc.). “Cada uno de estos intenta crear construcciones similares a un lenguaje dentro de los límites de un lenguaje de datos con resultados terribles”. Pulumi ofrece un enfoque interesante para esto.
- Flujos de trabajo. Temporal es un ejemplo interesante de tomar lo que se habría hecho anteriormente en un lenguaje de flujo de trabajo de diagrama y llevarlo a un formato de lenguaje de programación de propósito más general.
Libertad suficiente, con sencillez y seguridad
El truco, dice Rosoff, es darle al programador suficiente lenguaje para expresar la regla de autorización, pero no tanta libertad como para que puedan romper toda la aplicación si tienen un error. ¿Cómo se determina qué idioma usar? Rosoff ofrece tres criterios de decisión:
- ¿El idioma me permite expresar toda la variedad de programas que necesito para escribir? (En el caso de la autorización, ¿me permite expresar todas mis reglas de autenticación?)
- ¿Es el lenguaje conciso? (¿Tiene menos líneas de código y es más fácil de leer y comprender que el equivalente de YAML?)
- ¿Es seguro el idioma? (¿Evita que el programador introduzca defectos, incluso intencionalmente?)
Todavía tenemos mucho camino por recorrer para hacer de los lenguajes declarativos la respuesta fácil y obvia a la programación de infraestructura como código. Una razón por la que los desarrolladores recurren a lenguajes imperativos es que tienen enormes ecosistemas construidos a su alrededor con documentación, herramientas y más. Por lo tanto, es más fácil comenzar con lenguajes imperativos, incluso si no son ideales para expresar configuraciones de autorización en IaC.
También tenemos trabajo por hacer para que los lenguajes declarativos sean accesibles para los novatos. Esta es una de las razones por las que Polar, por ejemplo, intenta tomar prestada la sintaxis imperativa.
Sin embargo, dados los beneficios de un enfoque declarativo, puede que simplemente sea cuestión de tiempo hasta que se conviertan en estándar para IaC.
Fuente: https://www.infoworld.com/article/3597054/figuring-out-programming-for-the-cloud.html
