Em um blog anterior, escrevi sobre os engenheiros de rede que tocavam um segundo violino (não importa que eu tenha mencionado as Filarmônicas de Nova York e Viena de Leonard Bernstein!) e, se o senhor verificar meu LinkedIn, isso me fez ser desprezado por alguns contatos (ainda somos amigos).
Seguiu-se um debate saudável, e foi admitido que os engenheiros de rede devem adotar os padrões de “NetOps” nesta era de Cloud-First em que nos encontramos.
Mas, para mim, o fato de tentarmos renomear uma disciplina de TI à medida que a aplicamos à rede (DevOps de alguma forma precisa se tornar NetOps) mostra que, na rede, ainda pensamos que somos diferentes.
Contesto categoricamente que a rede seja diferente e, portanto, quanto mais rápido adotarmos os modelos DevOps (em vez de NetOps), melhor será para nós.
O DevOps rege o ambiente de infraestrutura e aplicativos Cloud-First, portanto, a rede precisa seguir o exemplo. 
O que acontece com o NetOps é o seguinte: sempre que o assunto vem à tona, o foco é a programabilidade da rede com Python, a automação da configuração ou a definição de políticas.
Os termos técnicos dominam a discussão sobre NetOps.
A discussão sobre DevOps, por outro lado, concentra-se na transformação dos negócios, na cultura e na filosofia.
O NetOps está acontecendo, e isso é ótimo, mas o verdadeiro divisor de águas na rede seria elevar a discussão e adotar uma verdadeira filosofia de DevOps.
Para fazer isso, os profissionais de rede precisam liderar com intenção e cultura de negócios, em primeiro lugar, e não com ferramentas tecnológicas.
Vamos revisitar rapidamente a história da computação de aplicativos e como ela levou ao DevOps.
Então, como engenheiro de rede, o senhor terá que admitir, a contragosto, que há familiaridades impressionantes e que estamos espelhando exatamente a mesma trajetória, e certamente chegaremos ao mesmo resultado: DevOps.
No início, havia o ferro.
No mundo dos aplicativos, ele passou de mainframes para servidores.
O senhor tinha que cuidar com carinho de seus animais de estimação (também conhecidos como servidores): instalá-los, configurá-los, corrigir o sistema operacional e garantir que ele permanecesse compatível com o aplicativo ou os aplicativos executados nele, atualizar manualmente a CPU, a memória ou a unidade quando o desempenho começasse a diminuir.
Então veio a virtualização.
De repente, surgiu o “poder da abstração” (veja a lendária palestra de Barbara Liskov), e o senhor pôde passar mais tempo inovando no código e menos tempo cuidando dos problemas do servidor.
Essa separação possibilitou modelos as-a-Service, e agora vemos coisas como computação sem servidor, infraestrutura como código etc.
“Gado, não animais de estimação” é uma das frases de efeito quando se trata de uma infraestrutura de aplicativos que, entre contêineres e orquestração, tornou-se completamente abstraída.
Como desenvolvedor, o senhor simplesmente envia seu código para a orquestração e quer que ele seja implementado muito rapidamente e na escala necessária para que seus usuários tenham uma ótima experiência.
Mas o senhor não se importa com onde e como isso acontece, pois isso cabe à orquestração descobrir.
Junte as duas coisas: O DevOps cria uma cultura que impulsiona a inovação e os resultados comerciais.
Em redes, temos que admitir que ainda estamos cuidando de nossos animais de estimação: roteadores, switches e – sim, tenho que dizer – SD-WAN do tipo “faça você mesmo”.
Vamos dar uma olhada na história da WAN corporativa: quando entrei no setor, estávamos implantando infraestruturas ATM.
Depois vieram os roteadores IP, e isso foi divertido.
Depois, começamos a integrar todos os tipos de aplicativos no sistema operacional do roteador, como VoIP, funções de segurança e muito mais.
Esses “animais de estimação” passaram a ter uma manutenção muito alta e, ainda assim, tinham a expectativa de vida de um hamster.
A cada dois ou três anos, mais ou menos, o senhor parecia precisar de alguma atualização importante de hardware – CPUs maiores, interfaces mais rápidas, nova malha de switch.
O senhor pode dizer o que quiser.
Algumas pessoas do mundo da rede espiaram por cima da cerca com certa inveja do que o mundo dos aplicativos havia conseguido com a virtualização, e os visionários da SDN começaram a falar sobre abstrações de rede.
A virtualização de rede começou a acontecer.
A grande maioria das SD-WANs é construída como uma sobreposição virtual. Isso é ótimo porque essa sobreposição é bastante ágil, ao contrário da infraestrutura de rede física subjacente da qual depende para fornecer SLAs de nível comercial (escrevi sobre o dilema entre sobreposição e subposição aqui).
E, sim, existe o provisionamento zero touch.
Mas pergunte às pessoas que implementaram uma SD-WAN global do tipo “faça você mesmo” se foi tão fácil quanto distribuir código para um desenvolvedor de aplicativos.
Certamente não é(link do artigo da Network World)!
Há vários guias de design que têm várias centenas de páginas quando o senhor verifica a outra documentação à qual o guia de design se refere.
As políticas que o senhor precisa definir no Dia 0 são bastante complexas, e é melhor que as defina corretamente.
Ah, e o senhor ainda precisará de MPLS para os aplicativos essenciais aos negócios e, em muitos casos, terá que adquirir esses links em diferentes países e fazer o patch de tudo sozinho.
Voltando ao DevOps: ele se tornou possível graças aos modelos de fornecimento X-as-a-Service.
Que é exatamente o que a Aryaka faz para a rede.
Gosto de chamá-la de rede sem roteador, pegando emprestado o termo da computação sem servidor para fazer uma observação.
Esqueça a configuração e os ajustes constantes.
Nunca peça a um vendedor de roteador que lhe diga que há um hardware novo e muito melhor disponível e que há uma promoção especial.
Entregue resultados comerciais diretos, não se preocupe em definir políticas de rede complexas, nem em como fornecer SLAs entre limites administrativos, nem em ajustar constantemente sua rede para acompanhar as cargas de tráfego de IaaS e SaaS em constante mudança.
A Aryaka simplesmente resolve sua intenção de negócios: diga-nos onde estão seus sites, qual redundância precisa, quais são seus principais aplicativos, como deseja priorizá-los – e veja a rede que o senhor imaginou se materializar magicamente em 48 horas ou menos.
E não apenas isso, mas também ver sua rede como serviço se adaptar constantemente às necessidades comerciais em constante mudança.
A Aryaka processa e monitora constantemente os dados de sua rede Global Layer-2, bem como todos os links de última milha que se conectam à rede principal, para detectar macrotendências e oferecer aos clientes opções de otimização constantes.
É preciso uma grande mudança cultural, sim.
O DevOps é uma nova filosofia e, inevitavelmente, passará a dominar também as redes.
A Aryaka foi criada como uma WAN Cloud-First para trazer a cultura DevOps para a rede: uma nova maneira de conectar globalmente sua empresa global com uma WAN corporativa Cloud-First que oferece agilidade e resultados comerciais.
Mais de 800 empresas já se juntaram a nós.
Por que o senhor não se junta a nós para uma demonstração do nosso portfólio SmartServices?
