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 | 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.
