Almacenamiento de datos en la nube

En las aplicaciones de negocio, el almacenamiento es uno de los puntos claves que tenemos que garantizar. Por ello, es fundamental hacernos algunas de las siguientes preguntas:

• ¿Cuánto almacenamiento vamos a necesitar?
• ¿Podemos estimar el crecimiento de este almacenamiento para los próximos años?
• ¿Todo el almacenamiento es para datos relacionales?
• ¿Cuántos usuarios van a acceder a este almacenamiento?

Resolviendo estas, y otras cuestiones, nos podemos plantear una arquitectura en la nube optimizada para nuestra aplicación.

¿Por qué queremos optimizar si en nuestro DataCenter no tenemos problemas de recursos y en la nube siempre nos cuentan que nunca tendremos problemas de recursos?

Si somos capaces de optimizar recursos de nuestra aplicación, el coste en la nube también estará optimizado y esto es algo que… ¡Nos preocupa a todos! Tener recursos ilimitados nos lleva a pagar grandes cantidades de dinero por esos recursos que tienen un coste por uso.

Probablemente la mayoría de las aplicaciones de negocio actuales son migrables a la nube en modo IaaS, o lo que es lo mismo, llevarlas a un Hosting escalable donde, además del alto coste de la infraestructura que contratamos en la nube, seguimos teniendo un alto grado de complejidad y administración de esos servidores. El éxito de estas aplicaciones pasaría por hacer uso, en la medida de lo posible, de los servicios PaaS que ofrece la nube para la ejecución de nuestros servicios y clientes.

Sería muy sencillo clonar nuestro SQL Server y ponerlo en una máquina virtual en la nube para seguir dando soporte a capa de almacenamiento de datos de nuestra aplicación. Sin embargo, lo ideal es ser capaces de llevar esos datos a SQL Azure o, inclusive, plantearnos por qué esos datos tienen que estar en un almacenamiento Relacional-Transaccional.

En la nube tenemos diversos tipos de almacenamiento para dar soporte a las necesidades de nuestras aplicaciones de negocio, como pueden ser SQL Azure, MongoDB, Tablas, etc. Todos ellos como servicio PaaS.

Si hablamos de Azure, estos son los tipos de almacenamiento disponibles:

• Datos relacionales en SQL Azure o MySQL
• Grafo de objetos JSON en DocumentDB
• Datos semi-estructurados planos en Azure Storage Tables
• Ficheros en Azure Storage Blobs
• Grafo de objetos binarios en Azure Storage Blobs
• Mensajes entre sistemas o procesos en Azure Storage Queue
• Cache con Redis
• Documentos NoSQL en MongoDB
• Big Data en Azure HDInsight o Azure DataLake

¿Muchas opciones?

Pensemos que no todo tiene que ser SQL Server o su gemelo SQL Azure. Veamos algunos ejemplos:

• Es muy probable que podamos almacenar los datos de las alertas en una tabla de Azure Storage o en una Cola de mensajes en Azure Storage Queue
• Utilizar Cache para mejorar el rendimiento de las consultas de los datos que no cambian con frecuencia, por ejemplo, el listado de empleados de la compañía.
• Guardar los datos de las solicitudes de vacaciones en documentos JSON con DocumentDB o MongoDB.

Una buena arquitectura de datos en la nube tiene en cuenta algunos de los siguientes puntos:

• Aunque el almacenamiento puede ser limitado, debemos de tener estrategias de particionado de los datos. Por ejemplo: por cliente, por funcionalidad, etc.
• ¿Cuál es el origen de los datos? ¿Necesitamos procesos de integración/transformación de los mismos?
• En cuanto a seguridad, ¿podemos almacenarlos en la nube? ¿Quién puede ver la información?

Aprovechemos la nube para plantear una arquitectura de datos adecuada que aproveche las capacidades que nos ofrece para mejorar el rendimiento y optimizar los recursos, con el objetivo de que nuestra aplicación se ejecute en un modelo optimizado de almacenamiento de datos en, la medida de lo posible, modo PaaS.