A engenharia de plataforma é a disciplina de projetar e construir cadeias de ferramentas e fluxos de trabalho que permitem recursos de autoatendimento para organizações de engenharia de software na era nativa da nuvem. Os engenheiros de plataforma fornecem um produto integrado mais frequentemente referido como uma “Plataforma Interna de Desenvolvedor”, cobrindo as necessidades operacionais de todo o ciclo de vida de um aplicativo. UmaPlataforma Interna de Desenvolvedor (IDP) é uma camada sobre a tecnologia e as ferramentas que uma equipe de engenharia já possui. Ele ajuda as operações a estruturar sua configuração e habilitar o autoatendimento do desenvolvedor. A engenharia de plataforma feita corretamente significa fornecer caminhos dourados e estradas pavimentadas que correspondam ao nível de abstração preferido do desenvolvedor individual, que interage com a camada IDP.

Neste artigo, vamos explorar as origens desta disciplina e discutir as principais áreas de foco dos engenheiros de plataforma. Também explicaremos como isso se encaixa na configuração de uma organização de engenharia moderna e é, na verdade, um componente-chave na maioria das equipes de desenvolvimento avançadas.

Das cinzas do DevOps: a ascensão das Plataformas Internas de Desenvolvedores

Vamos voltar o relógio algumas décadas. No final dos anos 90 e início dos anos 2000, a época em que a maioria das configurações tinha um único gatekeeper (e ponto de falha), o SysAdmin. Se os desenvolvedores quisessem fazer qualquer coisa para executar seus aplicativos, eles tinham que passar por eles. Na prática, isso se traduziu no conhecido fluxo de trabalho “jogar sobre a cerca”, o que levou a experiências ruins em ambos os lados da cerca. Como indústria, todos concordamos que este não era o ideal a que deveríamos aspirar.

Ao mesmo tempo em que a nuvem começou a se tornar uma coisa, com o lançamento da AWS em 2006, o conceito de DevOps ganhou terreno e se estabeleceu como o novo padrão de ouro para as equipes de engenharia. Embora o nativo da nuvem tenha impulsionado grandes melhorias em áreas como escalabilidade, disponibilidade e operacionalidade, isso também significou que as configurações se tornaram muito mais complexas. Longe vão os dias de executar um único script para implantar um aplicativo monolítico consumindo um banco de dados relacional.

De repente, os engenheiros tiveram que dominar 10 ferramentas diferentes, gráficos Helm, módulos Terraform, etc. apenas para implantar e testar uma simples alteração de código em um dos vários ambientes em sua configuração de microsserviço multi-cluster. O problema é que, ao longo dessa evolução da cadeia de ferramentas, a indústria aparentemente decidiu que a divisão do trabalho (Ops e Devs), que se mostrou bem-sucedida em praticamente todos os outros setores da economia global, não era uma boa ideia. Em vez disso, o paradigma DevOps foi defendido como o caminho para alcançar uma configuração de alto desempenho.

Os desenvolvedores devem ser capazes de implantar e executar seus aplicativos e serviços de ponta a ponta. “Você o constrói, você o executa”. Verdadeiro DevOps.

O problema com essa abordagem é que, para a maioria das empresas, isso é realmente irrealista. Embora o acima funcione para organizações muito avançadas como Google, Amazon ou Airbnb, está muito longe de ser trivial replicar o verdadeiro DevOps na prática para a maioria das outras equipes. A principal razão é que é improvável que a maioria das empresas tenha acesso ao mesmo pool de talentos e ao mesmo nível de recursos que podem investir apenas na otimização de seus fluxos de trabalho e experiência de desenvolvedores.

Em vez disso, o que tende a acontecer quando uma organização de engenharia regular tenta implementar o verdadeiro DevOps é que uma série de antipadrões emergem. Isso está bem documentado pela equipede Topologias da Equipe(Matthew Skelton e Manuel Pais, palestrante em um de nossos encontros de Engenheiros de Plataforma) em sua análise dosantitipos de DevOps, uma leitura altamente recomendada para quem quer entender melhor essas dinâmicas. Abaixo, um exemplo do que surge em muitas equipes de desenvolvimento quando a organização decide implementar o DevOps e remover uma função ou equipe formal de Ops. Os desenvolvedores (geralmente os mais experientes) acabam assumindo a responsabilidade pelo gerenciamento de ambientes, infraestrutura, etc. Isso leva a uma configuração em que as “operações de sombra” são executadas pelos mesmos engenheiros, cuja entrada em termos de codificação e desenvolvimento de produtos é mais valiosa. Todos perdem. O engenheiro sênior que agora se torna responsável pela configuração e precisa resolver solicitações de colegas mais juniores. A organização mais ampla, que agora está abusando de alguns de seus recursos mais caros e talentosos e não pode enviar recursos com a mesma velocidade e confiabilidade.

Esse tipo de antipadrões foi demonstrado por vários estudos, como oState of DevOps by Puppetou, mais recentemente, peloestudo Benchmarking da Humanitec. Neste último, as organizações de alto e baixo desempenho foram agrupadas, com base em métricas padrão de DevOps (lead time, frequência de implantação, MTTR, etc.). Como mostrado abaixo, impressionantes 44% das organizações de baixo desempenho experimentam o antipadrão acima, com alguns desenvolvedores fazendo tarefas de DevOps por conta própria e ajudando colegas menos experientes. Isso é comparado aos de melhor desempenho, onde 100% das organizações implementaram com sucesso uma verdadeira abordagem “você cria, você executa”.

Então, qual é a principal diferença entre organizações de baixo e melhor desempenho? Como as melhores equipes garantem que seus desenvolvedores possam executar seus aplicativos e serviços, sem a necessidade constante de ajuda de colegas seniores? Você adivinhou, eles têm uma equipe de plataforma construindo uma Plataforma de Desenvolvedor Interno. O State of DevOpsReport 2020 da Puppetmostra claramente a correlação entre o uso de plataformas internas e o grau de evolução do DevOps das organizações.

Isso é o que as melhores organizações de engenharia fazem. Eles configuram equipes internas de plataforma que constroem IDPs. Ao usar esses IDPs, os desenvolvedores podem escolher o nível certo de abstração para executar seus aplicativos e serviços, dependendo de sua preferência, ou seja, eles gostam de mexer com gráficos Helm, arquivos YAML e módulos Terraform? Ótimo, eles podem fazê-lo. Eles são um front-end júnior que não se importa se o aplicativo está sendo executado no EKS? Fantástico, eles podem simplesmente auto-servir um ambiente que vem totalmente provisionado com tudo o que precisam para implantar e testar seu código, sem se preocupar onde ele é executado.

Caminhos dourados e estradas pavimentadas

O que queremos dizer com caminhos dourados e estradas pavimentadas? Sejamos mais específicos. Hoje, a maioria das configurações de CI/CD está focada em simplesmente atualizar imagens. CI os compila, atualiza o caminho da imagem em configurações, feito. Isso abrange a maioria dos casos de uso de implantação. Mas as coisas começam a ficar mais complexas e demoradas, sempre que precisamos fazer algo além desse fluxo de trabalho básico, como:

  • Adicionando variáveis de ambiente e alterando configurações
  • Adicionando serviços e dependências
  • Revertendo e depurando
  • Criando um novo ambiente
  • Refatoração
  • Adicionando/alterando recursos
  • Aplicando o RBAC

A lista continua. A engenharia de plataforma é sobre amarrar tudo isso em uma estrada pavimentada. Em vez de deixar que todos operem tudo e tenham que entender toda a cadeia de ferramentas para fazer isso, os engenheiros de plataforma fornecem a cola para vincular tudo a uma experiência de autoatendimento consistente.

Esta cola é a plataforma interna. Nas palavras deEvan Bottcher (Thoughtworks), as plataformas são “uma base de APIs de autoatendimento, ferramentas, serviços, conhecimento e suporte, que são organizados como um produto interno atraente. As equipes de entrega autônomas podem fazer uso da plataforma para fornecer recursos do produto em um ritmo mais alto, com coordenação reduzida.”

Com base nessa definição, Kaspar von Gruenberg, da Humanitec,define uma Plataforma Interna de Desenvolvedores como uma“camada de autoatendimento que permite que os desenvolvedores interajam de forma independente com a configuração de entrega de sua organização, permitindo que eles façam autoatendimento de ambientes, implantações, bancos de dados, logs e qualquer outra coisa que precisem para executar seus aplicativos”.

Princípios de engenharia de plataformas

Muitas organizações estão acordando para os benefícios das Plataformas Internas de Desenvolvedores e do autoatendimento do desenvolvedor. Para citar oRelatório de Estado de DevOps 2021 da Puppet, “A existência de uma equipe de plataforma não desbloqueia inerentemente DevOps de maior evolução; no entanto, grandes equipes de plataforma ampliam os benefícios das iniciativas de DevOps.”

Contratar o talento certo para construiressas plataformas e fluxos de trabalho pode ser complicado. E ainda mais complicado é garantir que eles forneçam consistentemente um produto confiável para o resto da organização de engenharia, incorporando seu feedback ao IDP.

Abaixo estão alguns princípios úteis que vejo serem um fio condutor entreequipes de plataformabem-sucedidas e organizações orientadas para o autoatendimento:

Missão e papel claros

A equipe da plataforma precisa de uma missão clara. Um exemplo: “Crie fluxos de trabalho confiáveis que permitam que os engenheiros interajam de forma independente com nossa configuração e atendam a infraestrutura de que precisam para executar seus aplicativos e serviços”. O que fizer mais sentido para sua equipe, certifique-se de que isso seja definido desde o início. Também é extremamente importante estabelecer um papel claro para a equipe da plataforma, que não deve ser vista como mais um help desk que cria ambientes sob demanda, mas sim como uma equipe de produto dedicada que atende aos clientes internos.

Trate sua plataforma como um produto

Expandindo o foco do produto, a equipe da plataforma precisa ser impulsionada por uma mentalidade de produto. Eles precisam se concentrar no que fornece valor real para seus clientes internos, os desenvolvedores de aplicativos, com base no feedback que eles lhes deram. Certifique-se de que eles enviam recursos com base nesse ciclo de feedback e não se distraiam brincando com uma nova tecnologia brilhante que acabou de sair.

Concentre-se em problemas comuns

As equipes de plataforma impedem que outras equipes reinventem a roda, enfrentando problemas compartilhados repetidamente. É fundamental descobrir quais são esses problemas comuns: comece entendendo os pontos problemáticos do desenvolvedor e as áreas de atrito que causam lentidão no desenvolvimento. Essas informações podem ser coletadas qualitativamente por meio do feedback dos desenvolvedores e quantitativamente, observando os KPIs de engenharia.

A cola é valiosa

Muitas vezes, as equipes de plataforma são vistas como um centro de custo puro, porque não enviam nenhum recurso real do produto para o usuário final. Eles estão apenas colando nossos sistemas, afinal. Esta é uma perspectiva muito perigosa e, é claro, essa cola é extremamente valiosa. Os engenheiros de plataforma precisam abraçar e anunciar a si mesmos e sua proposta de valor internamente. Depois de projetar os caminhos dourados e as estradas pavimentadas para suas equipes, o principal valor que você cria como uma equipe de plataforma é ser a cola pegajosa que une a cadeia de ferramentas e garante um fluxo de trabalho de autoatendimento suave para seus engenheiros.

Não reinvente a roda

Da mesma forma que as equipes de plataforma devem impedir que outras equipes dentro da organização reinventem a roda e encontrem novas soluções criativas para os mesmos problemas, elas devem evitar cair na mesma falácia. Não importa se a sua solução de CI/CD doméstica é superior hoje, os fornecedores comerciais vão recuperar o atraso eventualmente. As equipes da plataforma devem sempre perguntar qual é o seu diferencial. Em vez de criar alternativas internas a um sistema de CI ou a um painel de métricas e competir com empresas que têm 20 ou 50 vezes sua capacidade, elas devem se concentrar nas necessidades específicas de sua organização e adaptar soluções prontas para uso às suas necessidades. Os concorrentes comerciais são mais propensos a otimizar para necessidades mais genéricas da indústria de qualquer maneira.

A organização de engenharia moderna

De acordo como Relatório do Estado do DevOps 2021 da Puppet, “organizações altamente evoluídas tendem a seguir o modelo de Topologias de Equipe”.

Publicado em 2019, o livroTeam Topologiesde Matthew Skelton e Manuel Pais tornou-se um dos projetos mais influentes para configurações de equipes modernas em organizações de engenharia de sucesso. De acordo com seu projeto, existem quatro topologias fundamentais em torno das quais as equipes devem se estruturar.

  • Equipe alinhada ao fluxo: alinhada a um fluxo de trabalho de um segmento do domínio de negócios, eles trabalham na lógica do negócio principal.
  • Capacitando a equipe: ajuda as equipes alinhadas ao fluxo a superar obstáculos e detecta recursos ausentes.
  • Equipe complicada do subsistema: forma sempre que é necessário um conhecimento matemático/técnico significativo.
  • Equipe da plataforma: fornece uma plataforma interna atraente para acelerar a entrega por equipes alinhadas ao fluxo

Como pintado no gráfico acima, a equipe da plataforma é transversal a todas as outras, garantindo um fluxo de trabalho de autoatendimento suave, do código à produção.

Quando você deve olhar para isso?

Um equívoco comum é que a engenharia de plataforma é algo que só faz sentido em grandes equipes. E enquanto se sua equipe é composta por 5 desenvolvedores, uma equipe de plataforma e IDP são certamente um exagero, assim que sua organização cresce além da marca de 20-30 desenvolvedores, uma Plataforma Interna de Desenvolvedores é provavelmente algo que você deve olhar, mais cedo ou mais tarde. Ouvi inúmeras histórias de equipes que atrasaram a construção de um IDP por muito tempo e tiveram que sofrer dificuldades desnecessárias, por exemplo, sua única contratação de DevOps sai e toda a sua organização não pode implantar por semanas. IDPs e contratação de engenheiros de plataforma são investimentos que você pode querer considerar hoje.

Como começar

Se você está lendo isso, você já está no meio do caminho. Participe de nossos eventos,junte-se ao canal do Slack, interaja com outros engenheiros de plataforma e nerds de plataforma. Acompanhe a jornada de outras equipes, como Adevinta, Flywire e outras. Compartilhe com a comunidade com o que sua equipe luta e entenda quando e onde o autoatendimento pode fazer sentido. Confira as ofertas existentes em torno das Plataformas Internas de Desenvolvedores para iniciar sua jornada. Comece leve e continue iterando em casos de uso.

Artigo Original