Conseguir que desarrolladores y sistemas de TI trabajen juntos

Alan Hale, director EMEA Servicios Middleware de Red Hat.

Hoy en día, los responsables de empresas quieren más innovación, y más rápido. Tienen claro que, para superar a su competencia y seguir creciendo, su organización tiene que llevar rápidamente nuevos productos y servicios, además de superar constantemente las expectativas de sus clientes.

Esto ejerce una fuerte presión sobre los encargados de desarrollar y entregar nuevas y mejores funcionalidades de software para el negocio. Las versiones cada vez más rápidas y los plazos cada vez más cortos se están convirtiendo en hechos cotidianos. Pero en su carrera acelerada para crear nuevas piezas de código, los equipos de TI a menudo se topan con un obstáculo, que surge en la frontera entre el desarrollo de aplicaciones y las operaciones de TI, donde tropiezan dos culturas muy diferentes.

Solución de conflictos

A un lado de la frontera está la cultura de los desarrolladores, donde la creatividad, la libertad de experimentar y la elección de las herramientas son primordiales. El desarrollador es más feliz usando técnicas ágiles para producir una corriente constante de versiones y actualizaciones de software, que conseguirán posicionar al negocio donde debe estar, en términos de innovación.

Al otro lado de la frontera están los operadores de sistemas de TI, donde la estabilidad y el control son lo que importa. La interrupción es el enemigo y frecuentes cambios de versión o de software son complejos de manejar. Los operadores de sistemas coinciden en que quieren que el negocio avance, pero no arriesgándose a una caída de los sistemas críticos.

Esta división cultural puede llevar a todo tipo de «focos de tensión» antes de que llegue a producción una pieza de software. Los desarrolladores se sienten frustrados si se ven obligados a esperar que sean aprovisionados nuevos entornos de desarrollo o que se aprueben nuevas aplicaciones. Los operadores de sistemas, por su parte, se desesperan cuando los desarrolladores se toman la justicia por su mano, creando sus propios entornos o lanzando código preliminar en entornos de prueba. Y cuando falla el código, debido a desajustes en las librerías o diferencias en las plataformas o redes, todo el mundo se enfada por lo que percibe que son fallos debidos a la otra parte y por el valioso tiempo que ahora se perderá para subsanarlos. Aún peor, el negocio se queda a la espera de la funcionalidad que necesita hasta la nueva versión. Por supuesto, si alguno de los errores se produce en producción o la integración fracasa con otros sistemas en live, no queremos ni imaginar las consecuencias.

Este tipo de conflictos son la razón el gran interés que existe actualmente por lo que se conoce como DevOps, un movimiento que anima a colaborar más a los desarrolladores de aplicaciones y a los operadores de sistemas de TI, para eliminar los cuellos de botella que retrasan los lanzamientos de nuevo software y para ayudar a la empresa a mantener el ritmo de la innovación, que le permita estar un paso por delante de sus competidores.

La nube es un puente

En Red Hat, creemos que la nube es el mejor lugar para fomentar el DevOps, proporcionando una forma de trabajo que puede beneficiar a todas las empresas, incluso a las más reacias al riesgo. Una plataforma-como-servicio (PaaS), ya sea alojada en un proveedor externo o dentro de la propia empresa, proporciona beneficios que hacen a las tecnologías cloud atractivas para entornos de producción, pero que también se aplican al desarrollo y distribución de software: menor coste, mayor velocidad de salida al mercado, escalabilidad a medida, administración centralizada, aprovisionamiento y despliegue estandarizados son sólo algunos ejemplos.

Más aún, una PaaS basada en cloud ofrece un lugar de colaboración único donde los partícipes de ambos lados de la segmentación DevOps trabajan en equipo, en estrecha colaboración, independientemente de su ubicación física, y con una mejor comprensión de cómo trabaja la otra parte. Las capacidades de automatización orientan a todo el personal sobre el proceso de desarrollo y despliegue de la aplicación, proporcionando a todos los involucrados informes periódicos de progreso y advirtiéndoles sobre los próximos pasos, preservando las funciones y responsabilidades de cada uno.

Los operadores de sistemas, por ejemplo, pueden crear plantillas en el entorno PaaS, lo que permite a los desarrolladores tener acceso instantáneo a entornos de desarrollo similares a los de producción. Los desarrolladores, mientras tanto, pueden acceder a capacidades de auto-servicio que les permite crear aplicaciones escalables, empleando los lenguajes y workflows que escojan, mejorando su productividad. El resultado es un uso más eficiente del tiempo y las habilidades de todo el equipo de TI y más oportunidades para innovar en el conjunto de la empresa.

La hoja de ruta DevOps

Hay que tener en cuenta que la mayoría de las organizaciones tienen importantes inversiones existentes en herramientas y procesos existentes. Para todas ellas, la migración a DevOps será y debe ser un camino incremental. Por ese motivo, en Red Hat Consulting, creemos que es vital trabajar con las organizaciones para crear una hoja de ruta que les ayude a obtener el máximo provecho de lo que tienen hoy, pero, con el tiempo, les permita incorporar nuevas tecnologías, como una nube híbrida, y nuevas ideas como desarrollo continuo.

Incluso aunque el desarrollo y la distribución continua de aplicaciones no sea el objetivo de la empresa, o la idea de automatizar el desarrollo de aplicaciones hasta la producción pueda ser recibida con horror, DevOps pueden adaptarse a los niveles de confort particulares de cualquier empresa y al mismo tiempo ayudar a aumentar la fiabilidad, reducir el riesgo y optimizando los recursos necesarios para poner en uso el nuevo software.

Los operadores de sistemas obtendrán el control que requieren sobre los entornos, el marco y la reutilización. Van a aprovechar los beneficios en cuanto a costes y eficiencia de los entornos virtualizados y cloud, además de acelerar los procesos de desarrollo y prueba. Con el tiempo, pueden optar por mecanismos de recargo, que hagan a las unidades de negocio responsables de los costes de los entornos y herramientas de desarrollo que consumen.

Los desarrolladores, por su parte, consiguen un acceso más rápido a nuevos entornos, más opciones de herramientas, y la aptitud de «fracasar rápido». Es decir, cuando prueban nuevas tecnologías, marcos o versiones, si una configuración no funciona, tienen la posibilidad de cambiarla rápidamente por otra. Además, consiguen más escalabilidad de los entornos y mejores controles de prueba y repetición. Por encima de todo, pueden destinar más tiempo a desarrollar y menos esperando para iniciar el siguiente proyecto.