Con la programación de la nube hemos topado
La aparición de un nuevo modelo de programación para la construcción de infraestructura como código promete más simplicidad y seguridad.
En la última docena de años, más o menos, hemos sido testigos de un dramático cambio de las bases de datos de propósito general (Oracle, SQL Server, etc.) a las bases de datos de propósito específico. Ahora, los lenguajes de programación parecen ir en la misma dirección.
A medida que los desarrolladores pasan a una infraestructura caracterizada por su elasticidad y basada en APIs (donde los recursos pueden vivir durante días en lugar de años), están construyendo una infraestructura como código (IaC). Pero cómo construir IaC sigue siendo una pregunta que da lugar a infinidad de respuestas.
Por varias razones, el lugar obvio para empezar era con lenguajes imperativos como C o JavaScript, que le dicen 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, que permiten al desarrollador pedirle al programa cuál es el estado final deseado sin preocuparse demasiado de la manera de llegar a dicho final. De los dos enfoques, la programación declarativa podría ser la mejor opción, lo que se traduce en un código más ligero y seguro. Veamos por qué.
El porqué de la programación declarativa
Ante la pregunta de si realmente necesitábamos otro lenguaje de programación, la primera respuesta de Sam Scott, cofundador y CTO de Oso, fue "sí". La versión más larga: "Existe a menudo un desajuste entre el lenguaje y su propósito con los lenguajes imperativos. Es decir, estos lenguajes fueron diseñados para que la gente construya aplicaciones y scripts desde cero, en lugar de definir configuraciones, políticas, etc."
Introducir nuevos lenguajes declarativos como el Polar de Oso, en realidad puede salvarnos de la proliferación del lenguaje, continuó Scott: "No se trata sólo de introducir otro lenguaje para resolver un conjunto específico de problemas. Más bien se trata de crear algo para evitar que la gente tenga que inventar su propio lenguaje una y otra vez si pretende hacer alguna forma de lógica incorporada".
Tomemos, por ejemplo, el código JSON escrito para la autorización de AppSync:
{
“version” : “2017-02-28”,
“operation” : “PutItem”,
“key” : {
“postId” : $util.dynamodb.toDynamoDBJson($context.arguments.id)
},
“attributeValues” : {
“Author” : $util.dynamodb.toDynamoDBJson($context.identity.username)
#foreach( $entry in $context.arguments.entrySet() )
#if( $entry.key !="id" )
,”${entry.key}” : $util.dynamodb.toDynamoDBJson($entry.value)
#end
#end
},
“condition” : {
“expression” : “attribute_not_exists(postId)”
}
}
Para conseguir el equilibrio entre los datos y la lógica, el desarrollador ha escrito permisos en línea, de estilo inicial, en el lenguaje de plantillas Apache Velocity. Este es sólo un ejemplo de lo que los desarrolladores hacen para tratar de expresar la lógica de autorización ("authZ") utilizando una combinación de configuración estática y plantillas.
Pero, en realidad, no se trata de si debemos usar una programación imperativa, subrayó Jared Rosoff de VMware en una entrevista.
En su lugar, "es una cuestión de 'Actualmente no utilizamos un lenguaje de programación para expresar las 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 autorización. Esto está bien, señala Rosoff, cuando sus reglas de autorización son bastante simples. Básicamente lo que se tiene es una tabla de búsqueda que consultas cuando llega una solicitud para decidir si está autorizada o no.
Así que, con calma.
