Assim como a nuvem, a SDN sofre com a fadiga de definição

No início da história da nuvem, o que não foi há muito tempo, era comum ver relatórios de crescimento e adoção alardeando a penetração de mercado incomparável da "nuvem", sem distinção entre seus modelos primários (IaaS, PaaS e SaaS, caso você tenha esquecido). Isso fez parecer que todos os três modelos estavam experimentando um crescimento incrível e que a nuvem iria, como alguns previram, erradicar o data center como o conhecíamos.

Avançando alguns anos, agora, vimos melhores análises de mercado que indicam que a incrível ascensão da nuvem ocorreu principalmente no lado SaaS do mundo, já que as partes interessadas da LOB (linha de negócios) viram benefícios em mudar de um modelo de TI que implementa software empacotado para nós para um modelo de SaaS que nos dá o que queremos hoje. Indiscutivelmente, o maior crescimento na “nuvem” tem sido, até o momento, a movimentação de operações comerciais de locais para aplicativos “na nuvem”.

Considere que “ até 2018, 59% do total de cargas de trabalho na nuvem serão cargas de trabalho de Software como Serviço (SaaS), ante 41% em 2013. A Cisco prevê que, até 2018, 28% do total de cargas de trabalho na nuvem serão cargas de trabalho de infraestrutura como serviço (IaaS), uma queda em relação aos 44% em 2013. 13% do total de cargas de trabalho na nuvem serão cargas de trabalho de plataforma como serviço (PaaS) em 2018, uma queda em relação aos 15% em 2013.  O gráfico a seguir fornece uma análise comparativa das previsões de IaaS, PaaS e SaaS de 2013 a 2018. ” ( http://softwarestrategiesblog.com/tag/idc-saas-forecasts/ )

Então, quando você geralmente pergunta a uma organização se ela está adotando a “nuvem”, é provável que você receba um sim. Isso não diz nada sobre que tipo de nuvem eles estão adotando e, portanto, torna quase impossível prever ou comentar sobre que tipo de desafios eles podem estar enfrentando com base na adoção. Afinal, cada modelo de nuvem traz consigo seus próprios desafios e, embora alguns sejam compartilhados (o gerenciamento de identidade pode ser um problema em todos os três modelos), alguns não são. A segurança de aplicativos da Web é um desafio principalmente para aplicativos implantados em IaaS, não em SaaS.

Então, basicamente, o termo “nuvem” não tem muito sentido sem algum tipo de qualificador.

Isso também é verdade hoje para a SDN, onde uma variedade de modelos está em jogo, cada um com seus próprios requisitos arquitetônicos exclusivos e, portanto, desafios.

Considere este discurso do meu colega, Nathan Pearce, sobre a inclusão de protocolos de sobreposição (VXLAN e NVGRE) na definição de SDN: Qual protocolo SDN é ideal para você . Nathan sugere corretamente que, se vamos incluir protocolos de sobreposição na definição de SDN, precisamos nomear outros protocolos de encapsulamento também como SDN.

O problema é, claro, que, assim como a nuvem, a SDN sofre com sua ampla inclusão de múltiplos modelos. Existe a definição tradicional (ou clássica, se preferir), baseada no OpenFlow e que inclui apenas a rede sem estado (camadas 2-4). Há o modelo arquitetônico que se concentra na operacionalização da rede; abordando o aspecto de programabilidade da SDN a partir da perspectiva de automatizar o provisionamento e o gerenciamento. Isso é frequentemente chamado amplamente de “Gerenciamento e orquestração de rede” (MANO)

Depois, há o modelo que é uma espécie de mistura, que depende da programabilidade para construir uma rede automatizada em toda a pilha; ele inclui todas as sete camadas OSI, mas se concentra na capacidade da rede de ajustar seu roteamento e aplicação de políticas com base no tráfego em tempo real.  Isso é mais propriamente chamado de “redes automatizadas”.

Cada um desses três modelos traz consigo seus próprios desafios (e benefícios também). E não há nada que impeça uma organização de combinar esses modelos para atingir seus objetivos (da mesma forma que 82% das organizações estão planejando uma estratégia de multi-nuvem (RightScale, State of the Cloud 2015)). Mas o fato é que se você perguntar a alguém se ele está adotando ou implementando SDN e ele disser "sim", você realmente não tem ideia do que ele está realmente fazendo. É OpenFlow? O que é OpenStack? Luz do dia aberta? Aberto-nós-escrevemos-alguns-scripts-para-automatizar-a-rede?

As estatísticas atuais sobre a adoção de SDN não são muito inspiradoras e certamente estão longe de onde a nuvem estava no mesmo estágio de maturidade de mercado.

Mas dada a disparidade de definições, é bastante plausível (e provável) que o que realmente está acontecendo não seja uma falta de adoção ou interesse, mas sim uma falta de definição comum.

Vou reforçar isso com alguns dados que dizem que as organizações podem não dizer que estão fazendo SDN (ou DevOps, nesse caso, que também sofre de fadiga de definição), mas provavelmente estão fazendo.

Nos resultados compilados para o nosso mais recente relatório State of Application Delivery (2016, que estará disponível em, bem, 2016), o número de respostas reais “fazendo SDN” foi bastante desanimador, considerando quantos anos SDN tem sido “a coisa a fazer”. Mas, analisando as respostas sobre o uso de automação e scripts, bem, isso conta uma história completamente diferente: 67% dos entrevistados estão usando pelo menos uma ferramenta ou estrutura de automação; mais da metade está usando duas ou mais.

E por “ferramenta” ou “framework” estou incluindo Python, Juju, Chef, Puppet, OpenStack, VMware e Cisco.

O uso de tais estruturas e ferramentas indica mais interesse nas duas últimas definições de SDN – aquelas com foco em automação e orquestração, em vez da definição clássica baseada em OpenFlow.

Mas nós (como aqueles que elaboraram a pesquisa) não perguntamos sobre cada um dos modelos SDN; perguntamos sobre “SDN” em geral. O que deixa a definição aberta à interpretação, assim como o termo abrangente “nuvem” deixou o resultado das pesquisas de adoção inicial aberto à interpretação.

Precisamos ser mais criteriosos em relação à forma como usamos o termo SDN e o que isso significa. Inclui protocolos de sobreposição? Não inclui protocolos de sobreposição? Estamos falando de automação de rede ou automação de redes? Ou estamos nos concentrando em modelos de rede clássicos baseados em OpenFlow?

A resposta a essa pergunta acabará por fornecer a todos uma melhor compreensão de como o SDN está (ou não) sendo adotado hoje e (espero) impedirá que a cabeça dos meus pobres colegas exploda quando alguém sugerir que os protocolos de sobreposição devem ser incluídos como "SDN".