Almacenamiento de objetos es un método de almacenamiento de datos libre de jerarquía, generalmente utilizado en la nube, pero con varios a la hora de implementarlo en un formato self-hosted u on premise
. 
Al contrario de otros métodos de almacenamiento de datos, el almacenamiento basado en objetos no utiliza un árbol de directorio. Las unidades diferenciadas de datos (objetos) existen en el mismo nivel en una agrupación de almacenamiento. 
 
A diferencia del almacenamiento clásico en archivos, en el almacenamiento de objeto los metadatos se pueden elegir libremente. Por lo tanto, en lugar de incluir únicamente información de nombre, fecha de creación, tipo de archivo o similares, se pueden introducir metadatos específicos para cada archivo. Esto permite integrar, por ejemplo, información de la aplicación correspondiente o datos de usuario.

Para acceder a los datos (y comunicarse con el sistema de almacenamiento) se utiliza el protocolo de transferencia de hipertexto (HTTP) y una API REST. Esto simplifica en gran medida la conexión entre el cliente y el almacenamiento de objeto, ya que el protocolo HTTP, usado habitualmente en Internet, es compatible con todos los ordenadores. La comunicación con el sistema de almacenamiento solo requiere unos pocos comandos:

• PUT: crear un objeto

• GET: leer un objeto

• DELETE: borrar un objeto

• LIST: crear una lista de todos los objetos

Nuestra tecnología permite aprovechar el almacenamiento de objetos como backend a la hora de persistir y resguardar datos tales como:

• Grabaciones
• Backups
• Audios de IVR
• Mensajes de Voz
• Música de espera
• Video (próximamente)
• Pantalla (próximamente)

Si además consideramos la buena práctica de desplegar el motor de base de datos PostgreSQL separado, se ganara exponencialmente en robustez, tanto a la hora de trabajar en los backups y/o réplicas, así como también respecto a poder afinar los recursos óptimos para el desempeño del otro de los componentes que deben persistir y resguardar los datos del negocio. 
El planteo entonces Object Storage y PostgreSQL separados del resto de OMniLeads implica que nuestra aplicación queda totalmente “stateless”. Es decir que la instancia que aloja omnileads puede ser destruida por completa y regenerada a partir de aprovisionar una nueva instancia con las variables de entorno pertinentes. 

Desde que la accesibilidad a la infraestructura de servidores Linux, es un hecho de tan solo unos segundos a partir de disparar un comando a una API o con un par de clicks sobre una interfaz web muy amigable. Vale aclarar que alguien antes paso la tarjeta de crédito. 

A lo que voy es que podemos disponer de la distribución de linux deseada en la versión deseada sobre una instancia dimensionada con exactitud para el servicio/aplicación que debe alojar. Para nuestro caso sería contar con una instancia de OMniLeads disponible para atender a un determinado suscriptor del CCaaS. 

La particularidad es que además este OMniLeads (en un contexto de Cloud o Hybrid-Cloud) utiliza el motor de base de datos Postgres y el almacenamiento de objetos como parte de un servicio cloud osea “llave en mano”. A nivel tareas de IT se trata de desocuparse de los backups, actualizaciones y demás actividades de un departamento de IT.

Entonces aprovechando esta ventaja de simplificar la puesta en marcha de un cliente, así como también la de poder redimensionar los recursos para atender el crecimiento/decrecimiento de las operaciones en tan solo cuestión de minutos de “downtime”, entre otras, es que OMniLeads se plantea un evolucionar constante sobre la arquitectura en pos de explotar cada vez más este modelo de negocios. 
Hablando de actualizaciones, lo que sigue en la cadena es que tenemos la opción de que por cada una de ellas, sencillamente se dispare un deploy sobre una nueva instancia Linux nueva, esta nueva encaje sobre el rompecabezas de manera totalmente transparente quedando online para seguir atendiendo solicitudes en cuestión de minutos.