Control versus ejecución en la ruta de datos
En el pasado, los servicios de aplicaciones que entregaban aplicaciones formaban una ruta de datos directa y estrecha. Básicamente, todas las aplicaciones atravesaron el mismo conjunto de servicios en la misma red. Esta simplicidad arquitectónica hizo fácil combinar un único punto de control con un único punto de ejecución. Esto, a su vez, condujo al surgimiento del controlador de entrega de aplicação (ADC). A través de él, se puede moldear, dirigir, escalar y proteger el tráfico de las aplicaciones, todo en un solo lugar. Control y ejecución combinados para proporcionar a las operaciones un punto estratégico en la ruta de datos en el que se pueden aplicar y ejecutar todo tipo de políticas.
El auge de la nube y la adopción continua de contenedores han alterado esa ruta de datos. Ahora contamos con rutas de datos múltiples y a veces dinámicas a través de las cuales se entregan las aplicaciones. Un único punto estratégico de control y ejecución a menudo ya no es viable desde el punto de vista operativo ni arquitectónico.
Pero eso no significa que ya no sea posible contar con un punto de control unificado incluso cuando la ejecución se delega a un conjunto dispar de servicios de aplicaciones.
Es importante tener la menor cantidad posible de puntos de control a través de los cuales se puedan operar (implementar, configurar y administrar) los servicios de la aplicación en la ruta de datos . Fomentar el uso de múltiples puntos de control inevitablemente genera políticas conflictivas que causan problemas a los consumidores de aplicaciones. La solución de problemas se vuelve más compleja y requiere más tiempo, lo que genera la ira y la angustia de los usuarios. Lamentablemente, la proliferación de herramientas es una queja común entre quienes gestionan la incorporación de arquitecturas nativas de la nube a una cartera de aplicaciones ya diversa .
Sabemos por nuestra investigación sobre el estado de los servicios de aplicaciones de 2020 que las operaciones son las principales responsables del funcionamiento de los servicios de aplicaciones, pero no están solas. DevOps, NetOps y SecOps invierten en el funcionamiento de los servicios de aplicaciones tanto locales como en la nube pública.
Lo que a menudo los separa son las funciones específicas de los servicios de aplicaciones de los que son responsables.
DevOps es en gran parte responsable de la confiabilidad, el rendimiento y las políticas específicas de la aplicación. NetOps, por otro lado, y a propósito de su nombre, se centra más en los atributos de la red. Es NetOps el que a menudo mantiene los servicios de aplicaciones desde una perspectiva de infraestructura. SecOps, por supuesto, se ocupa de la seguridad en relación con la infraestructura y la aplicación.
Pero el hecho de que pueda haber una división de tareas no significa que deba haber herramientas separadas con las que practiquen sus artes. Hoy en día, existe amplia evidencia de que los procesos de CI/CD y de implementación continua se basan en conjuntos de herramientas dispares. Jenkins y los repositorios Git dominan el flujo de trabajo de CI/CD, mientras que Ansible y Python son las herramientas elegidas en el lado de la implementación continua. Gran parte de la decisión radica en adaptar el conjunto de herramientas a las formas de trabajo de los distintos integrantes que deben interactuar con las herramientas a diario.
Por lo tanto, si surgiera una herramienta única para mejorar la coherencia de las políticas, acelerar la resolución de problemas y eliminar la complejidad y los costos de la proliferación de herramientas, debe tener las interfaces adecuadas para garantizar que todos los componentes principales de los servicios de la aplicación en la ruta de datos puedan aprovechar el conjunto de herramientas para realizar sus respectivas tareas.
Esto es importante para la seguridad general y la confiabilidad de los propios servicios de la aplicación. Al mantener un punto de control unificado, las organizaciones pueden tener la seguridad de que los cambios se controlan y se comprenden. Si bien no es una implementación inmutable, implica varios pasos hacia esa práctica al centralizar el control en una sola herramienta.
Un ejemplo de dicha herramienta es NGINX Controller .
Notarás que, como se imaginó, una variedad de servicios de aplicaciones (análisis, administración de API, seguridad y malla de servicios) se pueden controlar de forma central, aunque la operación y la ejecución estén distribuidas.
En cualquier entorno, es importante reducir la cantidad de herramientas que pueden interactuar con los componentes de la ruta de datos (servicios de la aplicación) para mitigar posibles problemas de configuración incorrecta o configuraciones conflictivas. En un entorno moderno de múltiples nubes, es aún más crítico centralizar el control debido a la complejidad que genera el crecimiento, a menudo exponencial, de los servicios de aplicaciones que comprenden la ruta de datos.
Más atractivo para quienes poseen los presupuestos es la reducción de los gastos operativos asociados con la eliminación de actividades manuales repetitivas mediante la automatización.
Unificar el control en una única herramienta es una forma de lograrlo.