La frase que da título a la entrada era muy frecuente en mis tiempo mozos,… o al menos así la recuerdo y justo fruto de estas warning quizás sea por lo que muchas personas no suelen arriesgarse a salir de la zona de confort. No sea que la líe y encima tenga que soltar unos billetes para enmendar el error.
Pues justo lo contrario me sucede a mi. Me encanta explorar los límites de las soluciones y ver cómo se tiene que hacer para volver a ponerlas en funcionamiento. Es decir, me parezco a esa persona que desmonta el motor del coche y lo deja expuesto en el garaje junto con el resto del vehículo y tras unos días, vuelve a ensamblarlo. Lo malo aquí es que en ocasiones, quede algún que otro tornillo sin usar…
Risas a parte, lo que quiero poner de manifiesto es que entre un punto y otro hay multitud de posiciones y seguro que, si te encuentras en el extremo opuesto al mío, tendrás espacio a recorrer si dejas atrás un poco ese miedo a romper ciertos límites. No te digo que pases de cero a cien desde el minuto uno, sino que al menos valores darle una vuelta.
Como no hay mejor forma de ilustrar de lo que hablo, te explico un ejemplo del que además hay poca literatura, o al menos yo no encontré en su momento. ¡Veamos!
Hace unos meses, tuve la oportunidad de participar en un despliegue de una solución de datos que tiene como core Azure Databricks. Hasta aquí, nada nuevo que no haya contado en más de una ocasión. Pues eso, que pasaron los meses y los días hasta que llegó un momento en que las queries ejecutadas desde el Notebook de Databricks a las tablas Delta alojadas en el Data Lake montado sobre un Azure Storage Account con el set de Jerarquía activado dejaron de funcionar.
En esos momentos, suele pasar que alguien se echa las manos a la cabeza y piensa en lo peor. Han llegado los extraterrestres y nuestro clúster está siendo usado para cualquier menester. Pues no fue el caso, ¡lástima!
Suele suceder que cuando creas un App Registration en Azure, el token generado tiene una fecha de caducidad y justo eso fue lo que había ocurrido. El sistema estaba queriendo recuperar la credencial almacenada en un Secret de la Key Vault vinculada con el Secret Scope declarado en Databricks y nada de nada,…
Pues una vez averiguado lo que estaba impactando el trabajo del día a día, tocaba implementar la solución. En principio era relativamente sencillo, crear un nuevo token y actualizar el Secret correspondiente con la nueva versión. Es decir, estamos dando solución a una situación acaecida para solventar el inconveniente.
Lo que ya no es tan usual es ir un poco más allá y buscar múltiples soluciones al problema para evaluar cual es la más eficiente. De ese modo, eres capaz de lidiar con otras situaciones que no aparecían en la situación de inicio, pero que te ayudan a comprender en profundidad el entorno en el que opera la solución. Me explico, en una de las aproximaciones se decidió hasta hacer un desmontaje del Data Lake para posteriormente volver a montarlo. En ese momento, recuerdo que alguien comentó, crucemos los dedos…
Nunca nadie había desmontado el Data Lake y lo había vuelto a montar, algo que hacía que se dudara de si tratando de resolver el problema inicial no se crearía uno aún más gordo. A esto me refiero cuando nos limitamos a buscar solucionar algo sin comprender en profundidad todo lo que está relacionado con ello. Puede que en ocasiones el tiempo empleado a proveer soluciones sea mayor que si sólo actúas sobre el problema, pero de lo que sí que estoy seguro es que a futuro te permite ser mucho más eficiente en la resolución de situaciones complejas, ya que el conocimiento del ecosistema es infinitamente superior.
CONCLUSIÓN
Por eso, que no te de miedo romper cosas, pues es la única forma que hay de aprender a arreglarlas.
Foto de portada gracias a cottonbro studio: https://www.pexels.com/es-es/foto/persona-en-botas-de-cuero-negro-con-palo-de-madera-marron-6110250/
Alb3rto Alonso 