Al igual que la nube, SDN sufre de fatiga de definición
Al principio de la historia de la nube, no hace mucho tiempo, era común ver informes de crecimiento y adopción que promocionaban la penetración de mercado sin precedentes de la “nube” sin distinción entre sus modelos principales (es decir, IaaS, PaaS y SaaS, en caso de que lo haya olvidado). Eso hizo que pareciera que los tres modelos estaban experimentando un crecimiento increíble y que la nube, como algunos predijeron, erradicaría el centro de datos tal como lo conocíamos.
Avanzamos algunos años y hemos visto mejores análisis del mercado que indican que el asombroso ascenso de la nube se produjo principalmente en el lado SaaS del mundo, ya que las partes interesadas de las líneas de negocio (LOB) vieron beneficios en pasar de un modelo donde TI implementa software empaquetado para nosotros a un modelo SaaS que nos brinda lo que queremos hoy. Indiscutiblemente, el mayor crecimiento de la “nube” hasta la fecha ha sido el traslado de las operaciones comerciales desde las instalaciones locales a las aplicações “en la nube”.
Tenga en cuenta que “ para 2018, el 59 % de las cargas de trabajo totales en la nube serán cargas de trabajo de software como servicio (SaaS), frente al 41 % en 2013. Cisco predice que para 2018, el 28% de las cargas de trabajo totales en la nube serán cargas de trabajo de Infraestructura como Servicio (IaaS), cifra menor que el 44% en 2013. El 13% de las cargas de trabajo totales en la nube serán cargas de trabajo de Plataforma como Servicio (PaaS) en 2018, cifra menor que el 15% en 2013. El siguiente gráfico ofrece un análisis comparativo de las previsiones de IaaS, PaaS y SaaS de 2013 a 2018. ( http://softwarestrategiesblog.com/tag/idc-saas-forecasts/ )
Por eso, cuando le preguntas a una organización si está adoptando la “nube”, probablemente recibirás un sí. Eso no dice nada sobre qué tipo de nube están adoptando y, por lo tanto, hace que sea casi imposible predecir o comentar qué tipo de desafíos podrían enfrentar en función de su adopción. Después de todo, cada modelo de nube trae consigo sus propios desafíos, y aunque algunos son compartidos (la gestión de identidad puede ser un problema en los tres modelos), otros no lo son (la seguridad de las aplicação web es principalmente un desafío para las aplicaciones implementadas en IaaS, no en SaaS).
Así que, básicamente, el término “nube” carece de sentido sin algún tipo de calificativo.
Esto también es cierto hoy en día en el caso de SDN, donde hay una variedad de modelos en juego, cada uno con sus propios requisitos arquitectónicos únicos y, por lo tanto, desafíos.
Considere esta diatriba de mi colega, Nathan Pearce, sobre la inclusión de protocolos de superposición (VXLAN y NVGRE) en la definición de SDN: ¿Qué protocolo SDN es adecuado para usted ? Nathan sugiere correctamente que, si vamos a incluir protocolos de superposición en la definición de SDN, también debemos nombrar otros protocolos de encapsulación como SDN.
El problema, por supuesto, es que, al igual que la nube, SDN sufre por su amplia inclusión de múltiples modelos. Existe la definición tradicional (o clásica, si lo prefieres), basada en OpenFlow e inclusiva únicamente de la red sin estado (capas 2-4). Existe el modelo arquitectónico que se centra en la operacionalización de la red, abordando el aspecto de programabilidad de SDN desde la perspectiva de automatizar el aprovisionamiento y la gestión. A esto a menudo se le denomina de forma amplia “Gestión y orquestación de red” (MANO).
Luego está el modelo que es una especie de mezcla, que se basa en la programabilidad para construir una red automatizada en toda la pila; incluye las siete capas OSI pero se centra en la capacidad de la red para ajustar su enrutamiento y la aplicación de políticas basadas en el tráfico en tiempo real. Es más apropiado llamarlo así: “redes automatizadas”.
Cada uno de estos tres modelos conlleva sus propios desafíos (y beneficios también). Y no hay nada que impida a una organización combinar estos modelos para alcanzar sus objetivos (de manera muy similar a como el 82 % de las organizaciones están planeando una estrategia de múltiples nubes (RightScale, State of the Cloud 2015)). Pero el hecho es que si le preguntas a alguien si está adoptando o implementando SDN y responde "sí", en realidad no tienes idea de lo que está haciendo. ¿Es OpenFlow? ¿OpenStack? ¿AbiertoLuz diurna? ¿Escribimos algunos scripts para automatizar la red?
Las estadísticas actuales sobre la adopción de SDN no son muy alentadoras y ciertamente no se acercan a donde se encontraba la nube en la misma etapa de madurez del mercado.
Pero dada la disparidad de definiciones, es bastante plausible (y probable) que lo que realmente está ocurriendo no sea una falta de adopción o interés, sino más bien una falta de definición común.
Voy a respaldar esto con algunos datos que indican que las organizaciones pueden no decir que están haciendo SDN (o DevOps, por cierto, que también sufre de fatiga de definición), pero es probable que lo estén haciendo.
En los resultados compilados para nuestro más reciente informe Estado de la entrega de aplicação (2016, que estará disponible en, bueno, 2016), la cantidad de respuestas reales de "implementación de SDN" fue bastante desalentadora considerando la cantidad de años que SDN ha sido "lo que hay que hacer". Pero al analizar las respuestas sobre el uso de la automatización y los scripts, vemos que la historia es completamente distinta: El 67% de los encuestados utiliza al menos una herramienta o marco de automatización; más de la mitad utiliza dos o más.
Y por “herramienta” o “marco” incluyo Python, Juju, Chef, Puppet, OpenStack, VMware y Cisco.
El uso de dichos marcos y herramientas indica un mayor interés en las dos últimas definiciones de SDN (las que se centran en la automatización y la orquestación, en lugar de la definición clásica basada en OpenFlow).
Pero nosotros (aquellos de nosotros que armamos la encuesta) no preguntamos sobre cada uno de los modelos SDN; preguntamos sobre “SDN” en general. Esto deja la definición abierta a la interpretación, al igual que el término amplio “nube” dejó el resultado de las encuestas de adopción temprana abierto a la interpretación.
Necesitamos ser más juiciosos en cuanto a cómo utilizamos el término SDN y lo que significa. ¿Incluye protocolos de superposición? ¿No incluye protocolos de superposición? ¿Estamos hablando de automatización de redes o de automatización de redes? ¿O nos centramos en modelos de redes clásicos impulsados por OpenFlow?
La respuesta a esa pregunta finalmente proporcionará a todos una mejor comprensión de cómo se está (o no) adoptando SDN hoy en día y (con suerte) evitará que la cabeza de mis pobres colegas explote cuando alguien sugiera que los protocolos de superposición se deberían incluir como "SDN".