Isso faz parte de uma série de artigos que contribuíram para a KubeCon + CloudNativeCon em outubro.
As empresas são obrigadas a se mover mais rápido do que nunca para entregar valor aos seus clientes. O aumento contínuo da nuvem, SaaS e serviços sempre ativos significa que os clientes esperam novos recursos, menos bugs e Tempo de atividade de 99,99% (ou superior).
Para acompanhar essas demandas, muitas organizações tentam adotar o DevOps, mas adotar práticas de DevOps é mais fácil falar do que fazer. O livro “Topologias de equipe” descreve a abordagem líder para organizar equipes de negócios e tecnologia para fluxo rápido, fornecendo um modelo prático, passo a passo e adaptável para o design organizacional e interação da equipe. A equipe da plataforma é um bloco de construção descrito no livro.
O relatório “State of DevOps” de 2021 da Puppet menciona esse tipo específico de equipe e observa claramente que o nível de maturidade de DevOps está relacionado ao uso de plataformas criadas por equipes de plataforma e seu papel crucial na expansão de organizações de engenharia de alto crescimento.
O fio comum em tudo o que uma equipe de plataforma faz é:
- permitindo o autoatendimento do desenvolvedor em toda a organização e
- mantendo sistemas confiáveis e sustentáveis
- sem comprometer a experiência dos desenvolvedores (usuários finais) de trabalhar com a infraestrutura.
Muitas organizações estão em sua jornada para construir equipes de plataforma e estão lutando com isso, algumas por causa de tópicos organizacionais e culturais, que não são abordados neste post. Outros têm um problema mais comum: quantos engenheiros devem trabalhar na “plataforma”?
Como a ideia subjacente de uma plataforma nativa de nuvem é tornar os desenvolvedores mais eficazes, podemos usar o modelo criado por Peter Seibel (líder de tecnologia do Engineering Effectiveness Group do Twitter). Seibel descreve o seguinte modelo:
Onde E é a eficácia total, sim é o número total de engenheiros de plataforma, b é o aumento de eficácia para o primeiro membro da plataforma e s é a escala do impulso. As unidades de eficácia são FTEs.
Em sua organização, o número de engenheiros é fornecido. Os parâmetros interessantes para este modelo são o fator de escala, se o impulso, b. Para seu modelo, Seibel usa 0,7 para s e 2% por FTE para b.
Se esses parâmetros estiverem corretos, para uma organização de engenharia de mil pessoas, devemos dedicar mais de um quarto de nossos engenheiros — 255 — à eficácia da engenharia, que é uma grande parte da engenharia de plataforma. Isso produz uma eficácia total equivalente a 1.465 engenheiros pelo preço de 1.000.
O sucesso vem com escala, o que requer otimização não para o indivíduo e não para a equipe, mas para a organização como um todo. Usando o exemplo anterior de uma organização de engenharia de mil pessoas, se a plataforma for usada apenas por cem, 100 é o número relevante, não 1.000.
Este é obviamente um modelo muito simples e, como todos os modelos, está errado. Mas isso não o torna menos útil. Isso mostra que investir em plataformas e engenharia de plataforma compensa. Para que os engenheiros de plataforma possam aumentar a eficácia em toda a engenharia, as coisas precisam ser padronizadas.
As equipes de plataforma precisam criar uma plataforma nativa da nuvem que consiste em blocos de construção de alta qualidade que ofereçam um caminho pavimentado para as equipes de desenvolvimento e ainda permitam que essas equipes implantem e operem seu próprio aplicativo, que é o objetivo do DevOps.
A plataforma permite que suas equipes se concentrem na solução de problemas reais de negócios, abstraindo as complexidades e o trabalho da organização. Isso facilita para suas equipes criar, implantar e operar produtos. Isso, por sua vez, permitirá que sua organização acelere seu tempo de lançamento no mercado, aumente a receita, reduza custos e crie produtos inovadores para seus clientes.
Outro aspecto é que os trabalhadores ficarão mais felizes à medida que sua carga cognitiva diminuir. As plataformas abstraem as preocupações usuais de infraestrutura, o que leva a tempos de integração reduzidos para novos participantes, uma mudança entre equipes, uma saída ou a integração de uma nova equipe de desenvolvimento. Também será mais fácil atrair novos talentos, pois sua organização terá tempo para se manter atualizada em tecnologia, o que incentivará engenheiros talentosos a ingressarem em sua organização e criarão mais opções de recrutamento.
Concentrar habilidades especializadas em equipes de plataforma significa que os esforços de recrutamento para equipes de desenvolvimento podem se concentrar em desenvolvedores, testadores etc., sem exigir habilidades mais caras e especializadas em nuvem ou plataforma.
Os resultados da pesquisa Puppet mostram que as equipes de plataforma podem ser um alicerce para se tornar uma organização DevOps de alto desempenho, mas é fundamental observar que o sucesso requer mais do que simplesmente reestruturar departamentos. Ele também deve se concentrar em como eles trabalham juntos.
Da mesma forma que as equipes de plataforma impedem que as equipes de desenvolvedores reinventem a roda pelo caminho pavimentado, as equipes de plataforma devem evitar cair na mesma falácia. As equipes de plataforma devem se concentrar nas necessidades específicas de sua organização e fazer uso de soluções prontas para uso.
O valor de uma equipe de plataforma não vem apenas da plataforma em si, mas também do suporte e suporte à adoção que a equipe oferece à organização de desenvolvimento.
As equipes de plataforma são essenciais porque esse tipo de equipe atua como um dos principais alicerces para capacitar as equipes de desenvolvimento; seu papel é único e crucial para o resto do sucesso da organização. Se você está pensando em construir uma equipe de plataforma, certifique-se de entender adequadamente que o sucesso requer mais do que reestruturar a engenharia e alocar pessoas para a equipe de plataforma.
As áreas de foco precisam ser a interação entre as equipes e a otimização do fluxo. Se você decidir que uma equipe de plataforma é a certa para você, deixe a equipe trabalhar para entender os pontos problemáticos recorrentes e capacitar sua equipe, fornecendo espaço para criar e inovar. Seus desenvolvedores e seus resultados agradecem.