Às vezes, a padronização é vista como um ataque à inovação. Ser forçado a abandonar um bufê poliglota e adotar um cardápio mais limitado certamente parece sufocante. Talvez isso ocorra porque a padronização costuma ser associada a normas de conformidade regulatória com nomes que soam oficiais, como ISO 8076.905E, e que trazem consigo listas de verificação, auditores e comitês de supervisão.
A realidade é que existem pouquíssimos padrões (na verdade, nenhum de que eu consiga me lembrar) que determinem a escolha de linguagens, protocolos e frameworks pelas organizações empresariais. O que impulsiona a padronização nas empresas são considerações mais práticas, como a disponibilidade de profissionais qualificados, a sustentabilidade e o custo total de propriedade ao longo da vida útil — muitas vezes considerável — de softwares e sistemas.
Estudos demonstraram que a vida útil média dos softwares nos últimos vinte anos é de cerca de 6 a 8 anos. Curiosamente, a longevidade tende a aumentar em programas maiores, conforme medido pelo número de linhas de código (LOC). Sistemas e softwares com mais de um milhão de LOC parecem ter uma vida útil superior a uma década, durando de 12 a 14 anos. Embora você possa considerar isso irrelevante, é importante perceber que, no fim das contas, os sistemas de automação de rede são softwares e sistemas. Eles precisam dos mesmos cuidados, recursos e manutenção que os softwares produzidos pela sua organização de desenvolvimento. Se você pretende tratar seu pipeline de produção como código, precisa aceitar que uma porcentagem significativa desse pipeline automatizado vai ser, de fato, código.
Ao longo da vida útil desse software ou sistema, portanto, é certo que várias equipes de operadores e desenvolvedores serão responsáveis por atualizá-lo, mantê-lo e operá-lo, além de implantar alterações nele.
E é exatamente isso que está no cerne do movimento em prol da padronização — especialmente para as equipes de NetOps, à medida que se aventuram no desenvolvimento e na manutenção de sistemas para automatizar e orquestrar a implantação e a operação da infraestrutura de serviços de rede e de aplicações.
Silos são para fazendas
Se você (ou sua equipe) escolher Python enquanto outra equipe escolher PowerShell, estará efetivamente criando um silo operacional que impede o compartilhamento de competências. Considerando que o principal desafio enfrentado pelas equipes de NetOps, conforme relatado no Estado da Automação de Redes de 2018, foi a falta de competências (apontada por 49% dos entrevistados), seria insensato criar obstáculos adicionais com a adoção de várias linguagens e/ou conjuntos de ferramentas. Da mesma forma, não é uma boa ideia escolher linguagens e conjuntos de ferramentas para os quais não haja profissionais qualificados disponíveis na região. Se outras organizações e universidades próximas ensinam Python e você optar pelo PowerShell, será difícil encontrar pessoas com as competências necessárias para trabalhar nesse sistema.
É raro uma organização padronizar uma única linguagem, mas as organizações tendem a adotar apenas algumas. A equipe de NetOps deve se orientar pelos padrões de desenvolvimento e DevOps, pois isso ampliará ainda mais o conjunto de profissionais disponíveis.
O tempo para gerar valor é valioso
Muitas organizações de NetOps já se encontram em desvantagem quando se trata de atender às demandas de DevOps e dos negócios por operações contínuas. A infeliz realidade de NetOps e da automação de redes é que se trata de um ecossistema heterogêneo, com pouquíssimas integrações prontas para uso disponíveis. Na pesquisa State of Network Automation, constatamos que essa "falta de integração" foi o segundo desafio à automação mais citado, apontado por 47% dos profissionais de NetOps.
A padronização de conjuntos de ferramentas e, sempre que possível, da infraestrutura (como serviços de aplicações) oferece uma oportunidade de reduzir o esforço de integração em toda a organização. O que uma equipe desenvolve pode ser aproveitado por outras para reduzir o tempo de geração de valor de outros projetos de automação. A reutilização é um fator importante para acelerar a geração de valor. Isso fica evidente na preferência dos desenvolvedores por código aberto e no fato de que, atualmente, entre 80% e 90% das aplicações são compostas por componentes de terceiros ou de 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 redes por meio do aproveitamento das integrações existentes.
Estabeleça uma cultura de compartilhamento e reutilização entre os domínios operacionais para aproveitar os benefícios da padronização.
Impulsionando 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 softwares e sistemas entre diferentes áreas operacionais, você reúne um conjunto mais amplo de conhecimentos e experiências capaz de colaborar no desenvolvimento de novos requisitos e sistemas. Assim, você cria um grupo de talentos dentro da sua organização que pode contribuir com sugestões, ideias e a implementação de novos recursos e funcionalidades, sem o ciclo de integração que, por vezes, pode ser demorado.
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 capacitado se torna. Isso aumenta a produtividade, permitindo dedicar menos tempo a reinventar a roda e mais tempo a pensar em como se diferenciar e agregar valor com novos recursos.
A padronização é uma oportunidade
A padronização pode parecer limitante a princípio, principalmente se a sua linguagem ou o seu conjunto de ferramentas preferido for excluído das opções da equipe. No entanto, encarar a padronização como uma oportunidade de criar uma base sólida para sistemas e softwares de automação beneficia a empresa e oferece à equipe de NetOps novas oportunidades de agregar valor em toda a cadeia de ferramentas de implantação contínua.
Mas não padronize apenas por padronizar. Leve em consideração as competências existentes e a disponibilidade de profissionais qualificados na sua região. Consulte universidades e outras empresas para entender o cenário atual das competências e dos profissionais de automação e operações, garantindo que sua organização não seja a única a adotar determinada linguagem ou conjunto de ferramentas.
Para obter os melhores resultados a longo prazo, não trate a padronização como se costuma tratar a segurança, deixando-a para depois de já ter concluído uma implementação. Adote a padronização desde o início de suas iniciativas de automação para evitar o acúmulo de dívidas operacionais e arquitetônicas que podem sobrecarregar você e dificultar a padronização posteriormente.
Quando se trata de padronização — assim como de segurança —, quanto antes, melhor.
Sobre o autor
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 VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...