El estado de la industria de bases de datos de código abierto en 2020: segunda parte

Una serie de blogs de cuatro partes de Matt Yonkovit, Director de Experiencia de Percona. Lea los otros blogs de Matt en esta serie: «Bases de datos y el tamaño del mercado», «La base de datos de código abierto más popular de 2020» y «¿Cuándo el código abierto no es realmente abierto?»

Migración de Software Propietario a Código Abierto

Hay dos fuentes principales de crecimiento en el espacio de bases de datos de código abierto. Primero está el desarrollo de nuevas aplicaciones (más sobre eso más adelante). El segundo es la migración y las empresas que se alejan del software propietario.

No puede ir a un sitio web de un proveedor de base de datos o en la nube sin ver mucha información sobre por qué debería abandonar su antigua tecnología de base de datos y actualizar a una nueva y brillante de código abierto.

Pero realmente, ¿cómo sucede esto? La respuesta es una buena cantidad, incluso si no es tanto como quieren estos vendedores. Las razones de esto son complicadas, pero las he resumido, basándome en lo que he observado.

¿Cuál es la motivación de la migración?

Muchas de las migraciones que vemos en este momento involucran aplicaciones pequeñas y medianas. Estas migraciones suelen ser oportunistas y forman parte de los esfuerzos de modernización.

Las aplicaciones más grandes y complejas no se migran en masa, excepto que los sistemas no tienen que ser reemplazados por completo. Esto ha llevado a muchas empresas a gestionar sus bases de datos propietarias junto con sus bases de datos de código abierto.

En cuanto a las migraciones más grandes, ¿por qué algunas se han ralentizado o ralentizado?

La mayor parte de esto parece derivar de la compra interna y el bloqueo del vendedor. El siguiente escenario es común:

  • Un ejecutivo de la empresa quiere alejarse de un proveedor propietario (utilicé Oracle aquí, por ejemplo) y toma la decisión de comenzar a reemplazar los sistemas para reducir los costos y la dependencia del proveedor.
  • La gerencia de medios acude a sus DBA enfocados en Oracle (muchos de los cuales han estado haciendo esto durante 10 a 15 años) y les dice que se están mudando a algo diferente a Oracle y que deberían comenzar a investigar alternativas. Esto hace que su equipo comience desde una posición de miedo, ya que les preocupa que su trabajo esté en línea si se alejan de Oracle.
  • A los equipos de desarrollo de aplicaciones se les informa del plan para migrar a una nueva base de datos.
  • La administración de aplicaciones y sus partes interesadas (a menudo ejecutivos de negocios que necesitan nuevas aplicaciones, funciones y nuevos flujos de ingresos) no ven el valor de migrar si ese movimiento interrumpe otros trabajos de ingresos en los que están involucrados. y esto también es un problema.
  • La empresa está de regreso y está tratando de reducir su factura de licencias con Oracle. En lugar de llegar a un ahorro de costos, Oracle dice que eliminar algunos servidores no ahorra mucho dinero, porque le han dado a la empresa un descuento por volumen. Entonces, cualquier ahorro de costos aquí se evapora.
  • El esfuerzo de migración pierde fuerza y ​​se desata durante varios años antes de que el ciclo se repita, a menudo bajo una nueva administración.

También se observa que no todas las migraciones ellos son migraciones Hemos notado que la gente a menudo confunde el término “migración” cuando se trata de proyectos de modernización. Muchas empresas están realizando proyectos de modernización más grandes, donde su base de datos es solo un componente.

Cambiar la base de datos back-end de una aplicación que migra de Oracle a MongoDB es muy diferente a reemplazar una aplicación heredada completa de N niveles con una aplicación de nube nativa nueva o completamente rediseñada. La última opción se trata más de reemplazar una pila de tecnología completa e implica una recuperación de arriba a abajo. Aquí es donde vemos más cambios en aplicaciones complejas.

¿Quién alimenta el actual crecimiento del espacio en la nube y el código abierto?

Una palabra: desarrolladores.

Una de las tendencias que vemos es que los desarrolladores y arquitectos de aplicaciones se están convirtiendo en los que eligen las tecnologías de base de datos que utilizan en sus aplicaciones.

En el pasado, los DBA o los equipos de infraestructura a menudo trabajaban duro para consolidar y reducir la complejidad de las tecnologías que usaban. Esto ha transformado a muchas empresas en lo que muchos llaman un «negocio de base de datos única» (¿recuerdan cuando la gente decía que éramos una «Tienda de Oracle» o una «Tienda de SQL Server»?)

Este tipo de consolidación se ha convertido en una cosa del pasado. Hay tantas bases de datos geniales y especialmente diseñadas que no puede evitar querer explicar.

Los datos de nuestra encuesta reciente respaldan esta tendencia creciente de uso de múltiples bases de datos:

Entonces, ¿cuál es la razón de este crecimiento en el espacio de múltiples bases de datos y múltiples nubes?

El crecimiento en el espacio de múltiples bases de datos podría ser una estrategia comercial, pero como el crecimiento en el espacio de múltiples nubes, esto también es el resultado de permitir que los usuarios/desarrolladores tengan un acceso más fácil a la tecnología.

La mitad de más poder en manos de los desarrolladores y usuarios finales es excelente porque acelera el tiempo de innovación y puede permitir que las empresas logren un mayor rendimiento y aumenten los ingresos. Pero también podría crearse un problema de “legado”.

En el entorno actual de bases de datos, los desarrolladores son los reyes. Pero son reyes con más opciones y elecciones que nunca.

Hemos visto repetirse el mismo patrón en numerosas organizaciones grandes. Diferentes equipos de desarrollo eligen diferentes tecnologías para sus aplicaciones. El DBA, SRE, Sysadmins, etc. heredan o respaldan esas decisiones tecnológicas a largo plazo.

Un acceso más fácil a diferentes tecnologías puede crear una variedad increíblemente compleja de tecnologías en una empresa.

Estamos comenzando a ver que los equipos de infraestructura se convierten en «equipos de desarrollo de productos», con el objetivo de crear automatización, herramientas e infraestructura para respaldar una pila de tecnología diversa y en rápida expansión. Esta es una tendencia importante de comprender que puede conducir a una serie de problemas, especialmente dificultades para consolidar en una sola tecnología de base de datos. Esto puede limitar el crecimiento de la empresa y del proyecto a largo plazo.

Una serie de blogs de cuatro partes de Matt Yonkovit, Director de Experiencia de Percona. Lea los otros blogs de Matt en esta serie: «Bases de datos y el tamaño del mercado», «La base de datos de código abierto más popular de 2020» y «¿Cuándo el código abierto no es realmente abierto?»

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario