En el pasado, los servicios de aplicaciones encargados de entregarlas conformaban una ruta de datos directa y bien definida. Básicamente, todas las aplicaciones atravesaban el mismo conjunto de servicios a través de la misma red. Esta simplicidad arquitectónica facilitaba la combinación de un único punto de control con un único punto de ejecución. Esto, a su vez, propició la aparición del controlador de entrega de aplicaciones (ADC). Gracias a él, el tráfico de las aplicaciones podía configurarse, dirigirse, escalarse y protegerse, todo desde un mismo lugar. La combinación del control y la ejecución proporcionaba a los equipos de operaciones un punto estratégico en la ruta de datos desde el que se podían aplicar y ejecutar todo tipo de políticas.
El auge de la nube y la adopción continuada de contenedores han alterado esa ruta de datos. Ahora disponemos de múltiples rutas de datos, en ocasiones dinámicas, a través de las cuales se entregan las aplicaciones. A menudo, ya no resulta viable, ni desde el punto de vista operativo ni arquitectónico, contar con un único punto estratégico de control y ejecución.
Pero eso no significa que deje de ser posible disponer de un punto unificado de control aunque la ejecución se delegue en un conjunto heterogéneo de servicios de aplicaciones.
Es importante disponer del menor número posible de puntos de control desde los que se puedan operar (desplegar, configurar y gestionar) los servicios de aplicaciones de la ruta de datos. Fomentar el uso de varios puntos de control genera inevitablemente políticas contradictorias que causan problemas a los usuarios de las aplicaciones. La resolución de incidencias se vuelve más compleja y requiere más tiempo, lo que provoca el enfado y la frustración de los usuarios. Por desgracia, la proliferación de herramientas es una queja habitual entre quienes gestionan la incorporación de arquitecturas nativas de la nube a una cartera de aplicaciones ya de por sí diversa.
Gracias a nuestro estudio «State of App Services 2020», sabemos que el equipo de operaciones es el principal responsable de gestionar los servicios de aplicaciones, pero no es el único. Los equipos de DevOps, NetOps y SecOps también participan en la gestión de los servicios de aplicaciones, tanto en las instalaciones como en la nube pública.
Lo que suele diferenciarlos son las funciones específicas de los servicios de aplicaciones de las que son responsables.
DevOps es responsable en gran medida de la fiabilidad, el rendimiento y las políticas específicas de las aplicaciones. NetOps, por su parte, y como su propio nombre indica, se centra más en los atributos de la red. NetOps suele encargarse del mantenimiento de los servicios de aplicaciones desde la perspectiva de la infraestructura. SecOps, por supuesto, se ocupa de la seguridad en lo que respecta a la infraestructura y la aplicación.
Pero el hecho de que pueda existir una división de responsabilidades no significa que deban utilizar herramientas distintas para desempeñar sus funciones. Hoy en día, existen numerosas pruebas de que los pipelines de CI/CD y de despliegue continuo se basan en conjuntos de herramientas diferentes. Jenkins y los repositorios de git predominan en el pipeline de CI/CD, mientras que Ansible y Python son las herramientas preferidas para el despliegue continuo. La decisión depende en gran medida de adaptar el conjunto de herramientas a las formas de trabajo de los distintos equipos que deben interactuar con ellas a diario.
Por tanto, si surgiera una única herramienta para mejorar la coherencia de las políticas, agilizar la resolución de problemas y eliminar la complejidad y el coste derivados de la proliferación de herramientas, esta debería contar con las interfaces adecuadas para garantizar que todos los principales actores implicados en los servicios de aplicaciones de la ruta de datos puedan aprovechar el conjunto de herramientas para desempeñar sus respectivas funciones.
Esto es importante para la seguridad y la fiabilidad generales de los propios servicios de aplicaciones. Al mantener un punto de control unificado, las organizaciones pueden tener la certeza de que los cambios se supervisan y se comprenden. Aunque no se trata de una implementación inmutable, la centralización del control en una única herramienta permite avanzar considerablemente hacia esa práctica.
Un ejemplo de este tipo de herramienta es NGINX Controller.
Como puede observar, tal y como se había previsto, diversos servicios de aplicaciones (análisis, gestión de API, seguridad y malla de servicios) pueden controlarse de forma centralizada, aunque su funcionamiento y ejecución estén distribuidos.
En cualquier entorno, es importante reducir el número de herramientas que pueden interactuar con los componentes de la ruta de datos (servicios de aplicaciones) para mitigar posibles problemas derivados de configuraciones incorrectas o incompatibles. En un entorno multinube moderno, es aún más importante centralizar el control debido a la complejidad que genera el crecimiento, a menudo exponencial, de los servicios de aplicaciones que conforman la ruta de datos.
Para quienes gestionan los presupuestos, resulta aún más atractiva la reducción de los gastos operativos que se consigue al automatizar y eliminar las tareas manuales repetitivas.
Unificar el control en una única herramienta es una forma de conseguirlo.
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.