¿Existe una implementación mínima viable para NetOps?
¿Es realmente todo o nada para la automatización de la red?
La automatización de la red (la práctica de DevOpsing en el flujo de producción) ya está en uso por un porcentaje significativo de organizaciones. Si bien muy pocos están completamente comprometidos, la mayoría (77 % según nuestro último informe State of Aplicação Delivery ) están probando o utilizando parcialmente la automatización en producción.
Uno de los conceptos estrechamente vinculados con DevOps (y por lo tanto a menudo vinculados con NetOps) es la noción de producto mínimo viable (MVP).
Es parte de la metodología Agile y se utiliza como una forma de acelerar los ciclos de desarrollo y llevar las soluciones al mercado más rápidamente. Eso es algo que necesitamos desesperadamente en “la red”. Quizás recuerdes la encuesta de Appian mencionada en un blog anterior que nos bombardeó con una investigación que decía que el 72 % de los encuestados no tenían confianza en que la TI pudiera escalar para satisfacer las necesidades del negocio.
Ay. A pesar del uso bastante extenso de la automatización en TI, los desarrolladores y las partes interesadas comerciales aún no confían en nuestra capacidad para lograrlo.
Por lo tanto, adoptar herramientas, tecnología y metodologías de DevOps para acelerar las cosas (mediante una escala más inteligente) no es una locura. Pero antes de que podamos entender cómo aplicar MVP a la red, tenemos que entender qué es. Entonces, para aquellos que no están familiarizados con DevOps, Agile o MVP, aquí hay una definición sencilla de Agile Alliance:
Un producto mínimo viable (MVP) es un concepto de Lean Startup que enfatiza el impacto del aprendizaje en el desarrollo de nuevos productos. Eric Ries, definió un MVP como aquella versión de un nuevo producto que permite a un equipo recolectar la máxima cantidad de aprendizaje validado sobre los clientes con el mínimo esfuerzo . Este aprendizaje validado se materializa en la información sobre si sus clientes realmente comprarán su producto.
Una premisa clave detrás de la idea de MVP es que usted produce un producto real (que puede no ser más que una página de destino o un servicio con apariencia de automatización, pero que es completamente manual detrás de escena) que puede ofrecer a los clientes y observar su comportamiento real con el producto o servicio. Ver lo que la gente realmente hace con respecto a un producto es mucho más confiable que preguntarles qué harían.
Un equipo utiliza eficazmente el MVP como pieza central de una estrategia de experimentación. Su hipótesis es que sus clientes tienen una necesidad y que el producto en el que está trabajando el equipo satisface esa necesidad. Luego, el equipo entrega algo a esos clientes para descubrir si, de hecho, utilizarán el producto para satisfacer esas necesidades. Basándose en la información obtenida de este experimento, el equipo continúa, cambia o cancela el trabajo en el producto.
Este es el punto de este tratado donde observo que muchos de los conceptos asociados con DevOps (y sus tecnologías y metodologías relacionadas) no siempre se traducen bien cuando se aplican a una iniciativa de NetOps. La experimentación no es un término que utilicen los ingenieros, arquitectos o ejecutivos de TI cuando hablan de realizar cambios en la red.
El radio de la explosión, ¿ves? Es grande y está al mando. La mayoría de las organizaciones no tienen una alta tolerancia al riesgo operacional, y con razón. Los cortes de suministro eléctrico cuestan mucho dinero y, a veces, puestos de trabajo. La red no es realmente un buen lugar para la experimentación.
Pero eso no significa que no exista una implementación mínima viable (MVD) para NetOps.
Definición de un MVD para NetOps
Hoy en día, el flujo de producción se compone de recursos compartidos, como conmutadores, enrutadores, DNS y enrutamiento de múltiples nubes (GSLB), así como de servicios de aplicação por aplicación, como balanceadores de carga, WAF y control de acceso a aplicação .
Curiosamente, si observamos la tasa de cambio asociada a los recursos compartidos, descubriremos que son bastante nominales. Es decir, tienen una tasa de cambio baja. Esto es bueno, porque también tienen poca tolerancia a las disrupciones. Pase a los recursos por aplicación y encontrará una mayor tasa de cambio con una mayor tolerancia a las interrupciones.
Después de todo, ese es uno de los beneficios de una arquitectura por aplicación: el aislamiento de la ruta de datos que protege a otras aplicaciones de interrupciones cuando algo sale mal.
A lo largo de esa ruta de datos se encuentran los dieciséis servicios de aplicação diferentes que, según nuestra investigación, utilizan las organizaciones para distribuir y proteger sus aplicações. Algunos de ellos, como un firewall de red y un DNS, son recursos compartidos . Otros no lo son, o al menos no necesitan serlo. Es posible que hoy estén implementados en una plataforma compartida, pero podrían diseñarse en su propia ruta de datos si hubiera una buena razón para hacerlo.
Que es, por supuesto, lo que voy a darte.
La buena razón es que se puede desarrollar eficazmente un MVD para una aplicação si se adopta una arquitectura por aplicación para aquellos servicios de aplicação que están estrechamente acoplados a la aplicación en primer lugar.
Como nos dice nuestra definición de MVP, el “producto” (en nuestro caso, la implementación de una aplicación) no necesita estar completamente automatizado. Si partimos de la premisa de que los recursos más riesgosos y menos tolerantes deben seguir configurándose (y verificando) manualmente, aún ganamos terreno. Los firewalls y servicios centrales como DNS tienen una tasa de cambio muy baja, por lo que podemos asumir que los métodos manuales no tendrán un impacto significativo en el cronograma de implementación. Esto es aún más cierto si automatizamos la mayor parte de los servicios de aplicação por aplicación, porque entonces liberamos tiempo para que los operadores e ingenieros realicen cambios manuales si es necesario.
Suponiendo que la relación entre servicios básicos (compartidos) y servicios de aplicação por aplicación es de aproximadamente uno a tres*, eso significa que nuestra organización promedio tiene al menos cuatro recursos compartidos para administrar manualmente y doce recursos por aplicación para automatizar.
Al observar la extensa lista de servicios de aplicação ( actualmente estamos rastreando treinta servicios distintos ), notaremos que algunos de ellos son necesarios para entregar o proteger una aplicación (DDoS, WAF, equilibrio de carga para escalar, acceso a la aplicación), mientras que otros son más bien, digamos, mejoras . Estos incluirían servicios de aplicação como opciones de aceleración para mejorar el rendimiento o inicio de sesión único (SSO) que mejora la productividad.
Entonces, si tuviéramos que considerar la implementación de un MVD, podríamos adoptar un enfoque ágil y centrarnos en aquellos servicios de aplicação que son críticos para la entrega y la seguridad desde el primer día. Esto no significa que ignoremos las mejoras, solo significa que inicialmente nos centraremos en las críticas y las automatizaremos primero. Todavía podemos gestionar manualmente aquellos servicios que mejoran la productividad o el rendimiento, pero para un MVD queremos centrarnos en los servicios que impactan en las ganancias.
Un enfoque MVD para la red ágil
Abordar la automatización con la intención de definir y entregar un MVD significa que nos movemos más rápido (somos más ágiles) y nos da la oportunidad de iterar en la automatización para mejorarla y expandirla con cada sprint (medido en semanas, no en trimestres) hasta que tengamos un producto sólido y sustentable (implementación automatizada).
Adoptar una estrategia de automatización basada en MVD requiere compromiso no solo con una arquitectura, sino también con un enfoque y una actitud centrados en las aplicações. Esto se debe a que este tipo de enfoque requiere una comprensión de la aplicação y sus necesidades tanto desde una perspectiva operativa como desde un punto de vista comercial. El MVD de una aplicación puede no coincidir con el MVD de otra. Esa es una de las razones por las que la arquitectura por aplicación es un componente tan crítico durante la transición de una red fija y manual a un flujo de trabajo ágil (automatizado).
Resulta que existe una implementación mínima viable para NetOps. Esto significa que puede adoptar un enfoque ágil para la automatización de la red, uno que será infinitamente más rápido (y más seguro) si realiza la transición a una arquitectura por aplicación como parte de sus iniciativas de red ágiles.
Automatizar (casi) todas las cosas de la red.
*Eso es totalmente un SWAG basado en la lista, mi experiencia y mi (fuerte) opinión. Su experiencia y definición pueden variar.