Skip to main content

Gestão de Recursos Evolução

É difícil distinguir o que é um aplicativo e o que é infraestrutura. Estamos caminhando em direção à imutabilidade e tudo gerenciado por meio de APIs, não importa se é rede, processos, clusters ou qualquer coisa. É tudo sobre gerenciar recursos e o que mudou ao longo do tempo é como gerenciamos recursos.

Primeiro Momento​

Começamos escrevendo scripts para gerenciar recursos que eram complicados de escrever e dificeis de manter, dado o número de permutações entre o estado desejado e o estado real dos recursos. O resultado disso foi criar ferramentas como Chef e Puppet, e algumas outras, que foi engolidas pelo Ansible. Chamamos essas ferramentas de ferramentas de gerenciamento de configuração e todas elas têm duas coisas em comum:

  • São baseadas teoria da promessa, permitindo-nos especificar o que queremos em vez de especificar como fazer algo e o seu trabalho era converter o estado desejado em estado real.
  • Foram projetadas para trabalhar com servidores e que tudo é mutável. Chamamos essas ferramentas de ferramentas de gerenciamento de configuração.

Segundo Momento​

Então começamos a utilizar APIs e imutabilidade e nasceram o Terraform e o Pulumi para declarar o que queremos. Definiríamos o que queremos, o estado desejado, e essas ferramentas reconciliariam isso com o estado real conversando com APIs, seja AWS, Azure, Google Cloud ou qualquer outra e assim nasceu a Infraestrutura como Código.

Sempre tem algum binário em algum lugar que interpreta os nossos manifestos, nossas declarações, e se comunica com a alguma API para transformar o nosso estado desejado em estado real.

Terceiro Momento (Agora)​

Vamos chamar essa onde de ferramentas de Control Plane. Seu foco principal é criar APIs personalizadas. Em vez de definir o que queremos no mesmo nível dos recursos que estamos tentando gerenciar, essas ferramentas nos permitem nos tornar provedores de serviços.

Elas conseguem isso nos permitindo criar APIs com as quais os consumidores podem conversar. Agora podemos definir o que é um aplicativo, um banco de dados, um cluster ou qualquer outra coisa como um ponto de extremidade de API com seu schema.

Os consumidores não precisam lidar com detalhes de baixo nível, como VPC, sub-redes ou qualquer outra coisa que provedores como AWS ou Kubernetes nos dão. Há uma clara separação interna de preocupações com algumas pessoas em uma empresa criando serviços e outras consumindo esses serviços.

Os consumidores consomem invocando APIs e os provedores fornecem construindo serviços por trás dessas APIs. Enquanto as ferramentas de infraestrutura como código são baseadas em lições aprendidas do consumo de serviços criados por outros, as ferramentas Control Plane são baseadas em lições aprendidas da construção de serviços.

Ferramentas nessa categoria:

  • Open Application Model (OAM): Uma das mais antigas e começou com foco em aplicativos, mas hoje foi extendida para todo tipo recurso.
    • O KubeVela é a implementação mais comumento usada o OAM mas sua popularidade está em queda.
  • Cluster API: Seu problema esta no seu foco apenas em clusters do Kubernetes, resolvendo apenas parte do problema.
  • Crossplane: Assim como o KubeVela, nos permite criar nossos próprios endpoints de APIs, bem como processos que escutam esses endpoints e realizam a reconciliação necessária para converter o estado real no estado desejado dos recursos. Por ser mais flexível podemos criar qualquer tipo de definição com muito poucas restrições, se houver. Iniciou com alguma limitação mas foi melhorando ao longo do caminho.

O kro - Kube Resource Orchestrator faz parte dessa onda. Ele é muito parecido com Crossplane Compositions e pode, um dia, ser uma solução melhor, mas ainda esta crescendo. É um projeto muito novo, mas com muito potencial e por isso vale a pena ficar de olho. É a hora de usar? Não, mas é a hora de testar e se possível participar do projeto.