¿La automatización de redes es realmente una cuestión de todo o nada?
La automatización de redes —la práctica de aplicar DevOps al proceso de producción— ya se utiliza en un porcentaje significativo de organizaciones. Aunque muy pocas la han adoptado plenamente, la mayoría (el 77 %, según nuestro último informe «Estado de la entrega de aplicaciones») está realizando pruebas piloto o utiliza parcialmente la automatización en producción.
Uno de los conceptos estrechamente vinculados a DevOps —y, por tanto, a menudo asociado a NetOps— es el de producto mínimo viable (MVP).
Forma parte de la metodología Agile y se utiliza para acelerar los ciclos de desarrollo y lanzar soluciones al mercado con mayor rapidez. Es algo que necesitamos desesperadamente en «la red». Quizá recuerdes la encuesta de Appian mencionada en un blog anterior que nos puso frente a un dato contundente: el 72 % de los encuestados no confiaba en que el departamento de TI pudiera escalar para satisfacer las necesidades de la empresa.
Vaya. A pesar del uso bastante generalizado de la automatización en TI, los desarrolladores y las partes interesadas del negocio siguen sin confiar en nuestra capacidad para sacar el trabajo adelante.
Así que adoptar herramientas, tecnologías y metodologías de DevOps para acelerar las cosas (mediante un escalado más inteligente) no es una idea tan descabellada. Pero antes de averiguar cómo aplicar el MVP a la red, tenemos que entender qué es. Para quienes no estén familiarizados con DevOps, Agile o el MVP, aquí tienen una definición sencilla de la Agile Alliance:
Un producto mínimo viable (MVP) es un concepto de Lean Startup que destaca la importancia 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 obtener la máxima cantidad de aprendizaje validado sobre los clientes con el mínimo esfuerzo. Este aprendizaje validado permite determinar si los clientes comprarán realmente el producto.
Una premisa fundamental de la idea de producto mínimo viable (MVP) es crear un producto real (que puede ser simplemente una página de destino o un servicio que parezca automatizado, pero que en realidad funcione de forma totalmente manual) para ofrecérselo a los clientes y observar cómo interactúan realmente con el producto o servicio. Ver lo que las personas hacen realmente con un producto es mucho más fiable que preguntarles qué harían.
Un equipo utiliza eficazmente el producto mínimo viable (MVP) como elemento central de una estrategia de experimentación. Parte de la hipótesis de que sus clientes tienen una necesidad y de que el producto en el que trabaja la satisface. A continuación, ofrece algo a esos clientes para comprobar si realmente utilizarán el producto para satisfacer dicha necesidad. A partir de la información obtenida en este experimento, el equipo continúa, modifica o cancela el desarrollo del producto.
Llegados a este punto del presente tratado, cabe señalar que muchos de los conceptos asociados a DevOps (y a sus tecnologías y metodologías relacionadas) no siempre se trasladan bien al aplicarlos a una iniciativa de NetOps. «Experimentación» no es un término que los ingenieros, arquitectos o directivos de TI suelan utilizar cuando hablan de realizar cambios en la red.
El radio de impacto, ya sabe. Es amplio y tiene un peso considerable. La mayoría de las organizaciones no toleran demasiado bien el riesgo operativo, y con razón. Las interrupciones cuestan dinero de verdad y, a veces, puestos de trabajo. La red no es precisamente un buen lugar para experimentar.
Pero eso no significa que no exista un despliegue mínimo viable (MVD) para NetOps.
Definición de un MVD para NetOps
Actualmente, el pipeline de producción se compone tanto de recursos compartidos, como switches, routers, DNS y enrutamiento multicloud (GSLB), como de servicios específicos para cada aplicación, como balanceadores de carga, WAF y control de acceso a las aplicaciones.
Curiosamente, si observamos la frecuencia de los cambios asociados a los recursos compartidos, veremos que es bastante reducida. Es decir, estos recursos cambian con poca frecuencia. Esto es positivo, ya que también tienen una baja tolerancia a las interrupciones. En cambio, los recursos específicos de cada aplicación cambian con mayor frecuencia y presentan una mayor tolerancia a las interrupciones.
Al fin y al cabo, esa es una de las ventajas de una arquitectura por aplicación: el aislamiento de la ruta de datos, que evita que otras aplicaciones se vean afectadas cuando algo sale mal.
A lo largo de esa ruta de datos se encuentran los dieciséis servicios de aplicaciones diferentes que, según nuestra investigación, utilizan de media las organizaciones para ofrecer y proteger sus aplicaciones. Algunos de ellos —como un cortafuegos de red y el DNS— son recursos compartidos. Otros no lo son o, al menos, no tienen por qué serlo. Puede que actualmente estén implementados en una plataforma compartida, pero podrían diseñarse con su propia ruta de datos si hubiera una buena razón para ello.
Que, por supuesto, es lo que voy a ofrecerte.
La buena razón es que puedes desarrollar eficazmente un MVD para una aplicación si adoptas una arquitectura por aplicación para aquellos servicios de aplicación que, de entrada, están estrechamente vinculados a ella.
Como indica nuestra definición de un MVP, el «producto» (en nuestro caso, el despliegue de una aplicación) no tiene por qué estar totalmente automatizado. Si partimos de la premisa de que los recursos de mayor riesgo y menor tolerancia deben seguir configurándose (y verificándose) manualmente, aun así avanzamos. Los cortafuegos y los servicios básicos como el DNS tienen una frecuencia de cambio muy baja, por lo que podemos suponer que los métodos manuales no afectarán de forma significativa a los plazos de despliegue. Esto es aún más cierto si automatizamos la mayor parte de los servicios de aplicación específicos de cada aplicación, ya que así liberamos tiempo para que los operadores y los ingenieros realicen los cambios manuales cuando sea necesario.
Suponiendo que la proporción entre los servicios básicos (compartidos) y los servicios de aplicación específicos de cada aplicación sea aproximadamente de uno a tres*, esto significa que una organización media tiene al menos cuatro recursos compartidos que gestionar manualmente y doce recursos específicos de cada aplicación que automatizar.
Si observamos la extensa lista de servicios de aplicaciones (actualmente hacemos un seguimiento de treinta servicios distintos) veremos que algunos de ellos son necesarios para ofrecer o proteger una aplicación (DDoS, WAF, equilibrio de carga para escalar, acceso a aplicaciones), mientras que otros son, por así decirlo, mejoras. Entre estos últimos se incluyen servicios de aplicaciones como las opciones de aceleración para mejorar el rendimiento o el inicio de sesión único (SSO) para aumentar la productividad.
Así pues, si nos planteáramos implementar un MVD, podríamos adoptar un enfoque ágil y centrarnos en aquellos servicios de aplicaciones que son esenciales para la entrega y la seguridad desde el primer día. Esto no significa que vayamos a ignorar las mejoras, sino que inicialmente nos centraremos en los servicios esenciales y automatizaremos estos primero. Podemos seguir gestionando manualmente los servicios que mejoran la productividad o el rendimiento, pero, para un MVD, queremos centrarnos en los servicios que repercuten en los beneficios.
Un enfoque MVD para la red ágil
Abordar la automatización con el objetivo de definir y entregar un MVD significa que avanzamos más rápido (somos más ágiles) y nos brinda la oportunidad de perfeccionarla y ampliarla de forma iterativa con cada sprint (medido en semanas, no en trimestres), hasta obtener un producto sólido y sostenible (un despliegue automatizado).
Adoptar una estrategia de automatización basada en un MVD exige comprometerse no solo con una arquitectura, sino también con un enfoque y una actitud centrados en las aplicaciones. Esto se debe a que este tipo de enfoque requiere comprender la aplicación y sus necesidades tanto desde una perspectiva operativa como empresarial. El MVD de una aplicación puede no coincidir con el de otra. Esta es una de las razones por las que la arquitectura específica para cada aplicación es un componente tan importante al pasar de una red fija y manual a un proceso ágil (automatizado).
Así pues, resulta que existe un despliegue mínimo viable para NetOps. Esto significa que puede adoptar un enfoque ágil para la automatización de redes, que será infinitamente más rápido (y seguro) si, como parte de sus iniciativas de redes ágiles, migra a una arquitectura específica para cada aplicación.
Automatiza (casi) todo lo relacionado con la red.
*Esto es totalmente una estimación a ojo basada en la lista, mi experiencia y mi (firme) opinión. Tus resultados y tu definición pueden variar.
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.