por tecknolab | Sep 27, 2018 | BigData, Estrategia, Tecnología
Decía Benjamin Franklin que hay dos cosas seguras en esta vida: la muerte y pagar impuestos. Podríamos decir que aunque no tan deterministas, pero bastante cerca, el mundo de la tecnología sigue necesitando preservar y proteger la información con políticas de backup. Eso no cambia y sigue siendo una tarea bastante ingrata, por cierto (como todo aquello de lo que solo nos acordamos cuando hay algún desastre, pero que para evitarlo, requiere un coste y esfuerzo diario).
Lo que ha cambiado es la naturaleza y sobre todo el volumen de esa información (y los servicios de datos asociados) haciendo cada vez más complejo realizar esa tarea y una mayor incertidumbre en asegurar la capacidad de recuperación.
Esto nos lleva a buscar nuevos modelos y paradigmas de protección de datos que haga la tarea más efectiva, eficiente, predecible …. y barata.
Limitaciones estratégicas, organizativas y procesos
Por nuestra experiencia, detectamos en las empresas las siguientes limitaciones principales en la protección de la información, en todo lo relacionado con aspectos estratégicos, organizativos o de procesos:
- Falta de una visión global de la naturaleza y criticidad de la información. Las empresas suelen tener razonablemente completos y actualizados (no siempre!) mapas de sistemas pero muy infrecuentemente mapas de repositorios y flujos de datos, con su naturaleza (p.ej. fuente o derivado, conceptos que maneja) y su criticidad (en función del valor).
- Políticas de protección definidas verticalmente por sistemas, no horizontalmente por lógica del proceso. Ligado a lo anterior, es habitual encontrar que las políticas de protección de datos se hacen verticalmente por el sistema lógico (o físico) que lo alberga, y no por la naturaleza de la fuente. En muchos casos, los responsables del backup, desconocen por completo la naturaleza del repositorio al que están aplicando políticas de backup.
- Incapacidad de tratar de forma diferenciada, pero combinada, las políticas de protección de los datos y la disponibilidad de los sistemas. En muchos casos, los planes de recuperación de sistemas (lo que permite que un determinado servicio de información se preste) y los planes de protección de datos (lo que permite recuperar una determinado repositorio en caso de pérdida, borrado accidental o corrupción de datos) se gestionan de forma independiente e inconexa.
- Falta de modelos de análisis de riesgos e impacto económico asociado. La mayoría de organizaciones carece de modelos de riesgo medianamente completos relacionados con los dos aspectos anteriores. Y sobre todo no lo tienen modelizado con la métrica que todo el mundo entiende: DINERO. Esto hace que las políticas de protección de datos (y los modelos de retorno de inversión realizados) sean basados en criterios subjetivos, en algunos casos, espurios.
Limitaciones tecnológicas
En la otra cara de la moneda están las limitaciones tecnológicas derivadas de un mercado de poco glamour (el de las soluciones de backup) y de una creciente complejidad en los requisitos:
- Predecibilidad de las capacidades y métricas de recuperación. En general las herramientas de backup hacen un trabajo más o menos digno en realizar backups. Pero pregunte a un responsable de backup en la organización de operaciones de IT de una gran empresa si pone la mano en el fuego (y se juega su puesto) porque es capaz de recuperar la información de un sistema crítico con los niveles de servicio acordados en caso de un desastre, a ver qué contesta. En caso afirmativo, pregunte si realiza simulaciones regularmente.
- Heterogeneidad de los entornos y sistemas técnicos de protección. Cualquier empresa de tamaño mediano / grande acaba teniendo múltiples sistemas y soluciones de backup, complicando los procesos y aumentando el riesgo global de la solución. La adopción de los modelos Cloud solo ha añadido un factor adicional de complejidad que muchas soluciones ‘tradicionales’ no consiguen manejar de forma eficiente.
- Escalabilidad de los volúmenes de información a proteger. En el ámbito de bigdata es conocida la frase ‘los datos tienen gravedad’. O sea, pesan. Mover datos o realizar copias a efectos de protección o recuperación de los mismos no hace más que incrementar la complejidad técnica del proceso con el incremento (incesante) del volumen de información a manejar.
- Incapacidad de gestionar en función de la naturaleza específica de la información a proteger. Esto es, en muchos casos, nuestras políticas de backup, por razones técnicas, tienen que usar políticas de ‘café para todos’ cuando se mezclan en los repositorios, información con distinta naturaleza y que no deberían tener los mismos requisitos de protección (por ejemplo, información de alta volatilidad con información voluminosa, pero de baja o nula tasa de cambios).
Tendencias en la era de los datos masivos
El crecimiento imparable de los volúmenes de información a procesar y respaldar y el advenimiento de los proyectos de analítica masiva de datos, llevan a una presión adicional, que no se puede resolver de forma lineal. Necesitamos transformaciones radicales en la aproximación tecnológica. Algunas líneas de innovación que destacamos son las siguientes:
- Protección intrínseca. Lo que buscan las soluciones de protección intrínseca es sustancialmente eliminar la necesidad de realizar una copia de backup con una herramienta de backup convencional. Esto es el repositorio se auto-protege y es capaz de proporcionar una solución a los distintos escenarios de recuperación de información que podemos tener (recuperación completa por desastre físico, borrado accidental, recuperación de una versión previa en el tiempo, aseguramiento de la inalterabilidad de contenidos concretos por razones legales o funcionales, etc.). Hay muchos aspectos a tener en cuenta, pero en general la visión de un repositorio de datos como una sucesión de cambios en el tiempo, es la base que permite abordar estos modelos.
- Reducción de los activos tecnológicos a proteger. Como comentábamos en el apartado de limitaciones tecnológicas, tradicionalmente las políticas de backup se usaban para dotar de disponibilidad un determinado servicio o repositorio, no solamente para proteger los contenidos. Para entendernos, hacemos un backup de nuestro servidor, entero, con todos sus elementos, para asegurar que puedo restaurarlo entero en caso de problemas (con toda la información que alberga y sirve). Esto es profundamente ineficiente. La tendencia en ingeniería de software y sistemas con evoluciones como la virtualización en su momento y los containers más recientemente es que los servicios sean recreables por descripción de los mismos, no porque hemos guardado una copia exacta ‘por si acaso’. Es como si para proteger el servicio de movilidad en automóvil, tenemos un coche que es el que usamos y tenemos otro exactamente igual en el garaje por si el primero falla o tiene un accidente. Pero además tenemos que pasar el trabajo de hacer en ese segundo vehículo todos los pequeños golpes, arañazos, desgaste que tiene el coche original, para que sea exactamente igual. Si fuéramos capaces de describir de forma automatizada el proceso de construir un coche, es mucho más eficiente simplemente tener ese proceso actualizado y, cuando nuestro coche falla, lanzar el proceso de crear uno nuevo; naturalmente en nuestro ejemplo, ‘fabricar’ algo físico como un coche es complejo y costoso en el tiempo; pero ‘fabricar’ un servidor virtual o contenedor (especialmente esto último) no lo es. Por tanto, si diseñamos de forma adecuada nuestros servicios de SW, podemos limitarnos a respaldar únicamente los datos, no los sistemas que los ejecutan. En Tecknolab, en nuestro servicio DBcloudbin, hemos llegado al hito de que no hay ni un solo servidor físico o virtual del que se haga backup; únicamente se respaldan descriptores de servicios (las instrucciones para construir automáticamente el coche si es necesario) y los repositorios de datos, que están desacoplados físicamente de los servidores que los gestionan (por dos medios completamente independientes y heterogéneos; uno físico y otro lógico proporcionando cada uno una robustez añadida a las capacidades de recuperación).
- Combinar necesidades en un mismo proceso técnico (protección, disponibilidad y seguridad). Si tenemos que seguir realizando protección de los datos y debemos seguir asegurando que nuestros servicios están disponibles en caso de desastres y además tenemos que asegurar que los datos que manejamos no se corrompen accidental o intencionadamente (p.ej. ransomware) parece razonable aprovechar el mismo proceso para cubrir esas necesidades, simplificando y aumentando la eficiencia. Algunas soluciones modernas de backup permiten que sobre la misma copia de seguridad que hemos realizado de un sistema, podamos arrancar una nueva versión del servicio en caso de desastre en nuestro entorno primario (aprovechando por tanto ese backup para una casuística de disponibilidad de servicio); de paso, como tenemos toda una secuencia de backups en el tiempo de cada uno de nuestros repositorios, podemos identificar cambios inesperados (por ejemplo tasas de cambio en los datos fuera de un patrón razonable para ese repositorio de forma histórica) y alertar de ello como un potencial ataque de un virus. Ya hay fabricantes que proporcionan esta combinación de funcionalidades en el mercado.
Conclusiones
En resumen, no podemos sostener el modelo de ‘hacer las cosas como siempre’ con el escenario de escalado geométrico de los volúmenes de información a manejar. Esto es especialmente cierto en el ámbito de la protección de datos. Debemos cambiar los procesos, la forma de hacer las cosas y las soluciones para proteger lo que es (y cada vez más) el activo más importante de nuestras empresas: la información.
En Tecknolab, hemos aprovechado nuestra juventud y falta de herencia tecnológica para adoptar internamente procesos muy eficientes. Adicionalmente, hemos diseñado una solución de reducción de bases de datos empresariales, DBcloudbin, que nos permite segmentar de forma muy sencilla información a la que se debe aplicar políticas de respaldo de información muy distinta, simplificando el proceso con políticas intrínsecas de respaldo y reduciendo los costes de backup. Os animamos a probarlo y contactar con nosotros para cualquier duda al respecto.
por tecknolab | Jun 12, 2018 | BigData, Cloud, Tecnología
Las aplicaciones empresariales evolucionan muy rápido. Los requisitos funcionales son más sofisticados y necesitamos manejar más datos no relacionales (fotos, documentos, imágenes, videos….)
Esta necesidad incrementa en varios órdenes de magnitud el volumen de información a manejar. Esta explosión de datos genera una extraordinaria complejidad a nivel de desarrollo y, sobre todo, operaciones.
Tradicionalmente las aplicaciones empresariales consistían fundamentalmente en algún tipo de interfaz de usuario (con alguna tecnología más o menos sofisticada de formularios) que permitía a los distintos usuarios interactuar con el entorno para introducir y consultar datos que, de una u otra manera, acababan en una base de datos relacional tradicional (Oracle, SQL Server, DB2, Informix, …). La complejidad venía derivado de que, dependiendo de la aplicación y la empresa, algunas de esas tablas podían tener millones de filas y la consulta de datos por criterios muy variados resultaba en muy sensibles criterios de optimización de las consultas (el famoso ‘query plan’). En los aspectos más operacionales, el dolor de cabeza era la capacidad de recuperación en situaciones críticas (backup, replicación, procedimientos de recuperación de desastres,…).
Eso se ha mantenido así hasta hace relativamente poco (unos cuantos años), cuando esas aplicaciones fueron haciéndose más sofisticadas y necesitaban cubrir otras demandas del negocio. No era suficiente con guardar todos los datos de nuestro cliente en su ficha de cliente en la aplicación, teníamos también que guardar, por ejemplo, el documento de contrato firmado entre las partes y tenía que ser accesible desde la propia aplicación de gestión; o los mensajes de correo, con todos sus anexos, que hemos intercambiado con el cliente o proveedor en un determinado proceso de negocio. Esta casuística se ha resuelto habitualmente desde los departamentos de desarrollo de software de las empresas, de tres maneras alternativas:
- Guardamos esos datos en un servicio de ficheros y lo asociamos en la base de datos a través de un enlace. Esto es razonablemente sencillo pero da bastantes problemas de gestión, y también técnicos. Tenemos dos repositorios que gestionar (que sincronizar sus backups, por ejemplo). Si los datos son sensibles, necesitaremos políticas específicas de seguridad en dos medios (base de datos y sistema operativo) que no se integran de forma especialmente sencilla; también complicamos la consistencia transaccional (cancelar una transacción completa en base de datos ante un fallo es sencillo; si además tenemos datos en un filesystem, la cosa se complica).
- Guardamos esos datos en servicio de gestión documental o similar. En muchos aspectos es parecido al escenario anterior, con la ventaja de que un sistema documental proporciona más y mejores servicios de gestión, pero también una mayor complejidad en la gestión (debemos administrar dos sistemas complejos).
- Guardamos esos datos no relacionales en la base de datos. Esto es, a nivel de ingeniería de software, lo más sencillo; interfaz único (SQL), consistencia transaccional, un tipo de datos (BLOB) que permite manejar objetos de cualquier naturaleza. En muchos casos es la opción elegida por muchos clientes. En particular, donde la decisión es dirigida por el equipo de ingeniería de software.
Este último escenario nos lleva a que estas bases de datos ya no solo manejan datos relacionales, sino que deben gestionar volúmenes muy altos de contenido binario. Y, aunque las tecnologías más punteras de bases de datos empresariales son capaces de hacerlo, rápidamente descubrimos que el coste de infraestructura y operación se dispara. Estos entornos críticos requieren infraestructura de la máxima calidad y velocidad y eso se paga.
Esto nos lleva a buscar alternativas y últimamente, con la explosión del volumen de datos manejados, se ha hecho muy popular la alternativa de los Object Stores o almacenamiento de objetos, donde el servicio S3 de Amazon AWS se ha convertido en un estándar de facto. Parece sensato mover esos contenidos binarios a S3 o almacenamiento de objetos similares con varios beneficios claros e inmediatos:
- Almacenamiento ilimitado y prácticamente sin gestión.
- Costes mucho más reducidos.
- Posibilidad de explotar esos contenidos en escenarios alternativos (por ejemplo analítica avanzada, machine learning) sin impactar de forma directa en las bases de datos de los sistemas transaccionales.
- Simplificación o eliminación de las necesidades de backup convencionales.
- Posibilidad (dependiendo de la tecnología) de aplicar políticas de retención de la información que nos facilite el cumplimiento de normativas de retención de datos, de forma que el propio repositorio asegure la inalterabilidad e impida su borrado durante el periodo definido.
Las ventajas son múltiples; pero también hay inconvenientes, siendo el principal el hecho de que estos sistemas tienen un acceso a través de un API de programación que, sin ser muy complejo, nos obliga a cambiar toda la capa de acceso a datos y persistencia en nuestras aplicaciones empresariales para que guarden la información en este repositorio. Y eso puede llegar a ser un trabajo tedioso, sujeto a errores y con un cierto riesgo, proporcional al nivel de complejidad y obsolescencia de nuestras aplicaciones. Y casi más importante: supone desviar los recursos de ingeniería y desarrollo de software de nuestra empresa (siempre escasos) para resolver una problemática interna de IT, que no proporciona un valor funcional directo al usuario de negocio.
En este contexto, desde Tecknolab nos hemos propuesto proporcionar una solución que permita llevar los contenidos binarios a las distintas opciones de repositorio de objetos del mercado, tanto en servicio de Cloud pública (Amazon AWS, Microsoft Azure, Google Cloud Platform) como con los principales fabricantes de almacenamiento de objetos que permite un despliegue ‘on-premise’ en un CPD local (Hitachi HCP, Dell-EMC ECS, IBM COS, entre otros). Con este servicio, DBcloudbin, la configuración de la base de datos es inmediata y, lo que es más importante, transparente para la aplicación; con el mismo software, la aplicación sigue accediendo a los datos a través de la base de datos usando SQL como anteriormente, pero en realidad el sistema se encarga de leer los datos que se hayan movido al almacenamiento de objetos y proporcionárselo a la aplicación como si estuvieran en la base de datos. Esto nos proporciona todos los beneficios de tener los datos centralizados en la base de datos (acceso único, consistencia transaccional) pero con los ahorros de utilizar una infraestructura mucho más barata para aquellos datos que no necesitan la velocidad de acceso de una base de datos relacional. Para más detalles de la solución, visite https://www.dbcloudbin.com/solution
por tecknolab | Nov 28, 2017 | BigData, Estrategia
Una iniciativa bigdata debe empezar por una estrategia bigdata. Comentamos la aproximación recomendada.
Hoy por hoy un gran número de empresas de todos los sectores y tamaños (aunque especialmente las más grandes) están arrancando iniciativas de BigData, en parte por la presión de competencia y nuevos retos de negocio y, en parte, para qué ocultarlo, por una cierta ‘moda’ o presión del entorno (si mi competencia está metiéndose en esto, yo también, no voy a ser menos…).
La realidad, por sorprendente que parezca, es que tal y como reflejan recientes estudios de IDC, la mayoría de las empresas españolas están arrancando o planificando el arranque de iniciativas BigData en el corto plazo pero no saben por dónde empezar.
En este contexto, en muchos casos los resultados son trágicos porque se cometen errores de bulto. Uno de los más habituales es empezar por el componente tecnológico: “Montamos un DataLake”.El resultado, como digo, es trágico, en parte por el hecho de que los avispados comerciales del sector han creado una serie de mitos y leyendas que se han interiorizado.
Mito 1: Las nuevas tecnologías basadas en Hadoop son baratas y se montan en un periquete.
Esto es sustancialmente falso (o solo parcialmente correcto y una sobre-simplificación) que lleva a lanzarnos de cabeza sin una estrategia armada y, por supuesto, sin un caso de negocio y modelo económico medianamente robusto. Básicamente usamos el falso esquema mental, curiosamente habitual en muchos ‘top executives’ de abultadas nóminas de que si es mucho más barato que mis tecnologías habituales (de DWH en este caso) malo será que no le saquemos rendimiento. Y en este contexto, Murphy siempre sale triunfal y el resultado en la mayoría de los casos es un montón de presupuesto consumido sin nada que llevarse a la boca de resultado ‘real’.
Recomendación Inicial: Estrategia y modelo económico primero. Procesos y organización después. Tecnología, al final. Experimenta, prioriza y monitoriza (adapta y ajusta tu modelo).
En realidad son conceptos que llevo usando desde hace muchos años en consultoría de transformación de cualquier área tecnológica, pero es más aplicable que nunca a este ámbito.
Una gran debilidad de los países latinos es nuestra proverbial animadversión por la estrategia. Somos acción. Eso de planificar es de cobardes. La capacidad de adaptación e improvisación del carácter latino es un gran activo a mi juicio pero siempre adecuadamente integrado en una planificación estratégica robusta.
En este sentido, un primer error es confundir negocio ‘data-driven’ (dirigido por datos) con tecnología bigdata. Una cosa no implica la otra necesariamente. Debemos identificar nuestros escenarios de negocio data-driven y cómo los vamos a ejecutar. Solo adoptaremos nuevas tecnologías bigdata si tenemos una clara justificación para ello; y lo modelizaremos (no me refiero técnicamente, sino con un business case; hablaré de ello en más detalle en posteriores entradas de este blog).
Nuestra aproximación a la estrategia de bigdata es un modelo bidireccional (top-down y bottom-up). El modelo top-down, de negocio, se encargará de la identificación de esos escenarios de negocio ‘data-driven’, modelizándolo económicamente (valor de negocio) y requisitos de datos (qué datos y potenciales modelos analíticos necesito para implementarlo). El modelo bottom-up es un modelo de catalogación, que nos dibuje qué fuentes de datos (potenciales o reales) tenemos en nuestros procesos de negocio. La intersección de ambos nos dará el análisis de viabilidad y una primera modelización de costes. En este punto podremos tomar decisiones y plasmarlo en un plan estratégico; esto es, sustancialmente, qué escenarios abordamos primero (los más baratos entre los de más impacto), como vamos a monitorizar el progreso (cuales son mis KPIs?) y como vamos a retroalimentar nuestro modelo con la realidad a medida que la vamos ejecutando que nos permita ajustar nuestras expectativas.
