En el mundo empresarial todo tiene que funcionar y especialmente en lo que a desarrollo de soluciones se refiere. Es por ello que, siempre se pone mucho foco en que las aplicaciones nunca dejen de funcionar. Es decir, palabras como Business Continuity y Disaster Recovery se repiten en los planes de seguridad empresarial cuando se están definiendo las bases de prácticamente cualquier aplicación de negocio. Especialmente si aplica a clientes. Nadie quiere que el servicio se caiga, se pierdan datos o incluso que las actualizaciones obliguen a cortar el servicio. Pero esto que resulta decisivo a la hora de decantarse por una u otra arquitectura en la parte de operacional, casi no está explorado en la parte de analítica avanzada.
En el mundo de la analítica avanzada es habitual encontrarte con soluciones de datos que en rara ocasión implementan sistemas de backup. Si es cierto que, los componentes de almacenamiento de datos como los storages articulan capacidades que dan solución a la recuperación ante desastres, si bien no es tan usual encontrar planes de backup de los datos en las distintas capas. Por ejemplo, en un Lakehouse (con arquitectura de medallas), disponemos de capa Raw, Bronze, Silver, Gold… e incluso alguna más como Platinum,… en capas más cercanas a negocio, y es raro incluso encontrar definidas estrategias de lifecycle Management, como para tener implementadas estrategias de copia y movimiento de datos.
Es por ello, que quiero resaltar lo peligroso que es para una organización infravalorar esta capacidad. Para ello simplemente quiero ilustrarlo con simple un ejemplo. Supongamos que trabajamos en la empresa Contoso, y que el equipo de Cloud ha decidido lanzar los pipelines de Azure DevOps para hacer un upgrade de los componentes que tenemos en los diferentes entornos. Pues resulta que algo sale mal y en vez de hacer un upgrade se eliminan todos los componentes. Por supuesto, no había un plan de gestión de backup o incluso uno que realizara snapshots de datos. ¿Qué sucede en ese momento? Pues sencillamente, que se provoca el Kaos más absoluto.
Para entender lo grave de la situación, quiero recordar que en muchas ocasiones las estrategias de historificación que se realizan en las diferentes entidades de los modelos de datos en la parte de analítica avanzada, no es replicable desde el operacional, pues es raro encontrar dicha implementación allí. Por eso el coste asociado a esa pérdida puede resultar enorme, sobre todo si se aplican modelos de ML propios.
NOTA: un dataset para entrenamiento de ML debe disponer de datos históricos suficientes o el resultado del entrenamiento no resultará satisfactorio. Lo que significa meses (o incluso algo más de tiempo) hasta volver a disponer de un set de datos suficiente como para acometer un proyecto de ML tradicional con garantías.
Por todo esto, recuerda que el dato es un activo empresarial y el mismo valor tiene en la parte operacional como en la parte de analítica avanzada. No porque la primera aplique, en muchas ocasiones, al cliente externo frente a la segunda que habitualmente incumbe al cliente interno.
Apuesta por definir un proceso robusto de Analytics Continuity si quieres evitar futuros inconvenientes y dolores de cabeza.
Aquí os dejo una lectura recomendada de cómo Microsoft ayuda a mantener los datos de almacenados en Blobs de Azure Storage Account a buen recaudo y disponibles gracias a Azure Backup, link
Foto de portada gracias a Miguel Á. Padriñán: https://www.pexels.com/es-es/foto/teclado-palabra-botones-teclear-2882506/
Alb3rto Alonso 