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 | 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.
por tecknolab | Nov 28, 2017 | Cloud, Estrategia, Tecnología
La adopción de Cloud Publica en las empresas puede llevar a identificar alguna sorprendente limitación. Yo propongo cinco (y ninguna de ellas es la seguridad).
Hay una clara tendencia en las empresas de todos los tamaños de mover cargas a los distintos servicios IaaS de Cloud Pública que encontramos en el mercado, siendo Amazon AWS, Microsoft Azure y Google Cloud Platform las principales ofertas de carácter global (con un claro liderazgo a día de hoy de AWS).
Cuando una empresa toma esa decisión, normalmente habrá realizado algunos pilotos y pruebas de concepto con la solución y, suponemos y deseamos, realizado algunos números para definir el caso de negocio.
Mi experiencia con este proceso es que hay al menos cinco cosas que sorprenden porque podemos creer que debería estar resuelto o resultar sencillo, cuando nos lanzamos a este viaje. Y no, ninguno de ellos es la seguridad, sempiterno ‘sambenito’ que ha sufrido históricamente y a mi juicio poco fundado (en general es más seguro que muchas alternativas de servicio privado). Estas son cinco cosas con las que previsiblemente chocarás siendo una empresa de un tamaño significativo, no un usuario individual o pequeña organización o grupo de trabajo:
1.- Definir cuotas de consumo o recursos para limitar el uso a un determinado presupuesto
En un entorno privado los recursos están delimitados de forma explícita. Son los que son. Una gran ventaja de la nube pública es que la capacidad es (casi) ilimitada y podemos crecer todo lo que queramos. Pero en una gran empresa, eso es un arma de doble filo y no es raro que en nuestro modelo organizativo queramos poner límites por organizaciones o grupos que, de hecho, mapeen los presupuestos que cada una de esos grupos tengan asignados. Pues bien, eso que parece obvio, no resulta tan sencillo de hacer porque los principales servicios de Cloud Pública no permiten definir cuotas, únicamente alarmas (y en muchos casos no se puede gestionar de forma sencilla por los recursos de cada grupo u organización de nuestra empresa). Esas alarmas no previenen del consumo adicional de recursos, únicamente avisan.
2.- Previsibilidad del coste mensual
Lo sabemos, o lo intuimos cuando nos embarcamos en la Nube; esto es pago por uso en el más estricto sentido del término. En principio, una vez más, es bueno, solo pagamos por lo que usamos. Pero en las empresas, especialmente en los departamentos de gestión económica, la imprevisibilidad de un coste genera muchos nervios. Lo primero que se exige al responsable de un determinado servicio es una cifra de previsión del gasto, muchas veces a largo plazo. Si combinamos este con el punto anterior, vemos que esta previsibilidad es mucho menor de lo que pudiéramos haber considerado al principio y requerirá posiblemente modelos económicos mucho más sesudos y sofisticados de lo que creeríamos en un principio.
3.- Transparencia y facilidad en la imputación de costes
Uno de los principios del modelo Cloud, transparencia de costes. Si, así es. Dado que te facturan por lo que consumes es evidentemente fácil recibir una ‘receta’ con todos los items facturados y el coste que te supone. Y quizá asustarse con la minuta. Pero en una empresa mediana/grande eso no es suficiente, uno tiene que imputar a su vez esos costes entre las distintas organizaciones y centros de coste que la componen. Y ahí la cosa se pone más difícil, con poca ayuda intrínseca de las herramientas del proveedor de servicios pudiendo llegar a ser un verdadero infierno y un significativo coste en esfuerzo y tiempo el mapear esos costes internamente.
Yo recuerdo una gran empresa multinacional española de rancio abolengo que vino, una semana más tarde, a pedirnos que rescatáramos de un almacén de chatarra un servidor que habían retirado y que en realidad era de ‘alguien’ y hasta se usaba. Una organización con ese nivel de control interno, imagina lo que puede sufrir en un modelo como éste.
La prueba de que esto es un problema real es que ha surgido un nicho de mercado de empresas que han generado soluciones normalmente SaaS cuyo propósito fundamental es ayudar a los clientes a controlar y gestionar sus costes de nube pública, integrando de forma más sencilla los distintos interfaces para obtener información y reportarla de forma adecuada para el cliente y su modelo organizativo. Y eso tiene un coste adicional, claro.
4.- Comparación de costes entre Nubes
Una máquina virtual es una máquina virtual. Está inventada, no tiene grandes diferencias y funciona más o menos igual en lo básico la pongamos a correr en una infraestructura virtual basada en vSphere de vmware en nuestro entorno privado o en una instancia de AWS en Ohio o en un nodo de Azure en Irlanda. Además la tipología del servicio (como servicio IaaS) también es muy similar al menos en lo que se refiere a hasta donde llega el proveedor y hasta donde la responsabilidad es tuya.
Todos los servicios de nube pública tienen modelos de preciario públicos y razonablemente transparentes (esto es la Nube…) con lo que una vez comparado peras con peras (esto es, asegurado que a nivel de rendimiento o cualquier otra característica que para nosotros sea relevante las instancias son similares) el tema del precio parece fácil: si la opción A es un 10% más barato, pues el servicio en global para nuestra empresa será un 10% más barato (más o menos). Así de simple.
Nada más lejos de la realidad. Hay múltiples factores que tumban esta aseveración simplista pero detallaré solamente dos:(1) por un lado el modelo de costes es mucho más complejo que el de ‘precio de máquina virtual por hora’. Hay decenas de conceptos facturables (desde las direcciones IP al tráfico de red o a conceptos de monitorización) que no son homogéneos y pueden hacer variar los costes de forma significativa (como un 10 o un 15%); (2) por otra, están los descuentos por uso sostenido, que tienen entre los tres principales players tres modelos radicalmente diferentes (AWS descuenta por la reserva a priori de instancias que además se gestiona por tipo de instancia complicando adicionalmente el modelo, Google usa un modelo de descuento automático para instancias permanentes y Azure lo integra en la gestión de contrato global de licencias que el 90% de las empresas grandes y medianas tiene con Microsoft, el Enterprise Agreement).
5.- La nube pública es la opción más barata
Un servicio masivo como el de AWS, Azure o Google es el que, en principio, tiene todos los ingredientes para sacar el máximo partido de la economía de escala. Esto sumado a la fiera competencia en este mercado lleva al escenario lógico de que el coste de un servicio de Cloud Pública debe ser necesariamente más bajo que otras alternativas (que tendrán sus opciones por otros factores pero difícilmente pueden competir en precio).
Pues… no siempre. Mi propia experiencia y otras que he tenido la oportunidad de escuchar, después de razonablemente sofisticadas comparativas, han llegado a la conclusión de que puede ser más caro. Este punto daría para una enciclopedia y en general cada organización es un mundo y su situación y escenarios son demasiado específicos como para poder aseverar de forma rotunda y generalizada si es más barato o más caro. Mi reflexión y resumen es que (1) cuanto más madura, flexible y avanzada es la gestión y operación de sistemas y la arquitectura de aplicaciones en una empresa, más probabilidades tiene de rentabilizar un servicio de Cloud Pública y (2) modeliza de forma razonable y lo más completa posible tus escenarios y costes de forma que puedas valorar de forma correcta si es una opción ventajosa a nivel de costes para tu empresa. Y si, es algo que resulta lo suficientemente complejo de analizar como para que algunos nos ganemos la vida con ello.
