DevOps está morto! Viva a engenharia de plataformas!
Aqui vamos nós de novo: outro ciclo de hype de tecnologia saudando The New Big Thing, e como The Old Big Thing está morto. Mas como alguém que ainda acredita em DevOps (apesar de observar muitas iniciativas abaixo do ideal) e como alguém que realmente acredita na engenharia de plataforma moderna, gostaria de separar o tópico com um pouco mais de detalhes e com um pouco da história do meu tempo neste espaço. Todas as histórias são imperfeitas, mas algumas são úteis.
Uma Breve História da Engenharia de Plataforma
Construir plataformas digitais como uma forma de entregar software em escala não é uma invenção recente e é anterior ao surgimento do movimento DevOps no final dos anos 2000. Muitas grandes empresas de tecnologia cujo principal negócio era construir software perceberam décadas atrás que poderiam permitir que as equipes de desenvolvedores construíssem, enviassem e operassem aplicativos mais rapidamente e com maior qualidade padronizando a infraestrutura, construindo interfaces de autoatendimento, fornecendo abstrações de nível cada vez mais alto focadas em resolver problemas de desenvolvedor e dedicar uma equipe para manter tudo isso como uma plataforma.
No entanto, essas equipes tiveram que construir e operar essas plataformas inteiramente do zero, o que exigia um pool de engenheiros tecnicamente sofisticados (e bem remunerados) com habilidades operacionais, suporte executivo e foco organizacional, e que eram relativamente livres de TI herdada, em menos em comparação com sua empresa média. As ferramentas que consideramos normais hoje em dia em relação à infraestrutura como código não existiam e, como setor, ainda não havíamos experimentado o impacto transformador das plataformas de nuvem pública.
No início dos anos 2000, a Amazon criou uma plataforma de TI interna compartilhada para lidar com o que foi descrito como “pesado pesado indiferenciado”, para que os desenvolvedores pudessem se concentrar melhor no envio de valor aos clientes. Alguns anos depois, isso se tornou disponível para usuários fora da Amazon e cresceu rapidamente de uma plataforma de aplicativos da web para o fornecimento de infraestrutura como serviço, transformando todo o nosso setor. Por volta de 2003 ou 2004, o Google construiu uma organização SRE dedicada e começou a trabalhar no Borg, mas a empresa não tornou essas iniciativas conhecidas publicamente até publicar um whitepaper sobre Borg em 2015 e um livro sobre SRE um ou dois anos depois.
A polinização cruzada de funcionários em grandes empresas de tecnologia modernas significou que essas ideias e abordagens começaram a se espalhar – porque funcionaram.
O início do DevOps
As ineficiências em muitas organizações de desenvolvimento de grandes empresas e os problemas impostos às equipes de desenvolvimento por uma infraestrutura cada vez mais complexa já eram aparentes há algum tempo. As tentativas de resolver isso incluíram acesso de autoatendimento a máquinas virtuais de “imagem de ouro”, catálogos de software de autoatendimento e as primeiras incursões em PaaS, geralmente com níveis decentes de sucesso para novos aplicativos novos, mas muito menos para legados e comerciais aplicações de prateleira. Foi um desafio significativo impor mandatos em cenários internos variados (ou, pelo menos, mais variados do que as empresas de Big Tech), principalmente devido à carga regulatória sob a qual muitas delas operavam, com décadas de processos manuais e relativamente pesados em vigor.
Em paralelo com muito disso, mas em ambientes um tanto diferentes, todo o movimento DevOps começou a se fundir no final dos anos 2000, com um dos momentos iniciais significativos sendo a palestra de John Allspaw e Paul Hammond em 2009 na VelocityConf “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”, no qual enfatizaram a importância da comunicação, colaboração e alinhamento de incentivos entre operações e desenvolvimento. Uma comunidade inteira surgiu para investigar e promover essas ideias, e uma explosão de interessantes projetos de código aberto ocorreu.
A maior parte desse trabalho aconteceu abertamente e essas ideias foram adotadas por uma ampla variedade de organizações. O DevOps foi influenciado e emprestado de muitos movimentos e estruturas anteriores, incluindo Agile, Lean Manufacturing, The Toyota Way e conceitos de psicologia, ciência cognitiva, dinâmica organizacional e segurança industrial. É por isso que sempre pensei que o DevOps é melhor definido como uma coleção solta de práticas e processos em evolução que levam em conta o contexto.
Escalar o DevOps é difícil
Como rastreamos nos relatórios Puppet State of DevOps por vários anos, embora muitas empresas tenham sido bem-sucedidas na implementação de princípios e práticas de DevOps, uma proporção significativa de empresas ficou “presa no meio”, com sucesso decente no nível de equipe individual, mas não de forma consistente em toda a organização.
Em 2018, identificamos pela primeira vez que o sucesso do DevOps dentro da empresa exigia uma padronização significativa na forma de fornecer autoatendimento como parte de nosso modelo evolucionário de cinco estágios.
O modelo evolucionário DevOps
A ascensão da engenharia de plataforma
A engenharia de plataforma não é nova, mas não era um conceito particularmente acessível se você não tivesse experimentado por si mesmo. Em 2019, algumas das principais empresas de análise começaram a identificá-lo como uma tendência, e Manuel Pais e Matthew Skelton publicaram Team Topologies – um exame aprofundado do tema com base em sua ampla experiência em consultoria de TI e observação de padrões que funcionaram em prática. Eles não apenas mapearam a estrutura organizacional, mas forneceram conselhos prescritivos sobre dinâmica – que, na minha experiência, é o maior obstáculo para as organizações mais tradicionais.
Engenharia de plataforma e DevOps estão alinhados
Dado quantas grandes empresas lutaram para experimentar os benefícios do DevOps em suas organizações e que esse movimento mais prescritivo da engenharia de plataforma moderna está provando agregar valor rapidamente, alguns argumentaram que “o DevOps está morto” e que a engenharia de plataforma moderna suplantou isto.
Isso simplesmente não é verdade, e prestamos um péssimo serviço a nós mesmos como indústria se o perpetuarmos. O DevOps sempre emprestou ideias de outros movimentos, e a engenharia de plataforma é apenas mais uma a acrescentar à lista de organizações de certa escala e complexidade. Se você estiver trabalhando em uma pequena empresa com um punhado de desenvolvedores (alguns mais inclinados para o lado operacional do que outros), pode não haver necessidade de adotar a abordagem de plataforma, e os princípios em torno do DevOps ainda são uma ótima função orientadora.
O DevOps trata do uso da automação como uma ferramenta para alinhar incentivos e aumentar a colaboração entre todas as equipes envolvidas no ciclo de vida de entrega de software, a fim de entregar software melhor, mais rapidamente e com menos estresse. A engenharia de plataforma moderna adotou a abordagem de plataforma já existente e adicionou um foco explícito em tratar a plataforma como um produtos ao invés de como um projetobem como orientações claras sobre onde as equipes devem interagir por meio da colaboração e onde devem interagir por meio de interfaces de autoatendimento.
Como o DevOps, a engenharia de plataforma faz uso intenso de automação, concentra-se na colaboração, exige empatia nas funções organizacionais e mantém as pessoas em vez da tecnologia na frente e no centro. Está perfeitamente alinhado com o DevOps e está provando ser uma maneira viável para muitas empresas fazerem o DevOps em escala, em ambientes altamente complexos e variados.
O DevOps não está morto. É só evoluir.
Obtenha informações completas sobre como a engenharia de plataforma habilita o DevOps em escala no próximo relatório State of DevOps da Puppet: Platform Engineering Edition. Inscreva-se agora para obter o relatório.