Seleccionar página

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