Planes de despliegue de servicios de aplicaciones condicionados por la estructura del equipo

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Los desarrolladores son realmente diferentes. Desde sus funciones y responsabilidades hasta su posición en la estructura organizativa, suelen ser el «grupo que no encaja». Ni siquiera se los puede incluir necesariamente bajo el término «TI», porque los equipos de desarrollo oscilan entre formar parte de TI y formar parte del negocio.

Aunque DevOps empieza a arraigar como cambio cultural, la mayoría de las organizaciones siguen estructurándose funcionalmente en lo que, no precisamente con cariño, se conoce como silos de TI. En nuestro estudio Estado de los servicios de aplicaciones 2019, descubrimos que casi la mitad de los encuestados (46 %) seguía organizándose en «equipos de una sola función», como «Redes», «Servidores», «Almacenamiento» y «Seguridad». Más de un tercio (37 %) trabajaba en equipos de operaciones combinados, más adecuados para adoptar y aplicar los principios y enfoques de DevOps a la entrega y el despliegue de aplicaciones. Solo el 15 % trabajaba en pequeños equipos multifuncionales organizados por unidades de negocio o productos de la empresa.

La estructura es importante porque, en parte, define los objetivos y las prioridades. Esto, a su vez, determina las métricas con las que se mide el éxito. Las organizaciones aisladas en silos implican métricas también aisladas. Así lo demuestra nuestra encuesta sobre NetOps y DevOps del verano pasado. Observamos diferencias significativas en la forma de evaluar a los equipos según su estructura. Por ejemplo, las métricas más habituales en todos los tipos de equipos y funciones fueron:

1. Disponibilidad de la red (60 %)
2. Disponibilidad de la aplicación (56 %)
3. Optimización de procesos (40 %)
4. Tiempo medio de resolución (39 %)

Pero, al desglosar estos datos y analizar las métricas según el tipo de equipo, observamos que, cuanto más colaborativa —es decir, más similar a DevOps— es la estructura de un equipo, más cambian las prioridades.

Ahora bien, ¿qué relación tienen las métricas con las que se evalúa su rendimiento con los servicios de aplicaciones? En realidad, mucha.

Si tu principal objetivo es el tiempo de actividad de la red, trabajarás para maximizarlo e implementarás servicios que contribuyan a ese objetivo. Lo mismo ocurre con el tiempo de actividad de las aplicaciones. Si esa es tu prioridad, te tomarás los servicios de disponibilidad mucho más en serio que quienes son evaluados en función de la frecuencia de despliegue.

En nuestro estudio, podemos observar el impacto de una base de encuestados compuesta en gran medida por «equipos con una única función» en los planes de implementación de servicios de aplicaciones. Esto resulta más evidente cuando clasificamos dichos servicios según lo que aportan a las aplicaciones: seguridad, rendimiento, identidad y acceso, disponibilidad y movilidad.

Estos resultados reflejan el impacto de las métricas de los equipos con una única función. A los desarrolladores les preocupa principalmente la disponibilidad —que a menudo incluye objetivos de rendimiento específicos— y tienen previsto implementar aquellos servicios de aplicaciones que favorezcan tanto la disponibilidad como el rendimiento. Del mismo modo, los equipos de operaciones de red se centran en los servicios de aplicaciones que garantizan la disponibilidad de la red mediante la optimización, el escalado y la protección de los protocolos de red de los que dependen las aplicaciones.

La estructura de los equipos es importante. No solo por la necesidad de fomentar una cultura más colaborativa, sino también por cómo influye en las decisiones, incluidas las tecnológicas. La diversidad de objetivos genera fricciones y frustración. Esta es una de las razones por las que vemos que servicios de aplicaciones como el balanceo de carga, tradicionalmente implementados y gestionados por NetOps, pasan a ser asumidos por DevOps e implementados como parte de la aplicación. Esto se debe a que, en las organizaciones con estructuras de equipos monofuncionales, la disponibilidad de las aplicaciones es una prioridad para los desarrolladores, pero no para NetOps.

Para aprovechar realmente las ventajas de DevOps, las estructuras de los equipos —y las métricas con las que se evalúan— deben orientarse hacia modelos más colaborativos y alejarse de los equipos tradicionales de función única.

Porque los silos deben estar en las granjas, no en TI.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie