¿Desea su organización simplificar las operaciones de desarrollo de bases de datos?
¿Se está convirtiendo su base de datos en un cuello de botella para innovar con rapidez?
¿Quiere ahorrarse millones de $$ en costes de licencias de bases de datos?
Siga leyendo.
Estado del DevOps de bases de datos
Estado del DevOps de bases de datos es una encuesta sobre las tasas de adopción de DevOps entre los profesionales de SQL Server. Más de 1000 profesionales de SQL Server respondieron a la encuesta. Los encuestados procedían de todo el mundo y representaban una amplia gama de puestos de trabajo, tamaños de empresa e industrias.
Los resultados de la encuesta son muy positivos. Merece la pena destacar algunas de ellas:
el mayor reto a la hora de integrar los cambios de la base de datos en un proceso DevOps seguiría siendo sincronizar los cambios de la aplicación y de la base de datos
Otro...
El mayor inconveniente identificado en el desarrollo tradicional de bases de datos en silos es el mayor riesgo de despliegues fallidos o tiempos de inactividad al introducir cambios. Le siguen de cerca la lentitud de los ciclos de desarrollo y publicación y la incapacidad de responder con rapidez a los cambiantes requisitos de la empresa.
Y otra...
Aumentar la velocidad de entrega de los cambios en las bases de datos y liberar a los desarrolladores para que realicen más trabajo de valor añadido son los principales factores que impulsan la automatización de la entrega de cambios en las bases de datos.
Los retos que se destacan aquí no se mencionan en el contexto de SQL Server solamente, sino que serían aplicables a cualquier base de datos relacional. Usted puede estar usando Oracle, Postgres, MySQL, MariaDB o cualquier otra base de datos relacional para el caso y sería muy frente a estas cuestiones. ¿Por qué?
¿Por qué las bases de datos relacionales no son adecuadas para DevOps?
Es habitual que una aplicación opere con datos de varias tablas de un RDBMS. Por ejemplo, realizar un pedido puede utilizar las tablas Cliente, Pedido y Producto. Cada tabla tiene varias columnas con tipos de datos estándar específicos de una base de datos. Las tablas pueden tener restricciones primarias, de referencia y de clave externa. Los desarrolladores que crean aplicaciones con una base de datos relacional suelen utilizar un Object Relational Mapper (ORM), como Hibernate o Java Persistence API para desarrolladores Java. También existen ORM similares para otros lenguajes. Los ORM capturan la compleja estructura subyacente de la base de datos y permiten a los programadores crear aplicaciones de forma natural utilizando su lenguaje.
Los ORM también utilizan un proveedor de persistencia y permiten que la aplicación sea independiente de la base de datos subyacente. Este proveedor de persistencia crea un vínculo entre la clase específica del idioma y la estructura de la base de datos. Por ejemplo, asigna una clase a una tabla o a varias tablas, vincula los tipos de datos del lenguaje a los tipos definidos en la base de datos y captura la relación entre las tablas. Teóricamente, un programador puede utilizar un proveedor de persistencia diferente para utilizar un RDBMS diferente para la aplicación. Pero esto dista mucho de ser una experiencia práctica.
Cualquier cambio en la base de datos requiere la actualización de las clases ORM, de lo contrario la aplicación podría no funcionar. Por ejemplo, añadir una nueva tabla puede significar una nueva clase Java o actualizar una clase existente. El cambio de un tipo de datos en una columna requiere que se actualice la definición de la clase, de lo contrario la aplicación ni siquiera compilará. Añadir una nueva columna significa añadir un nuevo campo en la clase. Cualquier cambio requiere actualizar las clases y volver a empaquetar la aplicación.
Los cambios en la estructura de la base de datos son necesarios todo el tiempo para satisfacer las necesidades cambiantes del negocio. Pero si los DBA realizan un cambio en la base de datos y las clases ORM no se actualizan, se produce una desconexión. El despliegue de la aplicación debe coordinarse con la actualización del esquema de la base de datos. Existen herramientas como Ruta de vuelo, Liquibase y otros que integran el despliegue de aplicaciones y bases de datos. Pero a menudo no se permite a los desarrolladores realizar cambios directos en la base de datos de producción. Una desconexión provocaría que la aplicación no funcionara y que el negocio se resintiera. Las prácticas DevOps pueden ayudar definitivamente a resolver estos problemas, ya que requieren una estrecha colaboración entre los desarrolladores que están creando aplicaciones y los DBA que están actualizando los scripts de la base de datos.
Sin embargo, según la encuesta, más del 50% de los encuestados no han adoptado DevOps en la actualidad.
Incluso si se integraran los cambios en las bases de datos en un proceso DevOps, se plantearían retos.
Sincronizar los cambios en la aplicación y la base de datos cuando las clases ORM deben sincronizarse con la estructura de la base de datos backend es el mayor reto. Los administradores de bases de datos pueden querer estructurar la base de datos de una forma determinada que puede no ser óptima para el desarrollo de aplicaciones. Aplicar la coherencia en el desarrollo de aplicaciones y bases de datos es el siguiente reto importante para garantizar un DevOps de bases de datos sin fisuras.
Un desarrollo en silos afecta gravemente a su capacidad para innovar con rapidez y aportar valor a su empresa.
Como se muestra en esta imagen, las implantaciones fallidas al introducir cambios, la lentitud de los ciclos de desarrollo/lanzamiento y la incapacidad para responder a las necesidades de la empresa representan más del 60% de los inconvenientes.
La velocidad de entrega de los cambios en las bases de datos es la mayor preocupación de los DevOps de bases de datos.
Entonces, ¿qué hacer?
¿Cómo simplifica NoSQL el DevOps de bases de datos?
La base de datos documental NoSQL ayuda a simplificar las operaciones de desarrollo de bases de datos.
¿Cómo simplifica NoSQL el DevOps de bases de datos?
- Flexibilidad del esquema - Los desarrolladores necesitan una única base de datos que pueda almacenar datos estructurados, semiestructurados y no estructurados que cambian rápidamente. La base de datos de documentos NoSQL ofrece flexibilidad de esquemas al permitir a los desarrolladores operar directamente sobre datos JSON y derivar significado de ellos
- Sin desajuste de impedancia - Sin ORM para la aplicación, no hay desajuste de impedancias entre las clases del dominio y la estructura de la base de datos. Sólo hay que actualizar el código de la aplicación y no es necesario coordinarse con los cambios del esquema.
- Escalabilidad - Uno de los inconvenientes mencionados en el informe es la incapacidad de adaptarse a los cambiantes requisitos empresariales. Esto pone de manifiesto que la escalabilidad es uno de los principales retos de DevOps. Si el volumen de datos, el número de consultas o los tipos de índices necesarios para dar soporte a la aplicación cambian, la base de datos tiene que cambiar para adaptarse a esos cambios. No en semanas o meses, sino hoy mismo. Ninguna base de datos SQL se ejecuta en hardware básico y tiene una arquitectura de escalabilidad horizontal, a diferencia de la escalabilidad vertical de los RDBMS. Sharding puede ayudar con la escalabilidad en RDBMS, pero eso es una complejidad adicional que ahora hay que tratar.
Más información por qué las empresas se pasan a NoSQL.
Qué Base de datos NoSQL es el preferido por GE, Marriott, Verizon, United, LinkedIn, DIRECTV y muchos otros?
¿Cuáles son otros ventajas de Couchbase?
- Arquitectura distribuida homogénea - sin maestro/esclavo
- Lenguaje de consulta tipo SQL para consultar documentos JSON
- Almacenamiento automático mediante vBuckets
- Arquitectura de memoria preferente reduce la necesidad de una capa de caché adicional
- Replicación entre centros de datos
- Múltiples SDK
- Base de datos en servidor o dispositivo móvilcon una sincronización completa entre ellos
- Diferentes marcos de orquestación de contenedores
NoSQL no es una panacea ni mucho menos. Si está construyendo un sistema que necesita una lógica de transacción compleja o almacenamiento de datos en tiempo real, entonces RDBMS puede ser una mejor opción. Sin embargo, resuelve sus problemas de escalabilidad y agilidad y simplifica las operaciones de desarrollo de bases de datos.
He aquí un magnífico vídeo sobre la migración de bases de datos relacionales a NoSQL:
Aquí hay otro vídeo interesante que muestra por qué Marriott pasó de Relational a NoSQL:
Hay muchos más vídeos disponibles en Couchbase Connect 2016.
Y algunos blogs más relevantes:
- Pasar de Relational a NoSQL: Cómo empezar (libro blanco)
- Paso de la base de datos Oracle a Couchbase
- Pasar de MySQL a Couchbase
- Pasar de SQL Server a Couchbase - Parte 1 (modelado de datos), Parte 2 (migración de datos), Parte 3 (próximamente)
- Pasar de MongoDB a Couchbase
- Migra tu API REST de MongoDB con Mongoose a Couchbase con Ottoman
- Migración de una base de datos relacional a Couchbase
- Las 5 razones principales por las que las empresas sustituyen Oracle por Couchbase
Hable con nosotros:
[...] Fuente: blog.couchbase.com/nosql-simplifies-database-devops/ [...]