O mito do painel único

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

Desde que me entendo por gente — e isso já faz muito tempo —, o canto da sereia de um painel único por meio do qual seria possível visualizar e operar a infraestrutura tem seduzido a área de TI. Assim como o Santo Graal, ele nunca foi encontrado, e muitos profissionais de TI passaram a duvidar de sua existência.

A transformação digital deu o golpe final nessa estrutura mítica de gerenciamento e, em seu lugar, deu origem a uma nova: um plano único de controle.

A boa notícia é que, ao contrário do painel único buscado pelos intrépidos exploradores de TI do passado, um plano único de controle pode estar ao nosso alcance. Isso porque ele não se baseia em uma GUI, mas na API.

E não qualquer API, mas uma API declarativa.

Para entender o motivo, vamos voltar a 2010, quando o termo "Infraestrutura 2.0" estava em alta.

Na camada mais básica da arquitetura está a Infraestrutura 2.0. A Infraestrutura 2.0 concentra-se em viabilizar o dinamismo e a colaboração em toda a infraestrutura de rede e de entrega de aplicações. É por meio dela que os componentes fundamentais do data center, tradicionalmente desconectados (do ponto de vista da comunicação e do gerenciamento), passam a ter a capacidade de se conectar e colaborar. Isso é realizado principalmente por meio de APIs abertas e baseadas em padrões que fornecem um conjunto granular de funções operacionais que podem ser acionadas por diversos métodos programáticos, como sistemas de orquestração e aplicações personalizadas, bem como por meio da integração com soluções tradicionais de gerenciamento de data centers. A Infraestrutura 2.0 visa tornar a rede mais inteligente, tanto do ponto de vista do gerenciamento quanto da execução em tempo real, mas, no que diz respeito à sua relação com a nuvem e a TI como serviço, o foco principal está no gerenciamento.

A Infraestrutura 2.0 inclui a habilitação como serviço de tudo, desde roteadores e switches até balanceadores de carga e aceleração de aplicações, desde firewalls e componentes de segurança de aplicações web até a infraestrutura de servidores (físicos e virtuais). Em sua essência, trata-se de componentes habilitados para API.

De <https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>

Parece familiar? Não chamamos mais isso de Infraestrutura 2.0, mas de "implantação contínua", "automação" e outros termos relacionados a DevOps. Mas o conceito é o mesmo. Essa ideia traz em si a razão pela qual um "painel único" nunca se concretizou. Afinal, para que uma estrutura tão mítica existisse, uma única solução precisaria incorporar (integrar por métodos manuais) uma vasta gama de soluções de rede, serviços de aplicações e segurança.

Isso nunca iria acontecer.

Para ser sincero, isso nunca iria acontecer, apesar de a maior parte dessa infraestrutura ter sido habilitada para APIs. Por quê? Porque todas essas APIs eram imperativas e estavam tão estreitamente vinculadas ao modelo de objetos de cada dispositivo quanto suas interfaces gráficas. APIs imperativas são inerentemente vinculadas a modelos de objetos específicos de dispositivos/serviços, que impõem uma pesada carga de conhecimento operacional a quem tenta usá-las. Agora imagine o profissional faz-tudo da sua organização de TI, em quem você confia para gerenciar operacionalmente roteadores, switches, dispositivos de segurança e cinco categorias diferentes de serviços de aplicativos de vários fornecedores.

Exatamente. Uma criatura dessas é como o Pé-Grande: muito se ouve falar dela, mas sua existência nunca foi comprovada.

O que quero dizer com isso? Quero dizer o seguinte:

A maneira como nós, por exemplo, representamos um pool, um VIP (endereço IP virtual) ou uma VLAN (rede local virtual) não é a mesma que a Cisco, a Citrix ou a Juniper usam para representar os mesmos objetos de rede. Na verdade, nossa terminologia pode até ser diferente: usamos “pool”, enquanto outros fornecedores de ADC usam “farm” ou “cluster” para representar o mesmo conceito. Quando acrescentamos a virtualização, surge ainda outro conjunto de termos, muitas vezes conflitante com os usados pelos fornecedores de infraestrutura de rede. “Servidor virtual” tem um significado completamente diferente para um fornecedor de entrega de aplicações e para um fornecedor de virtualização como a VMWare ou a Microsoft.

Fonte: <https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>

É POR ISSO que não podemos ter coisas boas, como um painel único. Porque o setor não tem um painel único por meio do qual ele visualize a infraestrutura.

Mas este post não foi feito para desanimar você nem para conduzi-lo a uma realidade de TI para sempre marcada pelo gerenciamento individual de cada dispositivo. Muito pelo contrário. APIs declarativas — verdadeiramente declarativas — podem levar a um plano de controle único.

Mas, para isso, precisamos abandonar a ideia de que declarativo significa codificar as configurações dos nossos dispositivos em JSON ou YAML. Isso não é verdadeiramente declarativo, pois ainda depende de conhecimento especializado do domínio operacional vinculado a modelos de objetos específicos de cada dispositivo — e ninguém mais consegue processá-los e utilizá-los.

Vou usar as descrições dos recursos Service e Endpoint do Kubernetes como exemplo de um modelo declarativo:

Tudo o que preciso para configurar um servidor virtual está bem aqui nestas definições muito concisas e independentes de implementação. O externalIP é o endereço IP virtual — o endereço com o qual o usuário ou aplicativo móvel se comunicará. O nome "my-Service" descreve um servidor virtual, enquanto a spec fornece os detalhes da rede, como quais ports usar e qual pool ("MyApp"). Os recursos de Endpoint descrevem cada um dos nós que compõem "my-service" e fornecem os membros do pool "MyApp". A única coisa que falta aqui é uma forma de selecionar um algoritmo de balanceamento de carga para os serviços capazes de fazer mais do que round-robin. E poderíamos facilmente estender a parte "spec" da descrição do serviço para incluir uma opção "algorithm: RR | WRR | LC | FR", aplicável universalmente a todas as soluções de balanceamento de carga. Pronto. Feito.

Em teoria, posso fornecer esse mesmo recurso a qualquer uma de dez soluções diferentes de balanceamento de carga, e cada uma determinaria como modelar e implementar a intenção da descrição — que é configurar um serviço virtual localizado em 80.11.12.10, na porta 80, que distribui as solicitações HTTP entre duas instâncias da aplicação localizadas em 1.2.3.4 e 2.3.4.5, na porta 80.

Outra forma de pensar nisso é comparar a diferença entre "Eu gostaria de uma pizza de pepperoni" e a versão mais trabalhosa: "Eu gostaria que você preparasse uma massa de pizza e depois a abrisse em um círculo de 10 polegadas de diâmetro. Cubra-a com molho de tomate. Por cima, coloque queijo muçarela. Agora, distribua o pepperoni por toda a superfície. Asse a 425 graus por 15 minutos."

Uma dessas opções é mais fácil e poupa você dos detalhes. A outra exige que você não apenas saiba o que quer — uma pizza de pepperoni —, mas também como prepará-la. Isso é o que se chama de conhecimento operacional.

Assim como ao pedir uma pizza, a descrição do recurso do Kubernetes é genérica. Nada nela impõe um modelo de objeto ou método de implementação específico ao dispositivo que recebe esse recurso. Ela descreve o que precisa estar presente, mas não interfere de forma alguma em como eu poderia implementá-lo.

Ser verdadeiramente declarativo significa fornecer os meios para comunicar a intenção e o estado final desejado. Em algum momento no futuro, bastará dizer: "configure um serviço virtual para 'my-app'" e voilà! Usando metadados, tags de aplicativos e descoberta automatizada e inteligente, o serviço se configurará por completo*.

Se quisermos algum dia alcançar o nirvana de um plano de controle único, teremos que arregaçar as mangas e criar especificações declarativas neutras que eliminem a necessidade de integrar, por meio de APIs imperativas, cada dispositivo do data center. Afinal, a integração de APIs dispositivo por dispositivo não é muito diferente do gerenciamento dispositivo por dispositivo.

Queremos coisas boas. Queremos um plano de controle único e unificado. Mas, para chegarmos lá, o setor terá que fazer mais do que apenas concordar superficialmente com a abordagem declarativa e reconhecer que se ninguém mais consegue interpretar e usar sua interface declarativa, então, para começo de conversa, ela não é realmente declarativa.

*Uma garota pode sonhar, não pode?

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