¿Por qué los profesionales de DevOps deben preocuparse por las arquitecturas por aplicación?
En esa pregunta está implícita la conclusión de que debería hacerlo.
Desde hace décadas, hemos estado implementando los servicios de aplicação que comprenden gran parte del proceso de producción en plataformas compartidas. NetOps proporciona servicios de aplicação como equilibrio de carga, servicios de rendimiento de aplicação , WAF e identidad federada en una infraestructura compartida, a menudo en forma de un controlador de entrega de aplicação (ADC).
Pero el tiempo y la demanda, junto con las arquitecturas de aplicação emergentes como los microservicios, están forzando cambios en ese proceso . Estos cambios son buenos, tanto para NetOps como para DevOps, porque están avanzando hacia un modelo que se alinea más de cerca con los cronogramas de implementación y las prácticas operativas como la infraestructura como código.
Hay algunos servicios de aplicação que permanecen firmemente arraigados en la infraestructura compartida. Nombre de dominio. Defensa contra ataques DDoS volumétricos. Cortafuegos de red. Estos servicios son por naturaleza servicios corporativos . Es decir, están diseñados para proteger, defender y servir al negocio. ¿Qué pasa si estos servicios fallan? No hay productividad ni ganancias en toda la empresa.
Pero otros servicios de aplicação son altamente afines a la aplicação ; sus configuraciones, API y servicios a menudo están configurados específicamente para soportar una sola aplicação. No una única arquitectura, sino una única aplicação.
La responsabilidad de estos servicios se está desplazando cada vez más hacia las operaciones de aplicação (DevOps) y hacia la participación de los desarrolladores que entregan las aplicações. Y si bien un modelo compartido puede (y a menudo lo hace) todavía funcionar para proporcionar los servicios de entrega y seguridad de aplicação necesarios, un modelo por aplicación para muchos de ellos es deseable por varias razones.
En primer lugar, un modelo por aplicación resuelve de forma clara los conflictos en el cronograma de implementación . Las organizaciones empresariales a menudo se ven limitadas por conflictos de infraestructura compartida con respecto a la configuración y la implementación de los servicios de aplicação que respalda. Una infraestructura compartida significa recursos compartidos, lo que invariablemente aumenta la posibilidad de un conflicto de configuraciones. Al eliminar esa posibilidad, se puede mitigar la resistencia a implementaciones más frecuentes o fuera de lo previsto. Después de todo, si un servicio de aplicação está dedicado a mi aplicação y se ejecuta en su propia plataforma con sus propios recursos, el conflicto se resuelve fácilmente. Mi aplicación, mi riesgo.
En segundo lugar, un modelo por aplicación respalda los esfuerzos de automatización emergentes que incluyen la puesta en práctica de metodologías como infraestructura como código. Al dedicar recursos y plataforma a una sola aplicação, la configuración incluye solo esa aplicação. Se puede imponer la inmutabilidad y evitar el riesgo de entropía. De hecho, yo diría ( y lo hice recientemente ) que no se puede crear adecuadamente una infraestructura inmutable sin una arquitectura por aplicación. Este enfoque permite la inclusión en un proceso de implementación continua que se extiende más allá de la infraestructura de aplicaciones y llega hasta “la red”. Proporcionar esta capacidad significa trasladar la responsabilidad de la configuración y la gestión continua de NetOps a DevOps. La buena noticia es que esa mayor responsabilidad conlleva un mayor control, ya que DevOps se convierte en el “propietario” del servicio de aplicação y tiene la capacidad de actualizar, aplicar parches y volver a implementar según sus propios términos y cronogramas.
Por último, un modelo por aplicación es inmediatamente más portable. Sin estar atado a una plataforma compartida y depender casi exclusivamente de artefactos de implementación (configuraciones y plantillas), la mayor parte del proceso de producción puede migrar de una nube a otra, de local a local, con mucha menos fricción y esfuerzo. Esa libertad ofrece a las organizaciones la posibilidad de elegir la mejor nube y ubicación para la aplicação en cuestión sin verse limitadas por los costos asociados con la migración.
DevOps puede beneficiarse enormemente al fomentar la adopción de una arquitectura por aplicación para los servicios de aplicação , tanto locales como en la nube pública. Con NetOps bajo presión para proporcionar mayor control y visibilidad a otros dominios operativos, este sería un buen momento para tomar una pizza y una cerveza y conversar con sus homólogos de NetOps sobre la transición hacia una arquitectura por aplicación centrada en la aplicación y de última generación.