Em Container Land, a configuração declarativa é rei
A transformação digital interna é essencial para permitir a transformação digital externa. Um dos componentes fundamentais da transformação digital interna é a automação, que depende muito do plano de controle . O plano de controle é onde a automação acontece. Antigamente, na computação, nos referíamos a ela como “rede de gerenciamento” e usávamos protocolos como SNMP para fornecer monitoramento, configuração e controle.
Hoje, a rede de gerenciamento ainda existe, pelo menos teoricamente, como o meio pelo qual realizamos as mesmas tarefas por meio do plano de controle. O plano de controle é uma terra confusa de APIs, nós mestres e até mesmo filas de mensagens que permitem que componentes individuais em um sistema distribuído complexo se gerenciem (quase) automaticamente. Ela é cada vez mais orientada por eventos, o que exige uma mudança de pensamento em relação aos modelos centralizados de comando e controle do passado, que dependiam principalmente de modelos imperativos de gestão. Ou seja, um sistema central instrui os componentes implicitamente com chamadas de API específicas que fazem com que as alterações ocorram. Os ambientes de hoje, por outro lado, dependem de modelos declarativos que distribuem a responsabilidade de mudar a si mesmos.
Em nenhum sistema isso é mais evidente do que em ambientes conteinerizados. Visto de fora, esses sistemas parecem ser quase desonestos por natureza; mensagens e eventos são publicados e disparados à vontade, sem um suserano para determinar quem ou o que deve reagir a eles. O plano de controle não é mais tanto sobre controle, mas sim sobre distribuição em um plano que é mais uma malha do que as arquiteturas de hub e spoke dos sistemas de gerenciamento arcaicos. No mundo tradicional, usamos APIs e protocolos para enviar alterações aos componentes. No mundo digital e em contêineres, usamos APIs para extrair as informações necessárias para que um componente se modifique.
Este novo mundo é reativo e evita o modelo imperativo (orientado por API) do plano de controle tradicional, confiando em um modelo mais aberto e declarativo para atingir o estado final automatizado desejado.
Isso não é nenhuma surpresa. À medida que adotamos cada vez mais uma abordagem orientada por software para tudo (sob o manto de DevOps, Nuvem e NFV), tivemos que lidar simultaneamente com uma escala operacional massiva. Um modelo de gerenciamento imperativo de hub e spoke não é escalável de forma eficiente, pois o ônus de todas as mudanças recai sobre um controlador central capaz de se comunicar por meio de uma gama confusa de APIs com um grupo quase ilimitado de componentes. Este é um modelo “push”, no qual o gerente (controlador) envia alterações para cada componente afetado. Ele se torna o gargalo que faz ou destrói todo o sistema.
Um modelo orientado a eventos que depende de pull por componentes é necessário para dimensionar e aliviar a carga do controlador, o que, por sua vez, exige que os componentes que desejam participar desse plano de controle estejam confortáveis com um modelo de configuração declarativo. Porque em vez de enviar alterações por meio de uma API (imperativo), os contêineres estão nos pressionando a extrair alterações por meio de configurações declarativas. A responsabilidade recai sobre os fornecedores de componentes (sejam de código aberto ou comerciais) de assinar corretamente as alterações e, então, extrair as informações apropriadas necessárias para implementar essas alterações imediatamente.
Se isso parece infraestrutura como código, é porque realmente é. Configurações declarativas são basicamente código, ou pelo menos artefatos de código. A automação depende cada vez mais de sua premissa que desvincula a configuração de seu serviço. Em um modelo utópico ideal, essas configurações declarativas são completamente agnósticas. Ou seja, eles seriam legíveis por qualquer produto de qualquer fornecedor (comercial ou de código aberto) que ofereça suporte a esse serviço. Por exemplo, uma configuração declarativa descrevendo o serviço apropriado (servidor virtual) e os aplicativos que comprometem seu conjunto de recursos poderia ser ingerida pelo serviço X ou serviço Y e implementada.
Os arquivos de recursos do Kubernetes são um bom exemplo de um modelo de configuração declarativo no qual o que é desejado é descrito, mas em nenhum lugar é prescrito como . Isso é marcadamente diferente de sistemas que dependem de APIs de infraestrutura que exigem que a implementação esteja familiarizada – às vezes intimamente – com a forma de atingir os resultados desejados.
O modelo declarativo também permite tratar a infraestrutura como gado. Se um falhar, é simples matá-lo e iniciar uma nova instância. Toda a configuração necessária está no arquivo de recursos; não há um botão "salve seu trabalho ou ele será perdido" porque não há trabalho a perder. Isso é quase imutável e é definitivamente uma infraestrutura descartável e é uma necessidade em sistemas que mudam a cada minuto, se não a cada segundo, para minimizar o impacto de falhas.
À medida que avançamos cada vez mais em direção a sistemas automatizados de escala e – ouso dizer? – segurança, precisaremos adotar modelos declarativos para o gerenciamento da miríade de dispositivos e serviços que compõem o caminho de dados do aplicativo ou corremos o risco de ficarmos soterrados por uma avalanche de dívida operacional incorrida por métodos manuais de integração e automação.