El proceso es muy sencillo, solo tienes que decirnos en qué estás interesado y te llegará un informe sobre la tecnología o la solución seleccionada:

• ¿Te interesa saber más sobre alguna tecnología?
• ¿Te interesa saber más sobre alguna solución?

CONSIGUE TU INFORME PINCHANDO AQUÍ

Y tranquil@… No habrá ninguna acción promocional a posteriori a no ser que se solicite expresamente.

Si por el contrario, desea que le llamemos para ampliar información indíquenoslo enviando un correo a info@prosol.com

Estamos ya incorporando de forma masiva las tecnologías de No-SQL en nuestras aplicaciones y servicios TI. Una de las que me encuentro más frecuentemente es la de la base de datos documental MongoDB, y me gustaría compartir mi preocupación por la escasa atención que se presta a las operaciones de copia de seguridad de este tipo de entornos. Entiendo que se produzca cuando libros como “Mastering MongoDB 3.X” de Alex Giamas (2017), que he utilizado para tratar de conocer con cierto detalle el funcionamiento de la plataforma, plantea una base de datos que permite a los desarrolladores su total independencia de un DBA tradicional (El mensaje de la base de datos autónoma de Oracle da continuidad a esta idea). La parte de Ops en el concepto de DevOps se nos cae. Partiendo de esta idea, el autor vuelve a la realidad cuando describe las diferentes operativas para optimizar los entornos y sacar partido de la plataforma, y detalla cómo hacer frente a la operativa diaria básica que requiere toda base de datos y que habitualmente hace un DBA (Optimización de queries, análisis de rendimiento, balanceos, índices, etc.).

Uno de los puntos que más me llamó la atención es la parte dedicada a las copias de seguridad, a la que dedica más tiempo del habitual en este tipo de libros. Plantea varios escenarios de trabajo: réplicas, replicas en la nube en un servicio de MongoDB-as-a-Service, réplicas con retardo en un nodo, snapshots, copia de un nodo desconectado & copia de los logs, dumps del sistema, copias del file system sobre el que se apoya la base de datos (A lo bruto), etc. Vamos que alternativas no faltan, y mejor utilizar la consola que te ofrece la versión de pago para hacer estas cosas.

Las limitaciones vienen cuando uno pone las funcionalidades de replicación (Réplica Sets) y particionado (Sharding) en funcionamiento, que habitualmente se hace para hacer frente a volúmenes grandes de datos y necesidades de rendimiento. En ese momento, el autor prefiere quitarse de en medio y recomendar hacer uso de una aplicación específica de backup porque todos los planteamientos anteriores empiezan a ser un engorro más que una ayuda. Esto me lleva a insistir en una tecnología de copias de seguridad para este tipo de bases de datos (También para la base de datos columnar Cassandra) que compró Rubrik hace meses ya, y que ha incorporado a su plataforma. Tiene una integración con MongoDB que permite hacer copias programadas en caliente, copias consistentes a nivel base de datos, copias completas e incrementales, etc.; pero lo más destacable es que permite hacer recuperaciones PIT (Point in Time) y en clústeres de igual o distinta tipología de la que hicimos backup (Lo más habitual que me he encontrado es un clúster de tres nodos en producción, y una configuración “single-node” en preproducción, aunque no es lo recomendado por el autor del libro), que es justo la operativa que el autor del libro indica como necesaria para poder hacer frente a los riesgos más habituales en este y cualquier sistema TI.

Me alegra comprobar que el backup no es un pensamiento secundario en el planteamiento del libro, me alegrará más cuando vea sus recomendaciones en práctica.

En cualquier caso, el libro ofrece una visión completa de la plataforma, y es de lectura recomendada para los que nos queremos saber un poco más de este tipo de herramientas.

En vacaciones tenemos tiempo para lecturas más o menos espesas, espero esta sea de las menos espesas.

En mi caso, ya no estoy de vacaciones, y me ha llamado la atención este artículo al respecto de empresas que parecen ir a la contra del mercado: Se “bajan” cosas de la nube (IaaS) a su propia infraestructura dedicada. Son ejemplos de empresas que descubren que la nube lleva a unos gastos operativos de difícil control, y en ciertos casos muy elevados cuando las cargas que tenemos desplegados en la nube son estables (O al menos buena parte de las mismas lo son), o muy ligadas a otros entornos. Estas mismas empresas afrontan la dificultad de estimar los costes reales de cuánto costaría desplegar estas mismas cargas en una infraestructura dedicada (Hay una comparativa de costes de almacenamiento, que no me termino de creer porque la media no es el único factor que distorsiona los costes de un sistema de almacenamiento), pero que aun así deciden saltar de la nube a la tierra.

No hemos terminado de subir, cuando ya nos empiezan a hablar de bajar. Veo en este artículo una confirmación de que muchas veces olvidamos la condición necesaria para que la nube (IaaS) sea barata, y es que la baratura se da cuando lo que necesitas es flexibilidad. Cuando no la necesitas, puede que tenga sentido la aproximación “híbrida”. Por híbrido no hablo de aplicaciones que desbordan a la nube en caso de necesidad (Algo de lo que todo el mundo habla, pero que con las aplicaciones tradicionales veo complicado o casi imposible), sino de servicios IT desplegados “abajo” y servicios IT desplegados “arriba”, con una cierta integración.

Podéis leer el artículo aquí:

https://www.theregister.co.uk/2019/08/09/repatriation_cloud_data/

Si quieres saber cómo podemos ayudarte a tener éxito en los entornos nube y en los terrenales, puedes ver cómo en www.prosol.com