O DevOps morreu?

Alguma vez se perguntou porque é que, mesmo com tanto investimento em DevOps, algumas empresas ainda enfrentam tantos problemas para implementar práticas ágeis de desenvolvimento e entrega de software? Porque é que em algumas organizações o ciclo de vida do software continua a ser um campo minado, repleto de pontos de estrangulamento e pontos de dor tanto para os developers como para as equipas de operações?

Nos últimos tempos, temos assistido ao surgimento de um novo conceito: a Engenharia de Plataformas. Muitos dizem que este é apenas um novo nome para o bom e velho DevOps, enquanto outros defendem que representa uma evolução natural e necessária. O que está realmente a acontecer? O DevOps morreu? Ou estaremos apenas a assistir à próxima fase da sua evolução?

Vamos explorar este tema fascinante e perceber o que realmente significa a engenharia de plataformas, como se diferencia do DevOps tradicional e porque deve estar atento a esta tendência que, segundo a Gartner, será adotada por cerca de 80% das grandes organizações de engenharia de software até 2026.

Uma breve história do desenvolvimento de software operacional

Para percebermos onde estamos, precisamos de saber de onde viemos. Recuemos no tempo e façamos uma rápida retrospetiva:

SysAdmin a negar um deploy a um dev júnior

A era do SysAdmin (final dos anos 90 e início dos anos 2000)

Lembram-se dos tempos em que tínhamos um único gatekeeper para todas as operações de infraestruturas? O famoso SysAdmin era o porteiro que controlava o acesso a tudo. Se um developer precisava de fazer qualquer coisa relacionada com a infraestrutura, tinha de passar por este gatekeeper.

Esta era a famosa abordagem de «jogar por cima do muro»: os desenvolvedores escreviam o código e, quando terminavam, jogavam por cima do muro para a equipa de operações o implementar e gerir. Inevitavelmente, isto resultava em experiências frustrantes de ambos os lados do muro.

Era comum ver os desenvolvedores a terminar as suas aplicações e a actualizar via FTP, editando ficheiros PHP directamente no servidor com o FileZilla, provocando aquela ansiedade do hot deploy. Que nostalgia para uns, e trauma para outros!

FireFTP nos anos 2000

A revolução DevOps (meados dos anos 2000 até hoje)

Quando a cloud começou a ganhar força, com a AWS a surgir em 2006, o conceito DevOps começou a estabelecer-se como o novo padrão de ouro para as equipas de engenharia. O DevOps prometia unir o desenvolvimento e as operações, criando uma cultura de colaboração e automatização que aceleraria a entrega de software.

«Tu constróis, tu executas» tornou-se o mantra, e a divisão tradicional entre desenvolvimento e operações começou a dissolver-se em muitas organizações. Isto trouxe melhorias significativas em áreas como a escalabilidade, disponibilidade e operacionalidade, mas também aumentou significativamente a complexidade do dia-a-dia.

Subitamente, os engenheiros precisavam de dominar 10 ferramentas diferentes, gráficos Helm, módulos Terraform e muito mais apenas para implementar e testar uma simples alteração de código num dos muitos ambientes da sua configuração de micro-serviços em vários clusters.

Onde é que o DevOps falhou?

O problema é que, ao longo desta evolução da cadeia de ferramentas, a indústria decidiu de alguma forma que a divisão do trabalho - que se revelou bem-sucedida em praticamente todos os outros setores da economia global - não era uma boa ideia para o desenvolvimento de software. Em vez disso, o paradigma DevOps foi defendido como o caminho para alcançar uma configuração de alto desempenho.

A ideia era nobre: os desenvolvedores deveriam ser capazes de implementar e executar as suas aplicações e serviços de ponta a ponta. No entanto, para a maioria das empresas, esta abordagem é bastante irrealista. Embora funcione bem para organizações avançadas como a Google, Amazon ou Airbnb, está longe de ser trivial replicar o verdadeiro DevOps na prática para a maioria das outras equipas.

A principal razão é que é improvável que a maioria das empresas tenha acesso ao mesmo conjunto de talentos e ao mesmo nível de recursos que podem investir apenas na otimização de fluxos de trabalho e experiências de desenvolvedor.

Os anti-padrões do DevOps

O que tende a acontecer quando uma organização de engenharia comum tenta implementar o verdadeiro DevOps é que emerge uma série de anti-padrões. Um exemplo clássico é o que acontece em muitas equipas de desenvolvimento quando a organização decide implementar o DevOps e remover uma função ou equipa formal de operações.

Os developers (normalmente os mais experientes) acabam por assumir a responsabilidade pela gestão de ambientes, infraestrutura, etc. Isto leva a uma configuração onde as «operações sombra» são realizadas pelos mesmos engenheiros cujo trabalho em termos de codificação e desenvolvimento de produtos é mais valioso.

Todos perdem neste cenário. O engenheiro sénior passa agora a ser responsável pela configuração e precisa de resolver pedidos de colegas mais juniores. A organização mais ampla está agora a utilizar incorretamente alguns dos seus recursos mais caros e talentosos e não consegue enviar recursos com a mesma velocidade e fiabilidade.

Estudos do setor confirmam esta realidade. Um levantamento recente mostrou que em 44% das organizações com baixo desempenho, alguns developers realizam tarefas de DevOps por conta própria e ajudam constantemente colegas menos experientes. Compare isto com as organizações de alto desempenho, onde 100% implementaram com sucesso uma verdadeira abordagem de «tu constróis, tu executas».

Sistema de tickets usado nos anos 2000

O ticket office: sintoma de um problema maior

Um sintoma claro de que a sua organização está a sofrer com estes anti-padrões é o que muitos chamam de «ticket office» - a necessidade de abrir inúmeros tickets para conseguir fazer qualquer coisa relacionada com a infraestrutura ou com a implementação.

Já trabalhou numa empresa onde, para cada nova aplicação ou alteração de infraestrutura, era necessário preencher vários formulários diferentes? Onde se escolhesse o template errado, recebia um e-mail a dizer: «Abriu o ticket errado, por favor abra novamente utilizando o formulário correto»?

Esta abordagem de ticket office é um sinal claro de que algo não está a funcionar bem na cultura DevOps de uma organização. Cria estrangulamentos, frustra os desenvolvedores e impede a entrega rápida de valor aos utilizadores finais.

O aparecimento da Engenharia de Plataformas

Então, qual é a diferença entre organizações de baixo e alto desempenho? Como é que as melhores equipas garantem que os seus desenvolvedores podem executar as suas aplicações e serviços sem a necessidade constante de ajuda de colegas seniores?

A resposta: têm uma equipa de plataforma a construir uma Plataforma Interna para Desenvolvedores (IDP - Internal Developer Platform). O Relatório State of DevOps 2020 da Puppet mostra claramente a correlação entre a utilização de plataformas internas e o grau de evolução do DevOps nas organizações.

A Engenharia de Plataformas é definida como a disciplina de conceção e construção de cadeias de ferramentas e fluxos de trabalho que permitem recursos de self-service para organizações de engenharia de software na era nativa da cloud. Os engenheiros de plataforma fornecem um produto integrado, frequentemente designado por «Internal Developer Platform», que abrange as necessidades operacionais de todo o ciclo de vida de uma aplicação.

Backstage IDP

Internal Developer Platform (IDP)

Uma IDP engloba uma variedade de tecnologias e ferramentas, integradas de forma a reduzir a carga cognitiva dos desenvolvedores, mantendo o contexto essencial e as tecnologias subjacentes. Ajuda as operações a estruturar a sua configuração e a permitir o self-service dos desenvolvedores.

As melhores organizações de engenharia configuram equipas internas de plataforma que constroem estas IDP. Ao utilizar estas plataformas, os desenvolvedores podem escolher o nível certo de abstração para executar as suas aplicações e serviços, dependendo da sua preferência.

Por exemplo, se um desenvolvedor gosta de mexer com gráficos Helm, ficheiros YAML e módulos Terraform, ótimo, pode fazê-lo. Se ele é um frontend developer júnior que não se importa se a aplicação está a correr no EKS, fantástico, pode simplesmente autoservir um ambiente que vem totalmente provisionado com tudo o que precisa para implementar e testar o seu código, sem se preocupar onde é executado.

Caminhos dourados e estradas asfaltadas

A engenharia de plataformas procura criar «caminhos dourados» e «estradas pavimentadas» para os desenvolvedores. Mas o que significa isto na prática?

A maioria das configurações de CI/CD hoje em dia concentra-se simplesmente na atualização de imagens. O CI constrói-as, atualiza o caminho da imagem nas definições, e está feito. Isto cobre a maioria dos casos de utilização de implantação. Mas as coisas começam a ficar mais complexas e demoradas quando precisamos de fazer qualquer coisa para além deste fluxo de trabalho básico, como:

• Adicionar variáveis de ambiente e alterar definições
• Adicionar serviços e dependências
• Fazer rollback e depurar
• Criar um novo ambiente
• Refatorar
• Adicionar/alterar recursos
• Aplicar RBAC (controlo de acesso baseado em funções)

A lista continua. A engenharia de plataformas consiste em ligar tudo isto a uma estrada pavimentada. Em vez de deixar que todos operem tudo e tenham de compreender toda a cadeia de ferramentas para o fazer, os engenheiros de plataforma fornecem a cola para ligar tudo numa experiência consistente de self-service.

Quando é que a engenharia de plataformas faz sentido?

Um equívoco comum é que a engenharia de plataformas é algo que só faz sentido em grandes equipas. E embora se a sua equipa for composta por 5 devs, uma equipa de plataforma e uma IDP sejam certamente exageros, assim que a sua organização crescer para além da marca dos 20-30 devs, uma Internal Developer Platform é provavelmente algo que deve considerar, mais cedo do que tarde.

Existem inúmeras histórias de equipas que adiaram a construção de uma IDP durante muito tempo e tiveram de sofrer dificuldades desnecessárias. Por exemplo, imagine que o seu único contratado DevOps deixa a empresa e toda a sua organização não consegue fazer deploy durante semanas.

Princípios da Engenharia de Plataformas

Muitas organizações estão a despertar para os benefícios das Internal Developer Platforms e do self-service do desenvolvedor. Para citar o Relatório State of DevOps 2021 da Puppet, «A existência de uma equipa de plataforma não desbloqueia inerentemente uma evolução DevOps mais elevada; no entanto, as grandes equipas de plataforma expandem os benefícios das iniciativas DevOps.»

Eis alguns princípios úteis que são um fio condutor comum entre as equipas de plataforma bem-sucedidas e as organizações orientadas para o self-service:

Missão e papel claros

A equipa de plataforma precisa de uma missão clara. Um exemplo: «Construir fluxos de trabalho fiáveis que permitam aos engenheiros interagir independentemente com a nossa configuração e autoservir a infraestrutura de que necessitam para executar as suas aplicações e serviços.»

Seja qual for o que faz mais sentido para a sua equipa, certifique-se de que este é definido desde o início. É também extremamente importante estabelecer um papel claro para a equipa de plataforma, que não deve ser vista como mais um help desk que cria ambientes on-demand, mas sim como uma equipa de produto dedicada que serve os clientes internos.

Trate a sua plataforma como um produto

Expandindo o foco no produto, a equipa de plataforma precisa de ser orientada por uma mentalidade de produto. Têm de se concentrar no que fornece valor real aos seus clientes internos, os desenvolvedores de aplicações, com base no feedback que receberam. Certifique-se de que enviam recursos com base neste ciclo de feedback e não se distrai a brincar com uma nova tecnologia brilhante que acabou de sair.

Foco em problemas comuns

As equipas de plataforma impedem que outras equipas internas reinventem a roda, abordando problemas partilhados repetidamente. É fundamental descobrir quais são estes problemas comuns: comece por compreender os pontos de dor dos developers e áreas de atrito que causam lentidão no desenvolvimento. Estas informações podem ser recolhidas tanto qualitativamente através de feedback dos desenvolvedores como quantitativamente, observando os KPIs de engenharia.

A cola é valiosa

Muitas vezes, as equipas de plataforma são vistas como um centro de custos puro, porque não enviam quaisquer recursos reais do produto para o utilizador final. Afinal, estão apenas a colar os nossos sistemas. Esta é uma perspetiva muito perigosa e, claro, esta cola é extremamente valiosa.

Os engenheiros de plataforma precisam de abraçar e anunciar internamente a si próprios e a sua proposta de valor. Uma vez que tenha concebido os caminhos dourados e as estradas pavimentadas para as suas equipas, o principal valor que cria como equipa de plataforma é ser a cola adesiva que une a cadeia de ferramentas e garante um fluxo de trabalho de self-service sem problemas para os seus engenheiros.

Não reinvente a roda

Da mesma forma que as equipas de plataforma devem impedir que outras equipas dentro da organização reinventem a roda e encontrem novas soluções criativas para os mesmos problemas, devem evitar cair na mesma falácia. Não importa se a sua solução CI/CD caseira é superior hoje em dia, os fornecedores comerciais irão alcançá-la eventualmente.

As equipas de plataforma devem sempre perguntar qual é o seu diferencial. Em vez de construir alternativas internas a um sistema de IC ou a um painel de métricas e competir com empresas que têm 20 ou 50 vezes a sua capacidade, estas devem concentrar-se nas necessidades específicas da sua organização e adaptar soluções prontas a usar às suas necessidades.

A organização de engenharia moderna

De acordo com o Relatório State of DevOps 2021 da Puppet, «as organizações altamente evoluídas tendem a seguir o modelo Team Topologies».

Publicado em 2019, o livro Team Topologies de Matthew Skelton e Manuel Pais tornou-se um dos planos mais influentes para as configurações modernas da equipa em organizações de engenharia bem-sucedidas. De acordo com o seu plano, existem quatro topologias fundamentais em torno das quais as equipas se devem estruturar:

1. Equipa alinhada com o fluxo: alinhada com um fluxo de trabalho de um segmento do domínio de negócio, trabalham na lógica de negócio principal.
2. Equipa facilitadora: ajuda as equipas alinhadas com o fluxo a ultrapassar obstáculos e deteta as capacidades em falta.
3. Equipa de subsistema complexo: forma-se sempre que é necessária experiência matemática/técnica significativa.
4. Equipa de plataforma: fornece uma plataforma interna convincente para acelerar a entrega por equipas alinhadas com o fluxo.

Como ilustrado no modelo, a equipa de plataforma é transversal a todas as outras, garantindo um fluxo de trabalho de self-service suave, desde o código até à produção.

Porque é que a Engenharia de Plataforma está a surgir agora?

Mas porque é que esta abordagem está a ganhar tanta força agora? Vários fatores contribuem para isso:

1. A crescente complexidade da nuvem nativa

À medida que as organizações adotam arquiteturas de microsserviços e tecnologias nativas da cloud, a complexidade das operações de desenvolvimento aumenta exponencialmente. Os desenvolvedores têm de lidar com contentores, orquestração, redes, segurança e muito mais.

2. A escassez de talento DevOps

Existe uma escassez significativa de profissionais com experiência em DevOps e infraestruturas na cloud. A engenharia de plataformas permite que as organizações aproveitem melhor estes recursos escassos, criando soluções reutilizáveis que beneficiam toda a organização.

3. A pressão por velocidade e qualidade

As empresas enfrentam uma pressão constante para entregar software mais rapidamente, sem comprometer a qualidade ou a segurança. A engenharia de plataformas promete acelerar o desenvolvimento sem sacrificar estes aspetos críticos.

4. A necessidade de normalização em grande escala

À medida que as organizações crescem, a necessidade de normalização torna-se mais premente. A engenharia de plataformas oferece uma forma de impor padrões sem criar estrangulamentos no processo de desenvolvimento.

O DevOps morreu?

Voltando à nossa questão original: o DevOps morreu? A resposta curta é: não, definitivamente não.

O DevOps não está morto - está a evoluir. A engenharia de plataformas não é uma substituição do DevOps, mas sim uma evolução natural que aborda algumas das limitações práticas da implementação do DevOps nas organizações do mundo real.

O DevOps estabeleceu os fundamentos: cultura de colaboração, automatização, medição e partilha (CAMS). A engenharia de plataformas constrói sobre estes fundamentos, fornecendo uma estrutura mais definida e sustentável para implementar estes princípios à escala.

Na sua essência, a engenharia de plataformas é a maturação do DevOps de uma filosofia para um framework operacional. Fornece uma estrutura clara para as organizações que desejam os benefícios do DevOps sem exigir que cada desenvolvedor se torne um especialista em todas as ferramentas e tecnologias envolvidas.

A transição para a Engenharia de Plataformas

Se está a considerar a transição para a engenharia de plataformas, aqui estão alguns passos a considerar:

1. Avalie a sua maturidade atual

Comece por identificar onde está a sua organização hoje em termos de capacidade de plataforma. Pode utilizar o Modelo de Capacidade de Engenharia de Plataforma para delinear onde se encontra a sua organização em capacidades como investimento, adoção, governação, aprovisionamento e gestão, interfaces e medição/feedback.

2. Identifique os seus objetivos

Defina claramente o que espera alcançar com a engenharia de plataformas. Isto pode incluir:

• Aumentar a qualidade da aplicação, reduzir bugs e problemas durante o lançamento
• Melhorar a segurança, reduzir o número de incidentes de segurança
• Diminuir o risco através de uma melhor conformidade
• Acelerar o tempo para entregar valor ao negócio
• Reduzir os custos de desenvolvimento ou operações

3. Construa a sua equipa

Para que a engenharia de plataformas seja bem-sucedida, precisa de uma equipa dedicada. Esta equipa deve ter uma combinação de competências, incluindo desenvolvimento, operações, segurança e uma forte mentalidade de produto.

4. Comece pequeno

Não tente resolver todos os problemas de uma só vez. Comece com uma «plataforma viável mais fina» (TVP - Thinnest Viable Platform) e cresça a partir daí. Concentre-se em resolver os problemas mais prementes que os seus desenvolvedores enfrentam.

5. Cultive a cultura certa

A engenharia de plataformas requer uma cultura organizacional que valorize tanto a autonomia como a estandardização. Isto pode exigir mudanças na forma como as equipas interagem e como o sucesso é medido.

Enfim...

A engenharia de plataformas representa uma evolução significativa na forma como pensamos o desenvolvimento e a implementação de software. Aborda muitas das dificuldades práticas que as organizações enfrentam ao tentar implementar o DevOps em escala, fornecendo uma estrutura mais tangível e operacional.

O DevOps não morreu - os seus princípios fundamentais de colaboração, automatização, medição e partilha são mais relevantes do que nunca. A engenharia de plataformas é simplesmente uma manifestação mais madura destes princípios, adaptada às realidades das organizações modernas de software.

À medida que a complexidade do desenvolvimento de software continua a aumentar, a engenharia de plataformas irá provavelmente tornar-se ainda mais importante. As organizações que adotam esta abordagem estarão agora bem posicionadas para enfrentar os desafios de amanhã.

Então, o DevOps morreu? Não, apenas cresceu e amadureceu na forma da engenharia de plataformas, preparando-nos para o próximo capítulo na evolução contínua de como construímos e entregamos software.

Afinal, como diria um velho sysadmin, «a única constante em TI é a mudança». E a mudança, neste caso, é definitivamente para melhor.