O mito de um painel de controle único

Desde que me lembro — e me lembro de muito tempo — o apelo da TI por um único painel de vidro para visualizar e operar a infraestrutura atraiu a atenção da área de TI. Assim como o Santo Graal, ele nunca foi descoberto e muitos profissionais de TI se tornaram céticos quanto à sua existência.

A transformação digital colocou o último prego no caixão dessa construção mítica de gestão e deu origem a uma nova: um único plano de controle.

A boa notícia é que, diferentemente do painel único buscado pelos intrépidos exploradores de TI do passado, um único plano 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 porquê, deixe-me levá-lo de volta a 2010, quando o termo "Infraestrutura 2.0" estava na moda.

Na camada mais baixa da arquitetura está a Infraestrutura 2.0 . A Infraestrutura 2.0 se concentra em permitir dinamismo e colaboração em toda a rede e na infraestrutura de rede de entrega de aplicativos. É a maneira pela qual os componentes fundamentais do data center tradicionalmente desconectados (do ponto de vista da comunicação e do gerenciamento) são imbuídos da capacidade de se conectar e colaborar. Isso é feito principalmente por meio de APIs abertas e baseadas em padrões que fornecem um conjunto granular de funções operacionais que podem ser invocadas a partir de uma variedade de métodos programáticos, como sistemas de orquestração, aplicativos personalizados e por meio da integração com soluções tradicionais de gerenciamento de data center. A Infraestrutura 2.0 visa tornar a rede mais inteligente tanto do ponto de vista do gerenciamento quanto do tempo de execução, mas no caso de seu relacionamento com a nuvem e a TI como serviço, a visão é focada principalmente no gerenciamento.

A infraestrutura 2.0 inclui a habilitação de serviços de tudo, desde roteadores a switches, de balanceadores de carga a aceleração de aplicativos , de firewalls a componentes de segurança de aplicativos da web e infraestrutura de servidores (físicos e virtuais). São, resumidamente, 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, chamamos de "implantação contínua", "automação" e outros termos do tipo DevOps. Mas o conceito é o mesmo. Inserido nessa ideia está o motivo pelo qual um "único painel de vidro" nunca se concretizou. Porque para que uma construção tão mítica exista, uma única solução precisaria incorporar (integrar por meio de métodos manuais) uma vasta gama de soluções de rede, serviços de aplicativos e segurança.

Isso nunca iria acontecer.

Para ser honesto, isso nunca iria acontecer, apesar da habilitação de API na maior parte dessa infraestrutura. Porquê?Porque todas essas APIs eram essenciais e estavam tão intimamente acopladas ao modelo de objeto de cada dispositivo quanto suas GUIs. 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 sobre aqueles que tentam usá-los. Agora imagine o 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. Tal criatura é como o Pé Grande. Muitas vezes ouvido falar, mas nunca foi provado que exista.

O que quero dizer com isso? Quero dizer isto:

A maneira como nós, por exemplo, representamos um pool ou um VIP (endereço IP virtual) ou uma VLAN (LAN virtual) não é a mesma maneira como Cisco , Citrix ou Juniper representam os mesmos objetos de rede. De fato, nossa terminologia pode até ser diferente; usamos pool, outros fornecedores de ADC usam "farm" ou "cluster" para representar o mesmo conceito. Adicione virtualização à mistura e outro conjunto de termos será adicionado à mistura, muitas vezes conflitantes com aqueles usados por fornecedores de infraestrutura de rede. " Servidor virtual " significa algo completamente diferente quando usado por um fornecedor de entrega de aplicativos do que quando usado por um fornecedor de virtualização como VMWare ou Microsoft .

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

É por isso que não podemos ter coisas boas, como um único painel de vidro. Porque a indústria não tem um único painel de vidro através do qual possa ver a infraestrutura.

Mas esta publicação não foi criada para deprimir você ou levá-lo a um caminho de existência de TI marcada pela gestão por dispositivo para sempre. Pelo contrário. APIs declarativas — verdadeiramente declarativas — podem levar a um único plano de controle.

Mas para fazer isso, precisamos abandonar a ideia de que declarativo significa codificar nossas configurações de dispositivo em JSON ou YAML. Isso não é verdadeiramente declarativo porque ainda depende da experiência do domínio operacional que está vinculada a modelos de objetos específicos do dispositivo - e ninguém mais pode ingeri-los e usá-los.

Deixe-me usar as descrições de recursos do Kubernetes Service e Endpoint como um exemplo de um modelo declarativo:

Tudo o que preciso para configurar um servidor virtual está aqui, nessas 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 irá se comunicar. O nome "my-Service" descreve um servidor virtual, com a especificação fornecendo detalhes da rede, como quais portas usar e qual pool ("MyApp"). Os recursos do Endpoint descrevem cada um dos nós que compõem "my-service" e fornecem os membros para o pool "MyApp". A única coisa que falta aqui é uma maneira 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 um "algoritmo: Opção "RR | WRR | LC | FR" que é universalmente aplicável a todas as soluções de balanceamento de carga. Lá. Feito.

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

Outra maneira de pensar sobre isso é a diferença entre "Eu gostaria de uma pizza de calabresa" e a mais tediosa "Eu gostaria que você misturasse um pouco de massa de pizza e depois a abrisse em um círculo com 25 cm de diâmetro". Cubra com molho de tomate. Cubra com queijo mussarela. Agora coloque calabresa por cima. Asse a 425 graus por 15 minutos."

Uma dessas coisas é mais fácil e te ofusca dos detalhes. A outra força você não apenas a saber o que quer - pizza de calabresa - mas também como fazê-la. Isso é que é competência operacional.

Assim como pedir uma pizza, a descrição do recurso do Kubernetes é genérica. Nada nele força qualquer modelo de objeto específico ou método de implementação no dispositivo que ingere esse recurso. Ele 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, poderemos simplesmente dizer "configure um serviço virtual para 'meu-aplicativo'" e pronto! Usando metadados e tags de aplicativos e descoberta automatizada e inteligente, o serviço se configurará de cima para baixo*. 

Se quisermos atingir o nirvana de um único plano de controle, teremos que nos esforçar e criar especificações declarativas neutras que eliminem a necessidade de integrar, por meio de API imperativa, todos os dispositivos no data center. Porque a integração de API dispositivo por dispositivo não é tão diferente do gerenciamento dispositivo por dispositivo.

Queremos coisas boas. Queremos um plano de controle unificado e único. Mas para chegar lá, a indústria terá que fazer mais do que apenas concordar com a declarativa e reconhecer que, se ninguém mais puder ingerir e usar sua interface declarativa, ela não é realmente declarativa em primeiro lugar.

*Uma garota pode sonhar, não pode?