La metodología de desarrollo de software y aplicaciones ha cambiado porque el tiempo que necesitan las empresas para disponer de aplicaciones ha cambiado radicalmente: hoy en día se requieren tiempos de desarrollo muy cortos para poder disponer rápidamente de nuevos productos y servicios. No sólo eso, se requiere que las nuevas aplicaciones sean capaces de comunicarse de forma nativa entre sí (a través de la interfaz de programación de aplicaciones (Api)). Pero, ¿qué es la metodología DevOps y la gestión ágil?
“La era del diseño ‘intrincado’ ha terminado; ha llegado la era del ensamblaje flexible, en la que el rápido desarrollo de nuevas aplicaciones se asegura ‘componiendo’ los servicios existentes, escribiendo nuevo código sólo cuando es inevitable y absolutamente necesario”, explica Forrester. Mediante el enfoque DevOps, la aplicación evoluciona paso a paso: el equipo de desarrollo trabaja en sinergia, mientras unos reescriben los servicios que no funcionan, otros perfeccionan los que son óptimos para la aplicación en desarrollo. Está claro que esta forma de trabajar, para ser realmente eficaz y no generar complejidades organizativas con inevitables repercusiones en la calidad de la aplicación o incluso en los tiempos de lanzamiento, requiere la definición de enfoques y metodologías rigurosas, controladas y controlables (como DevOps y Agile), nuevas competencias y tecnologías específicas de apoyo.
La diferencia entre Big Design y DevOps y la metodología ágil
El paradigma de desarrollo de aplicaciones centrado en el “Big Design” (escribir código nativo para construir monolitos de aplicaciones) es hoy en día, en comparación con las metodologías de desarrollo de software Devops y Agile, un enfoque fallido por varias razones:
- generan aplicaciones complejas con interfaces “frágiles” e inflexibles que dificultan la integración e interoperabilidad de las soluciones con otros servicios de aplicación, una situación que ya no es aceptable en el actual escenario competitivo global en el que se mueven las empresas;
- El mantenimiento y la evolución son costosos y complejos, por las mismas razones que la dificultad de integración/interoperabilidad, además de la criticidad de la disponibilidad de habilidades;
- Las tecnologías “monolingües” están fuera de tiempo en un mundo políglota: el enfoque de Big Design ha conducido generalmente al desarrollo de aplicaciones basadas en lenguajes propios; las modernas interfaces basadas en REST han permitido que las aplicaciones escritas en diferentes idiomas interoperen, pero la inserción de capas de aplicación de este tipo sigue siendo muy compleja y lleva tiempo (años, según Forrester);
- La interdependencia se ha convertido en la norma, no en la excepción: el parque de aplicaciones de la empresa se compone ahora, por lo general, de varias capas de aplicaciones con soluciones heterogéneas, cada una de ellas estrechamente dependiente de la otra. Esto ha llevado a la formación de intrincadas redes de aplicaciones que hacen complejas las intervenciones evolutivas debido a la excesiva interdependencia entre un servicio y otro (a menudo sin ninguna claridad ni visibilidad de las interconexiones reales, con repercusiones “dramáticas” también en las pruebas de las aplicaciones);
- La atención a los aspectos de la infraestructura debe ser continua, no “puntual”: en el pasado, las arquitecturas subyacentes a los servicios de las aplicaciones se “ajustaban” simplemente para soportar su escalabilidad; hoy las aplicaciones deben evolucionar rápidamente y con ellas la infraestructura de apoyo.
Índice de temas
¿Qué es DevOps? ¿Por qué deben trabajar juntos Desarrollo y Operaciones?
Desarrollo por un lado y Operaciones por otro, DevOps es una metodología de desarrollo de software que explota la nueva lógica de compartir y colaborar pero también de un crowdsourcing más vertical. Esto es lo que significa DevOps, y es posible aportando nuevos niveles de integración entre los desarrolladores y el personal de operaciones para acelerar los tiempos de diseño, prueba y lanzamiento de soluciones de aplicaciones corporativas tanto en entornos tradicionales como en la nube. Todo ello garantizando la calidad y seguridad del software desarrollado.
De hecho, la complejidad es a menudo un reflejo del crecimiento descontrolado de las infraestructuras informáticas, una deuda que no se ha resuelto ni siquiera con la introducción de tecnologías como Soa, la virtualización y la computación en nube, que deberían, por el contrario, garantizar la simplificación de las TI. En una encuesta realizada por Gartner, las infraestructuras informáticas existentes (incluidas las arquitecturas de las aplicaciones) resultaron ser “muy complejas” en el 54% de los casos.
Analizando las “causas” de esta complejidad con un poco más de detalle, Gartner señala que los mayores problemas se encuentran en el ámbito de los procesos de TI, por un lado, y en la proliferación de herramientas tecnológicas, por otro. Situaciones que dificultan tanto la liberación como el mantenimiento de servicios It eficientes (y eficaces en términos empresariales).
Dado que uno de los servicios de TI más importantes en términos de negocio es el de las aplicaciones, Gartner ha querido investigar para entender mejor cuáles pueden ser las “disfunciones” dentro de la familia de TI, que luego se reflejan en la empresa. Una de las áreas más críticas es la relación entre el desarrollo de aplicaciones y las operaciones de TI. Hasta un 47% de los encuestados afirma que la relación entre estos diferentes equipos es “poco colaborativa”. La queja más común de las operaciones es que a menudo se les “deja fuera” de las decisiones de arquitectura de TI y de negocio, lo que da lugar a un menor control de los niveles de servicio (incluidos los costes).
Los principales “conflictos”, que son la causa de la relación “disfuncional” entre el desarrollo y las operaciones, provienen de las personas, que no están acostumbradas a un enfoque de colaboración, especialmente debido a la estructura “en silos” del centro de datos. Por ello, los mayores problemas son atribuibles a procesos poco comunes (43% de los encuestados) y a la falta de colaboración (41%). Curiosamente, sólo el 3% de los encuestados considera que la falta de intercambio de métricas es una “causa de conflicto”: “Pero esto es el resultado de la ignorancia”, escribe Gartner, “que amplía el problema del ‘bloqueo’ y la falta de colaboración”.
Por el contrario, la importancia de DevOps radica en saber superar esta brecha cultural.
Las piedras angulares de la metodología DevOps: las 4 recomendaciones de Gartner
La evolución de las tecnologías ha generado un nuevo “estilo” de desarrollo que ha decretado el fin del Diseño de Aplicaciones en favor del modelo más dinámico de Composición de Aplicaciones. Una vez definido, en términos generales, lo que es DevOps, profundicemos ahora en el significado de este nuevo paradigma que pretende reducir las interdependencias de las aplicaciones a través de un acoplamiento “flojo”, es decir, explotando las arquitecturas orientadas a servicios (Soa) y las últimas Api Rest para desarrollar servicios de aplicaciones independientes que puedan ser reutilizados en contextos no planificados (es decir, como base para diferentes aplicaciones también). Hoy en día, los enfoques Agile y DevOps dan respuesta a este paradigma en términos de metodología, opciones tecnológicas y habilidades.
Gartner habla de una “filosofía” DevOps más que de una metodología, pero no deja de proponer algunas pautas útiles para guiar un camino adecuado:
- Comprender si el enfoque DevOps puede mejorar la gestión de servicios de It mediante el análisis del rendimiento de los procesos existentes y la identificación de posibles áreas de mejora en términos de agilidad. Esto implica una estrecha colaboración desde el principio entre el desarrollo y las operaciones, que deben analizar el rendimiento conjuntamente, aunque desde su propia perspectiva.
- Identificar los procesos específicos, aquellos en los que la simplificación infraestructural es más inmediata y en los que la agilidad es más fácilmente alcanzable, para poder lanzar proyectos piloto exitosos y útiles para “ganar experiencia”.
- Se necesitan mecanismos que ayuden y faciliten el flujo de información entre las distintas organizaciones (desarrollo y operaciones) implicadas. En este caso, las herramientas tecnológicas de planificación y gestión de la información social acuden al rescate, introduciendo funciones de colaboración y compartición para agilizar los procesos mediante el intercambio y la puesta en común de información.
- Definir métricas comunes compartidas (tanto técnicas como de negocio) entre desarrollo y operaciones que permitan a las dos partes trabajar hacia un mismo objetivo (normalmente, los equipos de desarrollo siguen métricas inherentes al código de desarrollo de la aplicación para verificar y probar la funcionalidad de la solución, mientras que los de operaciones utilizan métricas diferentes para probar la calidad, la seguridad, etc.). Esto garantiza una visión holística del proceso de desarrollo y acelera el lanzamiento del servicio It.
Cómo acelerar el nuevo “estilo” de desarrollo de aplicaciones: los 3 puntos de Forrester
Algunos procesos, en particular los de gestión del cambio, la liberación y la configuración, son elementos fundamentales para acelerar el nuevo “estilo” de desarrollo de aplicaciones. Así que aquí está la forma de proceder:
- el primer paso es pensar en términos de automatización para que las intervenciones sean lo más “ágiles” posible y acelerar las distintas etapas del ciclo de desarrollo;
- Cuando este ciclo se acerca al paradigma de la Composición de Aplicaciones, es esencial que estos procesos se gobiernen de forma inequívoca para tener siempre bajo control los posibles impactos y correlaciones que una intervención de configuración, por ejemplo, genera en términos de gestión de cambios y liberaciones (y viceversa).
Las aplicaciones desarrolladas como “redes de servicios” son más sencillas y menos arriesgadas porque las versiones son más frecuentes (con mejoras funcionales y de contenido) y se utiliza poco código nuevo y no probado. Si bien las liberaciones y la gestión de cambios (sobre todo si se apoyan en metodologías Agile y DevOps y en la automatización de procesos) son más dinámicas y fáciles de gestionar, no hay que olvidar que la complejidad no desaparece, simplemente recae (y crece) en otros pasos del ciclo de vida de la aplicación. Estos son los consejos de Forrester para hacer frente a esta situación.
- La coordinación de las actualizaciones y lanzamientos de aplicaciones “compuestas” requiere nuevas técnicas y tecnologías: resulta esencial hacer un seguimiento de toda la funcionalidad y usabilidad de la aplicación para que los cambios y actualizaciones sólo se realicen cuando los servicios subyacentes de apoyo y relacionados estén realmente listos;
- Se necesitan sistemas de descubrimiento de APIs y de gestión de dependencias: incluso antes de aspirar a la “reutilización”, los desarrolladores necesitan saber lo que está disponible; por eso es esencial contar con un sistema de descubrimiento y gestión de APIs (un ecosistema cada vez más complejo). Según los analistas de Forrester, las herramientas de búsqueda de APIs estarán basadas en la nube y serán guiadas en su evolución por comunidades globales de desarrolladores, incluyendo el código abierto;
- la complejidad se traslada al nivel de la gestión del servicio: si bien es cierto que se simplifica la escritura de código y se acelera el proceso de liberación de la aplicación, es innegable que la liberación continua de “piezas” del servicio de la aplicación hace más crítica la gestión del servicio de la aplicación en su conjunto. Una actividad que, según Forrester, tendrá que apoyarse en nuevas herramientas tecnológicas, cada vez más disponibles a través de modelos de nube y de código abierto.
