娇色导航

Puede que sus equipos DevOps estén desperdiciando la mitad de su tiempo en tareas que no aportan ningún valor al negocio. Según nuestra encuesta e informe sobre el estado de Java en 2025, el 62% de las organizaciones afirma que el código muerto obstaculiza la productividad de sus DevOps, mientras que el 33 % admite que sus equipos pierden más de la mitad de su tiempo persiguiendo falsas alertas de seguridad. Por otra parte, el 72% de las empresas paga por capacidad en la nube que nunca utilizan.

Además de una ineficiencia, se trata de un impuesto oculto a la innovación que acaba con la capacidad de competir de la empresa de una manera silenciosa. En mis más de 25 años trabajando con Java, desde JDK 1.0 en 1996 hasta hoy, he sido testigo de cómo estas ineficiencias crecientes se han convertido en el mayor obstáculo para la innovación de las empresas que utilizan Java. Y sabiendo que casi el 70% de las empresas indica que más de la mitad de sus aplicaciones se ejecutan en Java, en absoluto lo hemos de ver como un problema minoritario, sino como una crisis que se esconde a plena vista.

Los tres pilares de la deuda de DevOps

· Codificación excesiva: la creciente carga del acaparamiento digital

El código muerto, es decir, las partes del código base que nunca se ejecutan pero que siguen en producción, crea un torrente de problemas que van mucho más allá del desperdicio de almacenamiento. El impacto en la productividad no es más que una pista de un problema más profundo: este acaparamiento digital obliga a los desarrolladores a navegar por sistemas de una complejidad innecesaria.

Nuestra investigación revela que las organizaciones con altos niveles de código muerto reportan ciclos de desarrollo que son, en promedio, un 35% más largos que los de aquellas con bases de código optimizadas.

Lo cual se agrava con el tiempo a medida que las versiones de Java se vuelven obsoletas. Por ejemplo, el 10% de las organizaciones todavía ejecuta aplicaciones en Java 6, una versión que ya tiene sus 20 años, para la que Oracle dejó de proporcionar actualizaciones en diciembre de 2018.

· Falsos positivos de seguridad: la persecución sin fin

Más allá de la pérdida de tiempo de desarrollo, los falsos positivos de seguridad consumen una enorme cantidad de recursos de DevOps. Eso de “más vale prevenir que curar” en el análisis de seguridad ha dado lugar a una ristra cansina de alertas, de tal manera que un tercio de los equipos dedican la mayor parte de su tiempo a investigar problemas que resultan no ser amenazas.

Un problema que es especialmente grave en entornos Java, donde el 41% de las organizaciones se enfrenta a problemas críticos de seguridad a diario o casa semana. A pesar de haber tenido más de tres años para abordar Log4j, la mitad de las empresas encuestadas sigue experimentando vulnerabilidades de seguridad de Log4j en producción. Esto pone de relieve un reto mucho más amplio: distinguir entre vulnerabilidades teóricas y amenazas reales.

Nuestra investigación indica que aproximadamente el 70% de las alertas de seguridad en entornos Java se determina finalmente como falsos positivos o vulnerabilidades en rutas de código que nunca se ejecutan en producción. Es decir: la innovación se detiene de manera inevitable cuando los equipos de DevOps no son capaces de separar de manera eficiente las amenazas reales de las hipotéticas.

· Desperdicio en la nube: pagar por capacidad sin rendimiento

La dimensión financiera de la deuda de DevOps se manifiesta en la ineficiencia de los recursos en la nube. Más allá de la cifra destacada del desperdicio generalizado, hemos descubierto que muchas organizaciones sobredimensionan sus aplicaciones Java de una manera drástica debido a la incertidumbre sobre los requisitos de rendimiento y a los patrones de carga inconsistentes.

Para las organizaciones basadas en Java, es un problema especialmente significativo, ya que casi dos tercios afirma que más del 50% de sus costes de computación en la nube provienen de cargas de trabajo Java. Un análisis adicional muestra que bastaría con optimizar las configuraciones de Java Virtual Machine (JVM) para reducir los costes de la nube entre un 25% y un 30% para una empresa media.

Un desperdicio que funciona como una penalización financiera directa: está ocurriendo igual que con los intereses de una deuda financiera, pues se paga por una capacidad que no se usa como tal. En el panorama empresarial, estimamos que esto representa más de 10.000 millones de dólares en gasto anual en la nube.

Liberarse de la deuda de DevOps

A medida que las aplicaciones Java se modernizan, con casi la mitad de las organizaciones (49%) ejecutando ahora Java 17 o Java 21, esta transición crea una oportunidad perfecta para abordar estas ineficiencias subyacentes.

Automatización de la higiene del código

Por un lado, es preciso implementar herramientas automatizadas que identifiquen y eliminen de forma segura el código muerto, integradas directamente en su canalización CI/CD para evitar que se acumule nuevo. Del mismo modo que supervisamos continuamente las métricas de rendimiento de la JVM, es necesario aplicar el mismo rigor a la identificación de patrones de código no utilizados.

Las grandes organizaciones líderes ahora incorporan el análisis del uso en tiempo de ejecución para identificar las rutas de código que no se han ejecutado en producción durante largos periodos de tiempo. Un enfoque basado en datos que ha ayudado a algunas empresas a reducir sus bases de código hasta en un 40% sin ningún impacto funcional.

De ahí la necesidad de considerar la posibilidad de implementar políticas que exijan que el código obsoleto tenga fechas de caducidad. De esta manera, las soluciones temporales ya no se convierten en una deuda técnica permanente. En este sentido, las revisiones periódicas del código, centradas de manera específica en la identificación de los componentes no utilizados, pueden ayudar a mantener su base de código ágil y fácil de mantener.

Inteligencia de tiempo de ejecución para la seguridad

Los análisis de seguridad tradicionales generan demasiadas alertas con muy poco contexto. Por el contrario, los enfoques modernos incorporan inteligencia de tiempo de ejecución para priorizar las vulnerabilidades en función de los patrones de uso reales, en lugar de explotarlos de teórica.

Las organizaciones deben invertir en herramientas que distingan entre las rutas de código que se ejecutan realmente en producción y las que existen pero no se utilizan. Este enfoque de inteligencia de tiempo de ejecución transforma la seguridad, que pasa de la búsqueda teórica de vulnerabilidades a la gestión práctica de riesgos. Este proceder reduce drásticamente los falsos positivos y libera a los equipos para que se centren en la innovación.

Las que han adoptado este enfoque reportan una reducción de hasta el 80% en el volumen de alertas de seguridad, al tiempo que mejoran su postura de seguridad al centrar los recursos en vulnerabilidades que se pueden explotar de manera cierta.

Optimización de recursos

También es necesario adoptar herramientas y prácticas que optimicen la asignación de recursos en la nube mediante el autoescalado avanzado, JDK de alto rendimiento y prácticas de finops establecidas que alinean la tecnología con los objetivos empresariales.

Según nuestro informe, las organizaciones con visión de futuro ya están abordando esta cuestión: el 38% ha implementado nuevas normas internas para el uso de instancias en la nube, el 35% utiliza instancias y procesadores más eficientes, y el 24% ha adoptado JDK de alto rendimiento con el propósito de para mejorar el rendimiento y reducir los costes.

Las organizaciones con más éxito en el mercado implementan equipos de finops multifuncionales con representación de ingeniería, operaciones y finanzas para abordar de manera integral la optimización de los recursos. Estos equipos establecen métricas y procesos de gobernanza que equilibran la velocidad de la innovación con la rentabilidad.

La necesidad de innovar

El costo de la deuda de DevOps va mucho más allá de las horas de ingeniería desperdiciadas. Mientras los equipos dedican la mitad de su tiempo a gestionar falsos positivos y navegar por bases de código infladas, sus competidores que ya han abordado estos problemas pueden innovar el doble de rápido. Por eso, los mejores desarrolladores buscan entornos que se caracterizan por la creación de valor y no por gestionar problemas heredados. Cada hora dedicada a actividades que no añaden valor se traduce en funciones sin crear, necesidades de los clientes desatendidas y oportunidades de mercado perdidas.

Al igual que hemos visto a las organizaciones buscar alternativas a las implementaciones ineficientes de Java, preveo que veremos un movimiento similar para abordar la deuda de DevOps a medida que aumente la conciencia de sus costes. Quienes den el primer paso obtendrán una ventaja competitiva significativa.

La cuestión no es si tiene deuda de DevOps, sino si se empezará a pagar antes que los competidores. Hoy en día existen herramientas y prácticas para reducir estas ineficiencias. Quienes actúen ahora mejorarán su productividad en ingeniería y transformarán de verdad su capacidad de innovar en un mercado cada vez más competitivo.

Simon Ritter es director técnico adjunto de .