A padronização é boa para o NetOps

A padronização às vezes é vista como um ataque à inovação. Ser forçado a abandonar um bufê poliglota e adotar um menu mais limitado parece sufocante, com certeza. Isso pode ocorrer porque, muitas vezes, a padronização está associada a padrões de conformidade regulatória que têm nomes oficiais, como ISO 8076.905E, e trazem consigo listas de verificação, auditores e comitês de supervisão.

A realidade é que há muito poucos padrões (na verdade, nenhum que eu conheça) que regem a escolha de linguagens, protocolos e estruturas por organizações empresariais. O que impulsiona a padronização na empresa são considerações mais práticas, como disponibilidade de talentos, sustentabilidade e custo total de propriedade ao longo da vida útil (geralmente considerável) do software e dos sistemas.

Estudos mostram que a vida útil média do software nos últimos vinte anos é de cerca de 6 a 8 anos. Curiosamente, a longevidade tende a aumentar para programas maiores, medida por linhas de código (LOC). Sistemas e softwares com mais de um milhão de LOC parecem ter vida útil superior a uma década, durando de 12 a 14 anos. Embora você possa descartar isso como irrelevante, é importante perceber que, no final das contas, os sistemas de automação de rede são softwares e sistemas. Eles precisam do mesmo cuidado, alimentação e manutenção que o software que sai da sua organização de desenvolvimento. Se você vai tratar seu pipeline de produção como código, então você tem que aceitar que uma porcentagem significativa desse pipeline automatizado será código.

Ao longo da vida útil desse software ou sistema, então, é uma aposta certa que vários conjuntos de operadores e desenvolvedores serão responsáveis por atualizar, manter, operar e implantar mudanças nesse software ou sistema.

E é exatamente isso que está no cerne do impulso pela padronização - especialmente para NetOps, à medida que eles se lançam no desenvolvimento e manutenção de sistemas para automatizar e orquestrar a implantação e operação de infraestrutura de serviços de rede e aplicativos. 

Silos são para fazendas

Se você (ou sua equipe) escolher Python enquanto outra pessoa escolher PowerShell, você estará efetivamente construindo um silo operacional que impede o compartilhamento de habilidades. Considerando que o principal desafio enfrentado pela NetOps, conforme relatado no State of Network Automation 2018, foi a falta de habilidades (conforme relatado por 49%), pareceria tolice criar atrito adicional introduzindo várias linguagens e/ou conjuntos de ferramentas. Da mesma forma, é uma má ideia escolher idiomas e conjuntos de ferramentas para os quais você não tem nenhuma fonte local de talento. Se outras organizações e universidades próximas estiverem ensinando Python e você decidir usar o PowerShell, terá dificuldade em encontrar pessoas com as habilidades necessárias para trabalhar nesse sistema.

É raro que uma organização padronize em um único idioma, mas elas tendem a padronizar em apenas alguns. O NetOps deve seguir as orientações dos padrões de desenvolvimento e DevOps, pois isso expandirá ainda mais o conjunto de talentos.

O tempo para valorizar é valioso

Muitas organizações de NetOps já estão atrasadas quando se trata de satisfazer as demandas de DevOps e negócios para obter continuidade. A triste realidade do NetOps e da automação de rede é que se trata de um ecossistema heterogêneo com muito pouca integração pré-definida disponível. Descobrimos na pesquisa State of Network Automation que essa "falta de integração" foi o segundo desafio mais citado para a automação, com 47% dos NetOps concordando.

Padronizar conjuntos de ferramentas e infraestrutura sempre que possível (como serviços de aplicativos) oferece uma oportunidade de reduzir a carga de integração em toda a organização. O que uma equipe desenvolve, outras podem aproveitar para reduzir o tempo de valorização de outros projetos de automação. A reutilização é um fator significativo na melhoria do tempo de retorno do investimento. Vemos a reutilização na propensão dos desenvolvedores em relação ao código aberto e no fato de que 80-90% dos aplicativos hoje são compostos de componentes de terceiros/código aberto. Isso acelera o desenvolvimento e reduz o tempo de geração de valor. O mesmo princípio pode ser aplicado à automação de rede aproveitando as integrações existentes.

Estabeleça uma cultura de compartilhamento e reutilização em todos os domínios operacionais para colher os benefícios da padronização.

Estimulando a inovação

Em vez de impedir a inovação, como alguns acreditam inicialmente, a padronização pode ser um catalisador para a inovação. Ao padronizar e compartilhar software e sistemas entre domínios operacionais, você tem um conjunto mais robusto de mentes e experiências capazes de colaborar em novos requisitos e sistemas. Você está criando um grupo de talentos dentro da sua organização que pode fornecer informações, ideação e implementação de novos recursos e funcionalidades sem o ciclo de integração, às vezes longo.

A padronização também acelera a implementação graças à familiaridade. Quanto mais você trabalha com a mesma linguagem, bibliotecas e conjuntos de ferramentas, mais capaz você se torna. Isso significa maior produtividade, o que leva a menos tempo gasto na construção de rodas e mais tempo pensando em como diferenciar e agregar valor com novos recursos.

A padronização é uma oportunidade

A padronização pode parecer sufocante no início, principalmente se sua linguagem preferida ou conjunto de ferramentas for excluído da equipe. Mas adotar a padronização como uma oportunidade de construir uma base sólida para sistemas de automação e software beneficia os negócios e oferece à NetOps novas oportunidades de agregar valor a toda a cadeia de ferramentas de implantação contínua.

Mas não padronize apenas por padronizar. Leve em consideração os conjuntos de habilidades existentes e a disponibilidade de talentos locais. Pesquise universidades e outras empresas para entender o estado atual dos conjuntos de habilidades e talentos de automação e operações para garantir que você não seja a única organização adotando uma determinada linguagem ou conjunto de ferramentas.

Para obter os melhores resultados a longo prazo, não trate a padronização como segurança e deixe-a para depois de já ter concluído a implementação. Adote a padronização desde o início de seus esforços de automação para evitar ser atingido por dívidas operacionais e arquitetônicas que sobrecarregarão você e dificultarão a padronização posteriormente.

Com a padronização – assim como a segurança – quanto mais cedo melhor.