Por mucho que las aplicaciones necesiten datos y los desarrolladores necesiten bases de datos, existe una especie de relación de amor-odio, es decir, las bases de datos suelen estar gestionadas y operadas por administradores de bases de datos (DBA) y otros miembros del equipo de operaciones (Ops como en DevOps), incluidos los administradores de sistemas (sysadmins) y otros.
Esa desconexión se une al hecho de que a los desarrolladores les gusta codificar, no les gusta lidiar con las compilaciones de datos, los lotes y las copias de seguridad que se producen a nivel de la base de datos todos los días.
¿Hay esperanza, o esta desarticulación siempre será así… y podría la era moderna de la IA y la automatización venir al rescate?
Para responder a esta pregunta, necesitamos dar un paso atrás y observar cómo llegan los desarrolladores de software a sus funciones en las organizaciones contemporáneas y considerar cómo es su visión del mundo en la actualidad.
El camino al desarrollador
Hablando con Dave Stokes en su calidad de evangelista tecnológico de la empresa de software y servicios de bases de datos de código abierto Percona, la historia empieza a aclararse. Explica que, normalmente, si alguien quiere convertirse en desarrollador de software, el enfoque tradicional es estudiar Informática en la universidad. Hoy en día existen, por supuesto, múltiples cursos de conversión y bootcamps de software que también ayudan a las personas a entrar en la industria.
Mira también
Pero aunque estos cursos acostumbran a la gente a trabajar con herramientas para ponerse en marcha rápidamente, no profundizan necesariamente en áreas como la teoría relacional (un modelo fundamental utilizado por las bases de datos para organizar los datos en tablas "relacionadas" compuestas por columnas y filas con identificadores únicos) y las propias bases de datos. Al no profundizar en la teoría, los desarrolladores no aprenden a gestionar estos servicios.
Mira también
Pero, según Stokes, el reto es aún mayor. El gurú tecnológico de Percona nos recuerda que hoy sabemos que con el paso a DevOps y a la Ingeniería de Fiabilidad del Sitio (SRE) los desarrolladores son ahora más responsables del soporte de las aplicaciones que han construido. Esto significa que los desarrolladores asumen una mayor responsabilidad en la gestión de la infraestructura, incluidas las bases de datos. También significa que hay menos DBA "fuera y fuera" de los que solía haber.
Mira también
La automatización potencia
Mira también
Mientras que el papel del DBA ha quedado subsumido en las tareas de SRE y DevOps, ¿Cómo pueden los desarrolladores sacar el máximo partido de sus aplicaciones y datos? La respuesta, por supuesto, es la automatización", afirma Stokes.
Mira también
¿Por qué no utilizar servicios que puedan encargarse de las tareas aburridas pero necesarias?
Para empezar, los desarrolladores pueden mejorar las tareas habituales en torno a sus bases de datos para tareas esenciales como las copias de seguridad y la gestión. Utilizando scripts y herramientas [de código de software], los desarrolladores pueden automatizar fácilmente estos procesos para no tener que ejecutarlos manualmente".
En la era de la nube y la proliferación de la informática basada en servicios que nos ha dado Todo como Servicio (también conocida como XaaS), los equipos de desarrolladores también pueden contemplar la opción de externalizar la gestión de su infraestructura de datos utilizando un proveedor de Base de Datos como Servicio (DBaaS) para que se encargue de muchas de estas tareas. Incluso pueden plantearse implementar su propio enfoque DBaaS si confían en el uso de Kubernetes (una tecnología de orquestación de "contenedores" en la nube de gran importancia y muy popular) si no quieren depender demasiado de un proveedor de servicios específico.
Basarse en la ingeniería de plataformas
"Para los desarrolladores que quieran seguir con el código abierto, los enfoques de ingeniería de plataformas también pueden ayudar", afirma Stokes, de Percona, haciéndose eco del verdadero zeitgeist de las metodologías modernas y aún emergentes que se cenatralizan en torno a la tecnología empresarial hoy en día.
“La ingeniería de plataformas toma el enfoque de autoservicio fácil para el desarrollador que ofrecen los proveedores de la nube y luego les ayuda a llevar eso a su propio entorno. Esto significa que tienen más control sobre cómo y dónde ejecutan su infraestructura, pero siguen ofreciendo esa experiencia del desarrollador que es tan importante para la productividad”.
Desde la perspectiva de la base de datos, esto significa automatizar los procesos por los que pasan los desarrolladores para solicitar, construir y acceder a una instancia de base de datos cuando la necesitan. Esto lanza más fácil llevar a cabo las fases de desarrollo y prueba y luego pasar a producción (ese punto en el que las aplicaciones se despliegan realmente), mientras siguen funcionando las bases de datos y otros elementos que elijan.
Epifanía de la liberación del desarrollador
"Otra área en la que los desarrolladores pueden buscar una ventaja en la automatización es en torno a cómo obtienen recomendaciones sobre la configuración del sistema de bases de datos.Si una unidad de equipo desarrollador-programador carece de experiencia en esta área (y muchos la tendrán), ¿cómo pueden saber cuándo utilizar 'ajustes por defecto' y entender cuándo necesitan implementar un cambio basado en las cargas de trabajo de la aplicación? En el caso de las bases de datos, buscar áreas en las que los desarrolladores puedan mejorar el rendimiento de las consultas se considera algo así como un arte oscuro. Pero estos sistemas producen datos por derecho propio. Con suficientes datos -y las comparaciones adecuadas- los equipos pueden buscar mejoras y obtener recomendaciones sobre dónde pueden lanzar cambios", aclara Stokes, de Percona, en una especie de revelación esclarecedora (y esperemos que liberadora).
Stokes afirma que incluso si un programador de software es relativamente novato en el mundo de las bases de datos, utilizar las experiencias de otras personas a través de recomendaciones automatizadas puede ser de gran ayuda. Esto puede ser muy útil en torno a áreas como la disponibilidad y la durabilidad para una aplicación, en las que, de otro modo, los desarrolladores tendrían que comprender con cierto detalle la agrupación y el rendimiento de las bases de datos. Más allá del rendimiento, pueden fijarse en otros requisitos de gestión de la base de datos, como la comprobación del control de acceso a las instancias o de las conexiones inseguras.
Lo correcto frente a lo correcto
"Una cosa a tener en cuenta es la diferencia entre automatizar las cosas correctas y automatizar las cosas de la manera correcta. La diferencia aquí no es simplemente aplicar la automatización para lanzar un enfoque existente, sino ver cómo los equipos pueden mejorar su enfoque en general. Comprender áreas como las consultas y auditar lo que el equipo de desarrollo quiere conseguir en una aplicación puede ayudar. Esto puede comenzar con un enfoque de los datos, pero las necesidades de la aplicación evolucionarán con el tiempo. Esto significa que siempre tiene que haber espacio para esa pregunta abierta: ¿debemos seguir con nuestro enfoque automatizado actual o debemos estudiar la posibilidad de actualizarlo o sustituirlo?", se pregunta Stokes.
Todo esto también importa desde el punto de vista de los costos.
Si un equipo de desarrolladores automatiza los servicios de base de datos en un entorno para realizar consultas de datos, es posible que tengan un conjunto de consultas que no sean muy eficientes para lo que la base de aplicaciones necesita en la actualidad. Esto significa que pueden acabar pagando más por la infraestructura de datos de lo que necesitan. Stokes, de Percona, compara este proceso con subir una colina en bicicleta en marchas cortas, es decir, que se realiza un esfuerzo adicional innecesario para completar el trayecto.
"Sólo porque se pueda trabajar y viajar [en marchas cortas] tan [masivamente] duro utilizando la automatización, no significa que se deba hacer", afirma. "Al igual que las aplicaciones nunca se quedan quietas, la forma en que cualquier equipo de desarrolladores aborda la automatización de las bases de datos también tendrá que cambiar inevitablemente en algún momento".
El consejo aquí es sencillo en muchos sentidos. Nuestros equipos de TI pueden hacer más con más automatización y aliviar las cargas que entorpecen el rápido despliegue de aplicaciones y servicios de datos que a menudo deben cambiar rápidamente (¿recuerda Covid-19?) y servir a nuestras dinámicas economías mundiales. Pero, un gran poder siempre conlleva una gran responsabilidad, por lo que analizar qué automatizamos, así como por qué y cómo lo hacemos, también es crucial.
La automatización está en todas partes y empieza bajo la superficie.
Automaticemos, pero colaboremos para mitigar mientras asimilamos, deliberamos cuidadosamente e integramos con vistas a facilitar y liberar.
