El problema del flujo de trabajo de los desarrolladores del que nadie habla
El desarrollo de software moderno nunca ha sido tan potente; sin embargo, los equipos siguen dedicando una cantidad sorprendente de tiempo a lidiar con sus herramientas. El reto no son las herramientas en sí mismas, sino la fricción que se produce entre ellas.
El desarrollo de software moderno nunca ha sido tan potente.
Un desarrollador que trabaja hoy desde su oficina en casa tiene acceso a más potencia de cálculo, más marcos de trabajo, más servicios en la nube, más bases de datos y más automatización de la que tenían a su disposición departamentos enteros de ingeniería hace veinte años. El ecosistema de herramientas se ha disparado, la inteligencia artificial se ha convertido en parte de los flujos de trabajo diarios y poner en marcha una infraestructura global ahora se mide en minutos en lugar de meses.
Sin embargo, a pesar de todo este progreso, muchos equipos de ingeniería siguen dedicando una cantidad sorprendente de tiempo a lidiar con sus herramientas.
No es que las herramientas sean malas. La mayoría son excelentes para resolver problemas concretos. El reto es que los flujos de trabajo de desarrollo modernos rara vez se centran en un único problema.
Un desarrollador que investiga un problema en producción puede empezar por revisar los registros de la aplicación en un servidor remoto. Eso le lleva a realizar una consulta en la base de datos. La consulta revela datos inesperados. A continuación, el desarrollador necesita inspeccionar la respuesta de una API, validar las cargas útiles, rastrear una llamada de servicio, revisar una migración, comparar esquemas entre entornos y, tal vez, implementar una corrección.
Cada tarea, por sí sola, es sencilla.
La fricción surge en las transiciones.
Una aplicación para SSH. Otra para bases de datos. Otra para pruebas de API. Otra para transferencias de archivos. Otra para túneles. Otra para la documentación. Otra para la visibilidad de la implementación.
Al final del día, los ingenieros han dedicado tanto tiempo a cambiar de una herramienta a otra como a resolver el problema real.
En el sector se habla a menudo de reducir la complejidad dentro de los sistemas. Sin embargo, se presta mucha menos atención a reducir la complejidad entre sistemas.
Esa distinción es importante.
El coste del cambio de contexto
El cambio de contexto se ha convertido en uno de los factores que más merman la productividad en la ingeniería de software y que, sin embargo, se subestiman.
El problema no es simplemente abrir varias aplicaciones. Cada herramienta introduce su propia interfaz, modelo de autenticación, convenciones de flujo de trabajo, terminología, atajos y supuestos operativos.
Un ingeniero que investiga un problema en una base de datos puede pasar de una consola en la nube a un cliente SSH, a un cliente de base de datos, luego a una plataforma de pruebas de API antes de volver finalmente a un IDE. Cada transición obliga al cerebro a recargar el contexto.
El coste se acumula con el tiempo.
Esto se hace especialmente patente durante la respuesta a incidentes, cuando los equipos están bajo presión y cada minuto cuenta. Un problema de producción rara vez se presenta claramente delimitado dentro de los límites de un único sistema. Lo más habitual es que abarque simultáneamente bases de datos, infraestructura, API, servicios de autenticación, capas de almacenamiento y entornos de implementación.
Por desgracia, el ecosistema de herramientas sigue tendiendo a tratar estos ámbitos como mundos separados.
Los desarrolladores no lo hacen.
La infraestructura, los datos y las API ya no son disciplinas separadas
Hubo un tiempo en el que los equipos de infraestructura gestionaban los servidores, los administradores de bases de datos se encargaban de las bases de datos y los desarrolladores se centraban principalmente en el código de las aplicaciones.
Esas fronteras han desaparecido en gran medida.
Hoy en día, a menudo se espera que el desarrollador comprenda la infraestructura en la nube, las redes, las bases de datos, los controles de seguridad, la automatización de la implementación, la orquestación de contenedores, la observabilidad y los flujos de trabajo asistidos por IA.
El auge de la ingeniería de plataformas y de DevOps aceleró esta convergencia.
Como resultado, los desarrolladores se mueven cada día cada vez más entre tres ámbitos operativos:
Infraestructura. Datos. Conectividad.
La infraestructura proporciona acceso a los entornos. Los datos ofrecen información sobre lo que está ocurriendo realmente. Las API conectan los servicios entre sí.
Cuando algo falla, los desarrolladores rara vez investigan solo una de estas áreas de forma aislada. Investigan las tres.
Un ejemplo del mundo real
Imagina que un cliente informa de que los pedidos fallan de forma intermitente en una plataforma de comercio electrónico.
El primer instinto puede ser inspeccionar los registros de la aplicación. Un ingeniero abre una sesión SSH con el servidor de producción y comienza a revisar la actividad del sistema.
No aparece nada evidente.
La atención se centra entonces en la base de datos. Al consultar la tabla de pedidos, se observan varias transacciones incompletas. Una investigación más exhaustiva revela que se están creando registros, pero que no se procesan por completo.
En este punto, el enfoque cambia de nuevo.
El desarrollador debe examinar la API responsable de enviar esos pedidos. Se reproducen las solicitudes. Se validan las respuestas. Se comprueban los encabezados. Se examinan los tokens de autenticación. Se generan y comparan cargas de prueba.
Finalmente, sale a la luz la causa raíz.
Un sutil cambio en el contrato de la API introdujo un caso límite inesperado que se propagó a través de la pila de la aplicación y, en última instancia, se manifestó en forma de registros incompletos en la base de datos.
Fíjate en algo importante. El problema nunca fue exclusivamente un problema de infraestructura. Nunca fue exclusivamente un problema de la base de datos. Nunca fue un problema exclusivamente de la API. Fue un problema de flujo de trabajo operativo. Y eso es algo cada vez más habitual.
El auge de las herramientas operativas
Es probable que la próxima generación de herramientas para desarrolladores se centre menos en capacidades aisladas y más en la continuidad operativa.
Los desarrolladores no necesitan necesariamente más herramientas. Necesitan menos interrupciones en el flujo de trabajo.
Aquí es donde las plataformas operativas cobran interés. En lugar de tratar las bases de datos, la infraestructura y las API como actividades independientes, las herramientas modernas pueden empezar a reconocer que estos sistemas son partes profundamente conectadas del mismo flujo de trabajo.
Esa filosofía es la base de Datara Studio.
DataraDB: comprender la capa de datos
DataraDB se creó a partir de una sencilla observación. Las aplicaciones modernas generan más datos que nunca, pero comprender esos datos sigue siendo, a menudo, sorprendentemente difícil.
Los desarrolladores trabajan habitualmente con PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Redis y MongoDB. Comparan esquemas, revisan migraciones, resuelven problemas de rendimiento, generan documentación y utilizan cada vez más la IA para acelerar el desarrollo de consultas.
DataraDB integra estos flujos de trabajo en un entorno moderno y de alto rendimiento que se centra en el trabajo práctico diario de ingeniería, en lugar de limitarse a actuar como un simple explorador de bases de datos.
El objetivo no es simplemente ejecutar consultas. El objetivo es comprender los sistemas. Porque cuando algo falla, la base de datos suele ser la primera en dar la pista.
DataraSSH: Acceso a la capa de infraestructura
Por supuesto, los datos rara vez existen de forma aislada. Las aplicaciones residen en servidores, contenedores, plataformas en la nube, máquinas virtuales y entornos periféricos.
Esto significa que los desarrolladores siguen necesitando un acceso fiable a la infraestructura. SSH sigue siendo una de las tecnologías más importantes de la informática moderna, ya que el acceso remoto seguro sigue siendo la base de los flujos de trabajo operativos en prácticamente todos los sectores.
DataraSSH se creó para modernizar esa experiencia. En lugar de tratar SSH como una utilidad independiente, DataraSSH está diseñado como un espacio de trabajo operativo práctico para desarrolladores y equipos de infraestructura que necesitan conexiones seguras, reenvío de puertos, transferencias de archivos, hosts de enlace y gestión de entornos sin complejidades innecesarias.
El acceso a la infraestructura debe ser sencillo. No debe resultar difícil de manejar.
DataraAPI: completando el flujo de trabajo
Próximamente llegará a la plataforma Datara Studio: DataraAPI.
Si DataraDB ayuda a los desarrolladores a comprender los datos y DataraSSH les ayuda a acceder a la infraestructura, DataraAPI está diseñada para ayudarles a comprender la conectividad.
Las aplicaciones modernas se comunican cada vez más a través de API. Estas impulsan integraciones, servicios internos, ecosistemas de socios, aplicaciones móviles, plataformas SaaS, sistemas de IA y flujos de trabajo de automatización.
Sin embargo, las pruebas, la validación, la documentación y la gestión del ciclo de vida de las API suelen permanecer desconectadas de los entornos y las bases de datos con los que interactúan.
DataraAPI tiene como objetivo acercar esos flujos de trabajo. Y es que los desarrolladores rara vez investigan las API sin acabar tocando la infraestructura o los datos. Y rara vez investigan la infraestructura o los datos sin acabar tocando las API.
La plataforma de flujos de trabajo operativos
Tomadas individualmente, DataraDB, DataraSSH y DataraAPI resuelven problemas conocidos. En conjunto, reflejan un cambio más amplio que se está produciendo en la ingeniería de software.
El sector está avanzando hacia flujos de trabajo operativos en lugar de hacia categorías de herramientas aisladas. Los desarrolladores ya no se limitan a escribir código. Navegan por sistemas interconectados que abarcan infraestructura, bases de datos, API, entornos en la nube, límites de seguridad y, cada vez más, flujos de trabajo asistidos por IA.
Las herramientas que triunfen en los próximos años serán probablemente aquellas que reconozcan estas realidades y reduzcan la fricción entre ellas. No porque los ingenieros necesiten más funciones, sino porque necesitan más continuidad.
Puede que el futuro de la productividad de los desarrolladores no consista en crear mejores clientes de bases de datos, mejores clientes SSH o mejores herramientas de API de forma aislada. Puede que consista en crear un mejor flujo de trabajo operativo que abarque los tres.