Assim como a nuvem, a SDN sofre com o excesso de definições

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

No início da história da computação em nuvem, o que não faz tanto tempo assim, era comum ver relatórios de crescimento e adoção exaltando a penetração de mercado sem precedentes da “nuvem”, sem fazer distinção entre seus principais modelos (IaaS, PaaS e SaaS, caso você tenha se esquecido). Isso dava a impressão de que os três modelos estavam apresentando um crescimento extraordinário e de que a nuvem, como alguns previam, acabaria com o data center como o conhecíamos.

Avançando alguns anos, hoje temos análises de mercado mais detalhadas, que indicam que a impressionante ascensão da nuvem ocorreu principalmente no segmento de SaaS, à medida que as partes interessadas das LOBs (linhas de negócios) perceberam os benefícios de migrar de um modelo em que a TI implementa software pronto para elas para outro em que o SaaS oferece hoje o que elas desejam. Sem dúvida, até o momento, o maior crescimento da “nuvem” foi impulsionado pela migração das operações empresariais de ambientes locais para aplicações “na nuvem”.

Considere que “até 2018, 59% do total de cargas de trabalho na nuvem serão cargas 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 Infraestrutura como Serviço (IaaS), uma queda em relação aos 44% de 2013. As cargas de Plataforma como Serviço (PaaS) representarão 13% do total de cargas de trabalho na nuvem em 2018, ante 15% em 2013. O gráfico a seguir apresenta uma análise comparativa das previsões de IaaS, PaaS e SaaS para o período de 2013 a 2018.” (http://softwarestrategiesblog.com/tag/idc-saas-forecasts/)

Portanto, quando você pergunta de modo geral a uma organização se ela está adotando a “nuvem”, é provável que a resposta seja sim. Isso não revela nada sobre o tipo de nuvem que ela está adotando e, portanto, torna quase impossível prever ou comentar os tipos de desafios que ela pode estar enfrentando em decorrência dessa adoção. Afinal, cada modelo de nuvem traz seus próprios desafios e, embora alguns sejam comuns — o gerenciamento de identidades pode ser um problema nos três modelos —, outros não são — a segurança de aplicações web é um desafio principalmente para aplicações implantadas em IaaS, não em SaaS.

Então, basicamente, o termo “nuvem” não significa muita coisa sem algum tipo de qualificador.

Isso também se aplica atualmente às SDNs, nas quais diversos modelos estão em uso, cada um com seus próprios requisitos arquiteturais específicos e, consequentemente, seus próprios desafios.

Considere esta crítica 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 é o mais adequado para você. Nathan sugere, com razão, que, se vamos incluir protocolos de sobreposição na definição de SDN, também precisamos classificar outros protocolos de encapsulamento como SDN.

O problema, é claro, é que, assim como a computação em nuvem, a SDN sofre por abranger uma grande variedade de modelos. Há a definição tradicional (ou clássica, se preferir), baseada em OpenFlow e que inclui apenas a rede sem estado (camadas 2 a 4). Há também o modelo arquitetural, que se concentra em tornar a rede operacional, abordando o aspecto de programabilidade da SDN sob a perspectiva da automação do provisionamento e do gerenciamento. Isso costuma ser chamado, de forma abrangente, de “gerenciamento e orquestração de redes” (MANO).

Há também o modelo que é uma espécie de combinação, baseado em programabilidade para criar uma rede automatizada em toda a pilha. Ele abrange as sete camadas do modelo OSI, mas se concentra na capacidade da rede de ajustar o roteamento e a aplicação de políticas com base no tráfego em tempo real. Esse modelo é mais apropriadamente chamado de “redes automatizadas”.

Cada um desses três modelos traz seus próprios desafios (e benefícios também). E nada impede uma organização de combinar esses modelos para alcançar seus objetivos (assim como 82% das organizações planejam adotar uma estratégia multinuvem (RightScale, State of the Cloud 2015)). Mas o fato é que, se você perguntar a alguém se está adotando ou implementando SDN e a resposta for “sim”, você não terá a menor ideia do que essa pessoa realmente está fazendo. É OpenFlow? OpenStack? OpenDaylight? Open-nós-escrevemos-alguns-scripts-para-automatizar-a-rede?

As estatísticas atuais sobre a adoção de SDN não são muito animadoras e certamente estão longe do patamar em que a computação em nuvem se encontrava no mesmo estágio de maturidade do mercado.

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

Vou corroborar isso com alguns dados que indicam que as organizações talvez não digam que estão adotando SDN (ou DevOps, que também sofre com o desgaste causado pelo excesso de definições), mas provavelmente estão.

Nos resultados compilados para o nosso mais recente relatório State of Application Delivery (edição de 2016, que estará disponível, bem, em 2016), o número de respostas indicando que as organizações realmente estavam “adotando SDN” foi bastante desanimador, considerando há quantos anos a SDN é vista como “a tendência a seguir”. Mas, ao analisar mais a fundo as respostas sobre o uso de automação e scripts, bem, a história é completamente diferente: 67% dos entrevistados usam pelo menos uma ferramenta ou framework de automação; mais da metade usa dois ou mais.

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

O uso desses frameworks e ferramentas indica um interesse maior nas duas últimas definições de SDN — aquelas voltadas à automação e à orquestração, em vez da definição clássica baseada em OpenFlow.

Mas nós (isto é, aqueles de nós que elaboraram a pesquisa) não perguntamos sobre cada um dos modelos de SDN; perguntamos sobre “SDN” de modo geral. Isso deixa a definição aberta a interpretações, assim como o termo abrangente “nuvem” deixou os resultados das primeiras pesquisas sobre adoção abertos a interpretações.

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

A resposta a essa pergunta acabará proporcionando a todos uma compreensão melhor de como a SDN está (ou não) sendo adotada atualmente e (espera-se) evitará 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”.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie