Informe de la encuesta de F5 sobre DevOps y NetOps: la automatización es clave para cerrar la brecha digital
Se habla mucho de la relación arquetípica entre DevOps y NetOps. Nos vemos constantemente bombardeados por una retórica interminable de «nosotros contra ellos» que enfrenta a unos con otros, lanzando aplicaciones y acusaciones de un lado a otro por encima del muro que los separa. Ante la creciente presión por entregar aplicaciones con mayor rapidez y frecuencia, este muro puede convertirse en la brecha digital que separe a los ganadores de la economía de las aplicaciones del resto.
Afortunadamente, esta brecha digital se está reduciendo gracias a la automatización y la orquestación de TI. Al encuestar por separado a ambos grupos y analizar su uso de la tecnología, la percepción que tienen el uno del otro y las aplicaciones que ofrecen, descubrimos que tanto los equipos de NetOps como los de DevOps desean colaborar para cerrar esta brecha digital. Esto supone una noticia cada vez mejor para las empresas que emprenden iniciativas de transformación digital que requieren una escala y una velocidad que solo la automatización y la orquestación pueden proporcionar de forma eficaz. También es una buena noticia para las organizaciones que tienen dificultades con entornos multinube que exigen una mayor atención por parte de un personal ya sobrecargado. Aliviar la presión sobre los entornos locales mediante la automatización puede liberar recursos para dedicarlos a proyectos relacionados con la nube.
884 profesionales de NetOps y DevOps respondieron a encuestas en línea realizadas durante el verano de 2017. Formulamos varias preguntas sobre su percepción de las aplicaciones en general y de sus homólogos de NetOps o DevOps, así como preguntas centradas en su percepción de la frecuencia y las tasas de éxito de las implementaciones.
Los resultados muestran que, aunque el muro que los separa sigue en pie, no es ni mucho menos tan alto ni tan opaco como sugieren el discurso dentro de las comunidades u otros informes del sector. Encontramos numerosos puntos en común entre organizaciones de todos los tamaños y sectores en cuanto a la importancia de automatizar el proceso de producción y al deseo de hacerlo, así como una confianza compartida en la seguridad, el rendimiento y la fiabilidad de las aplicaciones que ambos grupos se esfuerzan por desarrollar e implementar.
La automatización parece ser una fuerza unificadora para NetOps y DevOps. Al menos en principio, aunque no tanto en los detalles específicos de implementación.
Aunque DevOps y NetOps siguen discrepando sobre el grado de acceso al pipeline que debería ofrecerse mediante el autoservicio y la automatización, en general ambos grupos consideran que el otro va por buen camino. El 82 % de DevOps y el 76 % de NetOps coinciden en que el otro prioriza «las cosas adecuadas». Está claro que, a ambos lados de la brecha digital, hay puntos en común al menos en cuanto a objetivos y prioridades, aunque no siempre se reflejen en el organigrama.
Entre quienes discrepaban por parte de NetOps, la respuesta más habitual sobre aquello a lo que DevOps no da suficiente prioridad fue la seguridad. La fiabilidad también se mencionó con frecuencia como motivo de frustración con DevOps entre sus homólogos de NetOps.
Como era de esperar, una de las quejas más habituales de DevOps sobre las prioridades de NetOps se centraba en la automatización. O, más bien, en la falta de ella.
Esta diferencia de opinión probablemente sea la causa de nuestro siguiente hallazgo clave, que puso de manifiesto cómo la falta de acceso de los desarrolladores y los equipos de DevOps al canal de producción mediante la automatización y el autoservicio afecta a la adopción de la nube y de soluciones ajenas al departamento de TI.
La automatización influye en la adopción de la nube
Ahora sí pueden oírte. Durante mucho tiempo se ha creído que uno de los factores que impulsan la adopción de la nube —tanto entre los responsables de negocio como entre los de DevOps— es la falta de acceso de autoservicio al proceso de despliegue en producción, lo que da lugar a ciclos de despliegue prolongados. La noticia no tan buena es que nuestra encuesta confirma esta creencia: el 27 % de los profesionales de DevOps afirma que influye «mucho» en su decisión de recurrir a soluciones basadas en la nube, mientras que para el 38 % influye «algo». La buena noticia es que los profesionales de NetOps no son ajenos a este impacto. Más del 65 % afirma que las decisiones de DevOps de adoptar la nube influyen «algo» o «mucho» en su deseo de automatizar y ofrecer acceso de autoservicio al proceso de despliegue en producción.
Hallazgos clave
- Firme apoyo a la automatización. Existe un amplio consenso sobre la importancia de automatizar los procesos de entrega e implementación, con una valoración media de su relevancia de 4,0 por parte de DevOps y de 3,5 por parte de NetOps en una escala de 5 puntos. En general, los encuestados también afirmaron tener más confianza en la fiabilidad, el rendimiento y la seguridad de las aplicaciones cuando el proceso de producción está automatizado en más de un 50 %. Ambos grupos coincidieron también, por abrumadora mayoría, en que el otro estaba «dando prioridad a los aspectos adecuados».
- La automatización influye en la adopción de la nube y viceversa. A pesar de ese acuerdo, las diferencias de opinión entre ambos grupos son reales y tienen consecuencias. Una de ellas es la disparidad de criterios sobre el acceso al canal de producción, que consideramos que contribuye al auge de la multinube. En el caso de DevOps, el 65 % de los encuestados señaló que la falta de acceso al canal de producción influía en su decisión de buscar soluciones externas y en la nube. Por el contrario, casi la mitad de los profesionales de NetOps (44 %) afirma que la decisión de DevOps de migrar a la nube influye «en cierta medida» en su disposición a facilitar dicho acceso, mientras que otro 21 % admite que influye «mucho».
- Discrepancias en torno al acceso al proceso de producción. Las iniciativas de transformación digital centradas en ofrecer aplicaciones para mejorar la eficiencia interna y la interacción externa deben salvar la brecha entre el desarrollo y la producción. Observamos que la barrera entre ambos sigue existiendo y que hay opiniones diversas sobre qué grado de acceso al proceso de producción deberían tener los desarrolladores y los equipos de DevOps. El grupo más numeroso de encuestados de DevOps considera que más del 75 % del proceso de producción debería estar disponible mediante autoservicio y automatización. Los equipos de NetOps son menos permisivos, pero las diferencias no son tan grandes como la percepción popular nos haría creer.
- La frecuencia actual de despliegue es adecuada. Tanto los equipos de DevOps como los de NetOps coincidieron rotundamente en que la frecuencia actual de los despliegues era «suficientemente buena». En consonancia con la percepción actual de la desconexión entre ambos grupos, los profesionales de NetOps tienen el doble de probabilidades que sus homólogos de DevOps de considerar que una frecuencia de despliegue es «demasiado alta». Solo unos pocos (el 4 %) del ámbito de DevOps indicaron que creen que los lanzamientos pueden llegar a ser «demasiado frecuentes».
Firme apoyo a la automatización
Se acabó el juego de las culpas. A diferencia de lo que sugieren las historias habituales, que enfrentan a NetOps y DevOps en un interminable cruce de acusaciones tras los incidentes, encontramos pruebas de que ambos grupos tienen una visión mucho más positiva el uno del otro.
El recurso a la nube por parte de quienes se sienten frustrados por la falta de acceso al pipeline contribuye en gran medida al auge de la multinube y a los retos de seguridad y rendimiento asociados, como suelen señalar quienes se enfrentan a la «TI en la sombra» resultante. Aunque NetOps sigue esforzándose por ofrecer acceso mediante automatización y autoservicio con nubes privadas o sistemas similares a la nube, sigue existiendo una importante inversión en soluciones de nube externas que difícilmente puede pasarse por alto. Esto obliga a las organizaciones a gestionar, supervisar y proteger múltiples soluciones —y entornos— de nube, lo que aumenta la complejidad de operar en la economía digital.
La cuestión ahora no es «¿ofrecemos acceso de autoservicio al pipeline de producción?», sino «¿hasta qué punto lo exponemos?»
Discrepancias en torno al acceso al pipeline
¿Cuánto es suficiente? La cuestión de cuál es el nivel adecuado de acceso al pipeline para los desarrolladores y los equipos de DevOps mediante funciones de automatización y autoservicio puso de manifiesto algunas diferencias de opinión notables. Sin duda, DevOps quiere tener más acceso al pipeline de producción del que NetOps se siente cómodo concediéndole.
Aunque no preguntamos por los motivos de la reticencia de NetOps a conceder a DevOps un mayor acceso al pipeline, la respuesta podría estar en las competencias disponibles para hacerlo. En general, los encuestados de NetOps consideran que existe una brecha entre las competencias que necesitan para desempeñar su trabajo y la formación y los conocimientos que poseen actualmente.
De hecho, tanto los profesionales de NetOps como los de DevOps que se identificaban como «desarrolladores» eran más propensos a creer que sus puestos seguirían siendo relevantes dentro de cinco años si mantenían responsabilidades y competencias similares. Quienes menos confianza mostraban eran los que se identificaban como operadores de red, a ambos lados de la barrera.
El estado actual de la automatización del pipeline de producción en el ámbito de NetOps parece reflejar el impacto de esa brecha de competencias. No resultó sorprendente comprobar que está considerablemente por detrás de la automatización del pipeline de entrega de DevOps. Mientras que el 11 % de los profesionales de NetOps reconoce que el pipeline de producción no está automatizado, solo el 5 % de los profesionales de DevOps afirma lo mismo sobre el pipeline de entrega de aplicaciones.
Es importante destacar el estado de la automatización de los pipelines, dado que hemos observado una correlación positiva entre dicha automatización y la frecuencia de despliegues satisfactorios. El 86 % de los profesionales de NetOps que indicaron un mayor porcentaje de automatización de los pipelines (un 75 % o más) también señalaron una mayor frecuencia de despliegues muy satisfactorios (un 90 % o más).
Pero no es el único factor, ya que la frecuencia de los cambios en las aplicaciones también parece influir en la frecuencia de los despliegues satisfactorios.
La frecuencia de despliegue actual es adecuada
Estamos bien así, gracias. Quizá la mayor brecha cultural siga estando en la frecuencia de despliegue. Mientras que algunos equipos de DevOps llevan aplicaciones a producción a un ritmo vertiginoso (el 12 % implementa cambios en producción más de una vez al día), los equipos de NetOps parecen sentirse mucho más cómodos desplegando esos cambios a un ritmo más lento, pero constante.
En general, parece haber cierto consenso entre una pluralidad de los encuestados en torno a las frecuencias mensual y semanal. Como era de esperar, DevOps prefiere realizar entregas con más frecuencia que NetOps. En concreto, del 26 % de los profesionales de DevOps que desean realizar entregas con mayor frecuencia, el 28 % lo hace una vez a la semana y el 26 % ya lo hace más de una vez al día.
La percepción sobre si la velocidad con la que se implementan los cambios es adecuada varía de un grupo a otro. No obstante, cabe destacar que la mayoría de ambos grupos (el 70 % de DevOps y el 74 % de NetOps) calificó la frecuencia de los cambios como «suficientemente buena para nosotros».
Ahí terminan las similitudes. Mientras que apenas un 4 % de los profesionales de DevOps afirmó que su frecuencia actual era «demasiado alta», el porcentaje de profesionales de NetOps que describió la frecuencia de entrega como «demasiado alta» fue el doble. Más de uno de cada cuatro profesionales de DevOps (26 %) quiere acelerar el ritmo, mientras que menos de uno de cada cinco profesionales de NetOps (18 %) desea hacerlo.
Sin embargo, si dejamos de lado las preferencias y analizamos los resultados, se revela cuál podría ser la frecuencia de despliegue «ideal» para equilibrar la velocidad y las tasas de éxito. Entre el 65 % de los profesionales de NetOps y el 57 % de los de DevOps cuyos despliegues tienen éxito en más del 90 % de los casos, los cambios se pasan a producción «una vez a la semana».
Conclusión
La brecha digital que deben superar las aplicaciones para pasar de la entrega a la implementación sigue existiendo. Una parte considerable del proceso de implementación continúa siendo manual, lo que seguirá impulsando la migración de las aplicaciones a la nube. A su vez, la decisión de DevOps de recurrir a la nube hará que NetOps proporcione más opciones de autoservicio necesarias para acelerar el proceso.
La automatización es clave para cerrar esa brecha digital, ya que permite a NetOps y DevOps trabajar de forma más inteligente, no más ardua, y ampliar conjuntamente las operaciones para satisfacer las necesidades de la empresa.
Metodología
Los datos de este informe se recopilaron mediante dos encuestas independientes realizadas por Internet en julio de 2017. Ambas se diseñaron para investigar el uso de la automatización en el ciclo de vida de las aplicaciones, desde el desarrollo hasta la implementación, así como las percepciones de los dos principales grupos implicados. Se ofrecieron incentivos a los encuestados de ambos grupos para que participaran.
Anexo: extractos de la encuesta
A continuación se incluyen algunas respuestas adicionales a las preguntas de la encuesta, procedentes tanto de participantes de NetOps como de DevOps. Aunque no se trata de una lista exhaustiva, se presentan como una muestra del tipo de comentarios recibidos. Los nombres de los productos se han corregido para garantizar su exactitud; por lo demás, la intención es publicar los comentarios sin editar y tal como se recibieron.
NetOps
Si has respondido «No» a «¿Tu equipo de desarrollo prioriza adecuadamente las tareas?», ¿qué te gustaría que priorizara de otra manera?
- Estabilidad, calidad y visión. Con demasiada frecuencia, la gente se apresura para cumplir una fecha y la calidad es lo que más se resiente. Además, no mirar más allá de la tarea actual acaba generando muchísimo trabajo adicional y soluciones que distan de ser óptimas (se improvisan apaños que quizá funcionen, pero que no son óptimos ni ideales en absoluto).
- Necesitamos una mayor colaboración entre los equipos de desarrollo y de administración de sistemas. No estamos dejando atrás la administración manual con la suficiente rapidez.
- Me gustaría que los equipos de desarrollo prestaran más atención a la fiabilidad operativa, la coherencia de la arquitectura y la cooperación entre los distintos equipos de desarrollo
- Los desarrolladores de aplicaciones no tienen en cuenta la red ni la seguridad; el equipo de seguridad apenas está al tanto del desarrollo y el equipo de redes se entera de los cambios operativos una vez finalizado el desarrollo.
En un mundo ideal, ¿cómo mejoraría la interacción, la comunicación, la colaboración, etc. entre sus equipos de Desarrollo y Operaciones?
- Mejorar las métricas, la supervisión y la visibilidad para que ambas partes estén al tanto del rendimiento. Automatizar el flujo de trabajo para agilizar la prestación de servicios. Proporcionar la capacidad adecuada para evitar plazos de entrega prolongados.
- Sustitúyalos por personas más inteligentes
- Dejad de veros como obstáculos y permitid que todos los equipos contribuyan allí donde puedan aportar más valor. La automatización es fantástica, pero, sin cierta supervisión, se implementan soluciones que pueden funcionar, aunque a menudo existe una forma mejor y más eficiente de hacer las cosas.
- Una mayor difuminación de la línea que separa a los equipos de desarrollo y operaciones. Deberían considerarse «un solo equipo», con el objetivo común de entregar aplicaciones que puedan escalar y ofrecer un buen rendimiento en la infraestructura disponible con una sobrecarga mínima.
- La comunicación no sirve de nada si estás hablando con el equivalente intelectual de una piedra con corbata.
- Involucrar al equipo de F5 en una fase más temprana del proceso dentro del ciclo de desarrollo.
- Involucrar antes al equipo de Operaciones en el ciclo de desarrollo
- Código compartido y visibilidad de los pipelines. Cuantas más herramientas se puedan gestionar mediante código, mejor (por ejemplo, no podemos gestionar de forma razonable un F5 BIG-IP mediante código, y ese es un punto débil de nuestro proceso).
DevOps
Si has respondido «No» a «¿Tu equipo de Operaciones prioriza las cosas adecuadamente?», ¿qué te gustaría que priorizara de otra manera?
- Me gustaría que dieran prioridad a la creación automatizada de recursos en la nube, independientemente del proveedor. Una infraestructura que pueda desplegarse con solo pulsar un botón, algo totalmente factible y útil para los desarrolladores, el equipo de control de calidad y el de operaciones.
- Tienen que adaptarse a automatizar todo lo que tocan y dejar de temer perder su puesto de trabajo
- Demasiado trabajo manual, ninguna automatización y falta de comprensión del problema técnico fundamental. Hay que dar autonomía a los desarrolladores.
- Suelen resolver los problemas a golpe de talonario: más equipos (caros) y más personal para realizar tareas repetitivas, en lugar de automatizarlas.
En un mundo ideal, ¿cómo mejoraría la interacción, la comunicación, la colaboración, etc. entre sus equipos de Desarrollo y Operaciones?
- Me gustaría que el equipo de Operaciones proporcionara más herramientas que abstrajeran los detalles del entorno operativo
- Soy desarrollador y necesitamos desplegar y automatizar la infraestructura. El equipo de operaciones debe aprender sobre automatización y a utilizar algunas herramientas.
- Transformaría el equipo de operaciones para que se centrase más en prestar soporte a la infraestructura y automatizar su gestión. Esto permitiría a los desarrolladores utilizar la infraestructura más como un servicio, en lugar de depender del equipo de operaciones para realizar actualizaciones, gestionar servidores, etc. También integraría a miembros del equipo de operaciones en otros grupos para que actuasen como enlace y ayudasen a facilitar la gestión de las aplicaciones.
- Es necesario ampliar el equipo de Operaciones e implicarlo directamente en el desarrollo y las pruebas. Debe ser menos un equipo al que acudir para hacer solicitudes y más un socio integrado que trabaje en primera línea.