Antigamente, os carros tinham câmbio manual. Alguns o chamavam de "câmbio de alavanca" por causa do mecanismo usado para trocar as marchas. Naquela época, o câmbio automático era algo especial que muitas vezes precisava ser encomendado. Seu nome vem do fato de o carro trocar as marchas automaticamente para você. O que, para falar a verdade, é bem conveniente. Afinal, há muitas variáveis a considerar ao tentar trocar as marchas manualmente.
Hoje em dia, os câmbios automáticos são o padrão. O câmbio manual é um mistério para a maioria das pessoas. Tentei ensinar cada um dos meus três filhos mais velhos a dirigir um carro com câmbio manual. Se você está pensando em fazer o mesmo, não recomendo. Não se você quiser que o câmbio do seu carro continue funcionando.
Menciono essa mudança nas expectativas e nos padrões como um preâmbulo para uma discussão sobre operações — principalmente as relacionadas à infraestrutura de rede e de serviços de aplicações, embora isso também se aplique a outras áreas.

Expectativas Operacionais
A mudança é em direção à automação, sim, mas também representa uma mudança nas expectativas quanto ao conhecimento necessário para operar a infraestrutura.
Voltando à minha analogia com o câmbio, se você estiver dirigindo um carro com câmbio manual, terá muitas variáveis para administrar. É preciso coordenar a embreagem e o acelerador. Você precisa ouvir o motor e reconhecer o momento de trocar de marcha. Também precisa saber em que marcha está, para qual marcha vai mudar e como movimentar a alavanca para engatá-la.
Isso reflete os tipos de conhecimento necessários para implantar manualmente a infraestrutura de serviços de rede e de aplicativos. É preciso entender muito bem como a rede funciona para garantir que o tráfego vá de um lugar para outro.
A adoção da nuvem deu início à mudança das expectativas em relação a esse "padrão". Embora ainda seja necessário compreender alguns conceitos básicos de redes, não é preciso necessariamente entender como eles funcionam. Com a introdução dos contêineres, as expectativas se deslocaram ainda mais para a direita, com pouca ou nenhuma necessidade de sequer pensar em endereços IP.
Isso muda as expectativas operacionais. Estamos passando de uma economia de operações especializadas para uma economia de operações comoditizadas. Hoje, espera-se que os aspectos operacionais da implantação da infraestrutura de serviços de rede e de aplicações sejam acessíveis a um conjunto mais amplo de funções dentro da organização. Para chegar lá, é necessário simplificar.
Mais especificamente, operacional simplificação. Não basta disponibilizar serviços de rede e de aplicações por meio de opções de autoatendimento; eles precisam ser fáceis de usar por quem, bem, vai utilizá-los. Precisa ser ainda mais simples do que é hoje.
Isso pode significar sacrificar a capacidade de configuração em favor da facilidade de operação.
Configurabilidade versus operabilidade
Assim como ocorre com a nuvem e os contêineres, as abstrações criadas sobre a infraestrutura de rede e de serviços de aplicações também se estendem ao uso dessas abstrações. Com isso, refiro-me ao vocabulário. À terminologia. Ao modelo de dados. À configuração propriamente dita.
O que quero dizer com isso, para quem está lendo e não é da área de programação, é que cada estrutura tem uma série de atributos associados que compõem o "objeto". Um objeto de Servidor Virtual tem um endereço IP, um Pool de aplicações, eventos, um nome e muitas outras características. Algumas dessas características são, na verdade, objetos — ou listas de objetos. Percorrer essas estruturas pode ser complexo. Isso porque a configurabilidade é essencial para fazer ajustes finos na infraestrutura. É importante poder ajustar características muito específicas — como ativar ou desativar o algoritmo de Nagle ou alterar o tamanho da janela TCP — para otimizar o desempenho ou a capacidade.
Agora, em um modelo de operações comoditizado — que é para onde estamos caminhando —, a operabilidade é mais importante do que a configurabilidade. Menos opções, entrada em operação mais rápida.
Mas isso não significa simplesmente remover opções. Apenas eliminar a possibilidade de ajustar opções atende somente aos requisitos básicos de operabilidade; isso não atende às expectativas de uma experiência operacional simplificada. Ainda é necessário entender o modelo de objetos. O que é preciso é abstrair o modelo em algo mais simples. Por exemplo, reduzir um Servidor Virtual a um endereço IP, um nome e uma lista de instâncias de aplicações.
A comoditização exige padronização
Essa é uma tarefa significativa, pois não existe um modelo comum no qual a infraestrutura de serviços de aplicações se baseie. A forma como servidores virtuais, controle de entrada e políticas de segurança são representados varia de um produto para outro e de um serviço para outro.
As equipes de operações — seja na área de desenvolvimento ou de TI — precisam, na prática, compreender uma infinidade de modelos para implantar e operar os, em média, quatorze serviços de aplicações usados para disponibilizar e proteger aplicativos. Há muita variação, o que, no passado, levou à criação de inúmeras certificações necessárias para comprovar o conhecimento especializado exigido para gerenciar esses serviços.
A outra mudança operacional é se afastar dessa abordagem. Há uma expectativa de simplicidade, facilidade de uso e uniformidade entre as ofertas, como forma de reduzir a dívida técnica gerada por modelos operacionais específicos de cada dispositivo. É uma expectativa de padronização — não dos protocolos e do comportamento da rede, que já são padronizados no âmbito da infraestrutura de rede, mas da forma como representamos esses protocolos e comportamentos da rede.

Vemos isso se refletir em pesquisas sobre conteinerização, nas quais as habilidades necessárias são apontadas como um grande obstáculo à adoção por quase um em cada quatro entrevistados (24%), enquanto 33% afirmaram que elas representavam um obstáculo moderado. A infraestrutura — que certamente inclui contêineres e sistemas de orquestração de contêineres, dada sua prevalência nos ambientes de produção atuais — está sendo impulsionada pela falta de profissionais qualificados e pelo desejo de acelerar a transição para operações comoditizadas.
Esse desejo e essa necessidade ficam evidentes na adoção orgânica de arquivos de recursos do Kubernetes que buscam descrever esses serviços de infraestrutura. Esses recursos impõem a todas as equipes de operações o uso de um modelo (formato) de dados comum (comoditizado) para descrever a implantação e a configuração de um determinado serviço. Considerando que as operações de TI são hoje o principal fator de adoção de contêineres (35%) nas organizações (de acordo com a Pesquisa de Adoção de Contêineres de 2019 da Diamanti) — com quase o dobro da influência dos desenvolvedores (16%) e quatro vezes a das equipes integradas de DevOps (9%) —, é importante reconhecer essa mudança e avaliar cuidadosamente como a nova infraestrutura se encaixa (ou não) em um ambiente de operações comoditizadas.
Com ou sem iniciativas oficiais (de grupos de trabalho ou fundações), a comoditização levará à adoção de um padrão de fato nas operações. E esse padrão de fato será um que prioriza a operabilidade em detrimento da configurabilidade.
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...