Introdução ao IDP (Internal Developer Platform)

DevOps não é sobre clouds, containers, Kubernetes, monitoramento, service mesh e todas essas ferramentas. O objetivo principal é permitir que os desenvolvedores sejam autossuficientes.

Gerenciar todas essas ferramentas, no entanto, não é DevOps. Times de SRE ou outra equipe, com a nomenclatura que sua empresa utiliza, são os responsáveis por conhecer profundamente essas ferramentas e mantê-las.

Não adianta disponibilizar uma infinidade de ferramentas para todos os desenvolvedores, porque, muitas vezes, eles não saberão usá-las corretamente. Tampouco terão tempo ou conhecimento necessário para entender os detalhes do Kubernetes, das clouds ou para resolver problemas complexos relacionados a essas tecnologias. Essas ferramentas devem ser gerenciadas por equipes especializadas em operações.

O desafio: como lidar com desenvolvedores sem conhecimento operacional profundo? É impossível que todos saibam tudo. Os desenvolvedores, geralmente, concentram seus esforços na escrita de código, enquanto o pessoal de operações (às vezes chamado de DevOps) assume a responsabilidade pelas etapas seguintes. A transição dessas responsabilidades é feita com o auxílio de pipelines, GitOps e outras técnicas que integram o trabalho entre os times.

No entanto, deveríamos capacitar os desenvolvedores para que eles fossem capazes de realizar essas tarefas sozinhos, como gerenciar clusters, configurar a infraestrutura, implantar seus aplicativos, executar integrações contínuas (CI), entre outros. O objetivo é criar times autossuficientes que combinem desenvolvimento e operações.

Entregar uma conta na cloud e esperar que os desenvolvedores resolvam tudo sozinhos não é eficiente. Eles enfrentariam uma curva de aprendizado enorme e cometeriam muitos erros devido à falta de experiência.

DevOps significa criar serviços que outras equipes da empresa possam consumir para se tornarem autossuficientes. Os clientes do DevOps são os desenvolvedores.

Nesse sentido, o DevOps está profundamente relacionado à criação de IDPs (Internal Developer Platforms). O IDP é uma plataforma de desenvolvimento interno destinada ao uso pelos desenvolvedores, que são os consumidores dessa plataforma.

O IDP é uma camada que permite que as equipes realizem as operações necessárias por meio de autoatendimento. Essa plataforma é criada e mantida pelas equipes de operações, SREs, DevOps e segurança.

Ao invés de sobrecarregar a equipe de operações com tarefas repetitivas para atender às demandas do time de desenvolvimento, podemos focá-los em criar serviços reutilizáveis que aumentem a produtividade de ambos os lados.

Com um IDP, o time de desenvolvimento não precisa ficar bloqueado esperando que a equipe de operações resolva uma solicitação. Muitas dessas solicitações são recorrentes e poderiam ser automatizadas ou padronizadas. Se o time de desenvolvimento puder resolver essas questões de forma autônoma, eliminamos bloqueios e reduzimos a carga de trabalho da equipe de operações.

O objetivo é fornecer uma plataforma que possibilite o ciclo de vida completo das operações, incluindo:

• Mudança de estados desejados
• Realizar certas operações ou ações
• Convergir o estado real para o estado desejado
• Observar o estado real do sistema

Estado Real (Actual State)

O estado real representa todos os recursos atualmente em execução no sistema. Ele reflete o que está operando no momento para atender às necessidades de negócio.

Podemos dividir o estado real em três categorias principais:

• Provedores: São os serviços e plataformas que utilizamos como base para o sistema. Exemplos incluem:
  • AWS
  • Azure
  • Google Cloud
  • On Premise
  • DataDog, Dynatrace, New Relic
  • Elastic
  • Splunk
  • Entre outros
• Infraestrutura: Representa os componentes que sustentam o sistema, como:
  • Servidores
  • Clusters
  • Bancos de dados
• Aplicativos: Inclui os softwares que compõem e dão suporte ao negócio:
  • Nossos próprios aplicativos, desenvolvidos internamente
  • Aplicativos de terceiros, que integram ou complementam o sistema

Para garantir que o estado real atenda aos objetivos da empresa, é essencial definir e gerenciar o estado desejado, o qual direcionará ajustes, melhorias e a convergência para o sistema ideal.

Estado Desejado (Desired State)

O estado desejado é a definição de como o estado real deve ser. Ele é criado por meio de código, manifestos, arquivos de configuração e outros artefatos. No entanto, essa definição pode se tornar extremamente complexa, pois envolve diferentes níveis de conhecimento e áreas de expertise.

Desafios do Estado Desejado

• Configuração de Aplicativos no Kubernetes

  • Para definir um aplicativo no Kubernetes, precisamos criar múltiplos manifestos para configurar recursos como deployments, services, ingress, etc.
  • É necessário também fazer build de imagens de contêiner e gerenciar todo o ciclo de vida do aplicativo.
  • Se o mesmo aplicativo for executado em outra plataforma, como servidores físicos ou outra nuvem, as configurações podem ser completamente diferentes.

• Definição de Infraestrutura na AWS (ex.: EKS)

  • Um cluster EKS exige configurações específicas, como: Provisionamento do próprio cluster EKS, grupos de nós (node groups), configuração de um Internet Gateway, VPC, sub-redes, entre outros.

Esses exemplos mostram que o estado desejado é composto por múltiplas peças interdependentes que precisam ser agrupadas para atingir o objetivo. Apenas pessoas com conhecimento técnico sobre esses blocos de construção conseguem fazer isso corretamente.

Ferramentas (Tools)

Não podemos evitar ter ferramentas, precisamos delas.

Existem outros grupos de ferramentas, no entanto, para IDP, essas são os tipos de ferramentas mais importantes que precisamos usar para habilitar o auto atendimento.

• Pipelines: Ferramentas para automação das etapas de CI/CD.
• GitOps: Para sincronizar o estado desejado com o estado real.
• Infraestrutura: Para gerenciar a infraestrutura.
• RBAC: Para autenticação e segurança do IDP.

Interface do Usuário (User Interface)

O IDP é o ponto central que conecta tudo e permite aos desenvolvedores alterar os estados desejados e observar o estado real. A interface desse sistema pode assumir diferentes formas:

• Web: Uma interface gráfica acessível por navegador.
• CLI: Uma interface de linha de comando.
• IDE: Extensões ou plugins integrados às ferramentas de desenvolvimento.

O ideal é oferecer uma combinação dessas opções para atender a diferentes preferências e necessidades.

Simplicidade e Usabilidade

O principal objetivo das interfaces de usuário para IDPs é tornar as coisas mais fáceis. Para isso, é essencial esconder a complexidade operacional. Isso significa:

• Abstrair as ferramentas e interfaces individuais por trás de uma camada unificada;
• Criar interfaces simples, feitas sob medida, que qualquer pessoa possa entender e utilizar.

---

Para que tudo isso funcione, precisamos de uma API robusta abaixo da interface do usuário. Não podemos depender de uma interface que apenas execute comandos diretamente no CLI, porque isso não é suficiente para todos os casos. A API deve:

• Executar ações de forma consistente;
• Prover informações quando consultada;
• Ser um ponto central para interação com o sistema.

O desafio surge quando lidamos com múltiplas ferramentas. Ter 100 ferramentas diferentes significa lidar com 100 APIs distintas, o que aumenta a complexidade. Precisamos de uma única API central que a interface do usuário possa usar como base.

Hoje, o Kubernetes é o principal candidato para essa função. Ele oferece uma API extensível e universal. Isso não significa que tudo precisa rodar no Kubernetes, mas sim que ele pode ser usado como uma camada de abstração para gerenciar operações diversas.

Não estou dizendo que tudo deveria estar rodando em Kubernetes, esse não é o objetivo. O Kubernetes não está tentando ser a única plataforma que você deve usar para executar seus aplicativos, mas está tentando se tornar a única API que importa. Podemos usar o Kubernetes não apenas para executar contêineres dentro de um cluster, mas para gerenciar tudo o que foi projetado para ser extensível e interagir com quase tudo.

API Universal (Universal API)

O Kubernetes não se limita a executar contêineres. Ele é uma API universal poderosa com um agendador (scheduler) altamente eficiente, capaz de gerenciar qualquer tipo de recurso. Os contêineres representam apenas a primeira onda de adoção e são uma pequena parte do que o Kubernetes pode e deve gerenciar.

Além disso, com o Controller Manager, o Kubernetes realiza a reconciliação contínua, assumindo tarefas operacionais que normalmente seriam feitas manualmente. Isso garante que o estado real esteja sempre alinhado com o estado desejado, proporcionando resiliência e confiabilidade ao sistema.

CR e CRD: A Base da Universalidade

Custom Resources (CR) e Custom Resources Definitions (CRD) são a chave de tudo e o motivo dessa API esta buscando se tornar universal.

• CRD (Custom Resource Definition): É a definição de como um manifesto YAML deve ser estruturado para descrever o estado desejado de um recurso.
• CR (Custom Resource): São os objetos que seguem a definição do CRD, representando os recursos personalizados dentro do cluster.

Os controladores do Kubernetes utilizam essas definições para transformar os manifestos em realidade, reconciliando o estado real com o desejado.

Podemos criar CRDs para gerenciar praticamente qualquer coisa:

• Aplicativos;
• Recursos em nuvem;
• Bancos de dados;
• Monitoramento de estados específicos
• Pipelines
• Outros

Todos deveriam ser capazes de escrever um CRD para monitorar o estado do que quiser.

Com os CRDs, é possível:

• Definir o que é um recurso de maneira padronizada;
• Compor e relacionar diferentes blocos de construção;
• Expor essas definições como novos recursos feitos sob medida.

Isso oferece uma oportunidade única para simplificar processos complexos. Por exemplo, a equipe de operações pode combinar diversos blocos em composições, permitindo que os desenvolvedores criem manifestos baseados nessas definições simplificadas. Os manifestos resultantes são convertidos em recursos personalizados, que automaticamente realizam as operações necessárias.

Colocando Tudo Junto

Os CRDs (Custom Resource Definitions) e CRs (Custom Resources) são a camada de abstração que precisamos para ocultar os detalhes irrelevantes para o público geral, simplificando tudo de forma que qualquer pessoa possa atender às suas necessidades com facilidade.

Pipelines Integrados

Precisamos de pipelines que executem ações específicas (como testes, criação de imagens, etc.) de forma automatizada sempre que algum evento ocorrer. A ferramenta de CI/CD escolhida deve ser integrada à API do Kubernetes.

Idealmente, a definição desses pipelines também deve ser baseada em CRDs, criando um modelo declarativo para o fluxo de trabalho. Embora possamos construir nossos próprios recursos, ferramentas como Argo Workflows e Tekton já fornecem essas funcionalidades prontas. No entanto, qualquer outra solução de CI/CD pode ser usada, desde que atenda às necessidades sem adicionar complexidade desnecessária. Afinal, pipelines são, essencialmente, apenas conjuntos de ações ou scripts executados em uma ordem específica.

Sincronização: Estado Desejado x Estado Real

Garantir que o estado real esteja sempre sincronizado com o estado desejado é essencial. Ferramentas como ArgoCD e Flux, baseadas em GitOps, já desempenham esse papel de maneira eficiente.

Infraestrutura como Código no Kubernetes

Para padronizar a infraestrutura, ela também deve ser declarada utilizando CRDs no Kubernetes. Embora possamos usar SDKs específicos das nuvens, ferramentas como o Crossplane já simplificam esse processo, permitindo gerenciar recursos de infraestrutura como bancos de dados, VPCs e muito mais, diretamente através de manifestos Kubernetes.

Orquestração de Aplicativos

A orquestração de aplicativos, especialmente em modelos customizados, pode ser desafiadora. Ferramentas como Crossplane e KubeVela permitem criar definições de recursos personalizados que representam aplicativos ou outros recursos de forma declarativa e flexível. O mais importante é que essas definições sejam acessíveis e consumíveis por todos os envolvidos no processo.

Gerenciamento de Permissões (RBAC)

Com o estado desejado armazenado no repositório Git, é crucial garantir que apenas as pessoas certas tenham acesso aos repositórios corretos e com as permissões corretas.

A maioria dos usuários não precisa acessar diretamente o Kubernetes ou a cloud, exceto em modo read-only.

O acesso direto ao Kubernetes ainda é necessário, mas apenas para o IDP, que precisa observar e monitorar o estado real.

Interação com o IDP

Toda interação com um IDP (Internal Developer Platform) se baseia em duas ações principais:

• Alterar o estado desejado.
• Observar o estado real.

Mudança do Estado Desejado

As alterações no estado desejado podem ser feitas de várias maneiras:

• Diretamente no código armazenado no repositório Git.
• Através da interface do IDP.
• Utilizando a CLI.
• Via IDE, com plugins ou extensões.

Independentemente do método escolhido, tudo DEVE ser refletido no repositório Git para garantir consistência.

Os pipelines também desempenham um papel importante na atualização do estado desejado. Por exemplo, ao construir e enviar uma nova imagem de contêiner para um registry, o pipeline pode automaticamente atualizar a tag da imagem em um manifesto YAML no repositório. Esse manifesto define o estado desejado do aplicativo.

Além disso, os desenvolvedores podem enviar código do aplicativo e criar, modificar ou atualizar manifestos baseados em CRDs. Esses CRDs, criados pelos operadores, são a base para definir e simplificar o que cada recurso é.

Observação do Estado Real

Ferramentas de GitOps detectam automaticamente discrepâncias entre o estado desejado (definido nos manifestos) e o estado real (representado pelos CRs no Kubernetes). Sempre que há um desvio, essas ferramentas sincronizam os dois estados para manter o sistema alinhado.

Responsabilidades do IDP

O IDP desempenha um papel crucial em três áreas principais:

• Criação de Manifestos:

  • Facilita a criação de manifestos baseados em CRDs, definidos pelos operadores.
  • Realiza o push dos manifestos para o repositório Git, garantindo que o estado desejado seja atualizado.

• Visualização do Estado Desejado: Permite observar o estado desejado do sistema, seja como um todo ou de partes específicas.

• Monitoramento do Estado Real: Coleta informações sobre o estado atual do sistema para fins de monitoramento, análise de logs e solução de problemas.

O objetivo do IDP não é apenas permitir que os desenvolvedores façam o que já fazem, mas também capacitá-los a realizar tarefas fora de suas áreas de especialização, de maneira mais simples, eficiente e acessível.

Qual IDP?

A maioria dos IDPs existentes no mercado funcionam bem para empresas pequenas, startups ou organizações que estão começando do zero e podem se adaptar a uma solução menos customizável. No entanto, para grandes empresas, isso se torna um desafio devido à complexidade dos processos existentes e à necessidade de uma adaptação mais robusta às particularidades do negócio.

Quando uma empresa chega ao ponto de implementar um IDP, geralmente ela já possui uma infraestrutura consolidada, com ativos, ferramentas e anos de investimento. Nesse contexto, é mais eficiente e prático que a ferramenta se adapte ao negócio, e não o contrário. Tentar impor mudanças culturais drásticas e alterar fluxos de trabalho bem estabelecidos pode ser contraproducente, gerando resistência interna e perda de produtividade.

Por isso, grandes organizações frequentemente optam por desenvolver seus próprios IDPs para garantir que sejam totalmente personalizados às suas necessidades. Essa abordagem permite criar soluções que atendam às exigências específicas de processos internos, conformidades, ferramentas já em uso e fluxos de trabalho existentes.

Construir ou Adaptar?

Embora desenvolver um IDP do zero possa parecer ideal para garantir personalização completa, não é sempre a melhor abordagem. Existem IDPs no mercado que oferecem alto grau de flexibilidade e podem ser customizados para atender necessidades específicas.

O Backstage, por exemplo, é uma solução amplamente adotada que permite criar uma interface gráfica adaptada, centralizar informações e fluxos de trabalho, além de integrar diversas ferramentas. Sua arquitetura baseada em plugins é uma grande vantagem, permitindo que equipes adaptem e expandam o IDP de acordo com o crescimento e as mudanças nas prioridades do negócio.

Por outro lado temos o Port que é uma solução SaaS, obviamente paga, porém bem adaptativa e com muitos recursos.

Além disso, algumas empresas utilizam uma abordagem híbrida: combinam a adoção de um IDP existente, como o Backstage, com o desenvolvimento de ferramentas e integrações próprias para complementar suas necessidades. Isso permite acelerar a implementação enquanto ainda garante flexibilidade e personalização.