Este artigo apresenta uma perspectiva única sobre uma das tendências mais recentes em TI: Platform Engineering. Descubra como o Platform Engineering pode beneficiar a empresa e como pode impactar as equipes de DevOps.
Parece que estamos realizando uma mudança rumo ao Platform Engineering, e você, como indivíduo ou como empresa, deve levar essa evolução a sério!
Não sei exatamente quando o conceito DevOps falhou. Não tenho certeza se alguém percebeu que ele começou a vacilar, mas, sem dúvida, foi difícil de implementar para as empresas, porque tocou o nervo mais importante (quem tem dentes sensíveis sabe o que quero dizer) em toda prática de TI: a cultura! DevOps exige não apenas uma mudança na tecnologia, mas também nos processos e nas competências (People, Process, Technology – PPT). E isso representa um grande desafio para as empresas. Pelo menos, DevOps é confuso, especialmente quando uma empresa não nasceu na nuvem.
Platform Engineering representa um deslocamento para a esquerda de muitas práticas de DevOps (desenvolvimento de ferramentas, plataformas, processos, segurança etc.), mesmo que ninguém admita. Ninguém dirá isso, mas estou convencido de que, com Platform Engineering, o que o DevOps não conseguiu entregar será dominado, ao fazer surgir, já no início do ciclo total, algo que agora chamamos de “time de plataforma”.
Afirmações como “Platform Engineering é DevOps corretamente aplicado” ou falam da “evolução do DevOps (em direção ao Platform Engineering)”, “da modernização do DevOps” ou ainda: “Precisamos introduzir padronização e consistência nos fluxos de desenvolvimento”. Mas, essencialmente, com esses e semelhantes pensamentos e manchetes, está se alegando que as empresas implementam as práticas de DevOps de forma equivocada. Então a comunidade “cloud‑native” precisou inventar algo novo ou diferente para salvar todo o empreendimento da fogueira de uma tecnologia extinta!
Se você perguntar a alguns “padrinhos do DevOps”, descobrirá que eles nem se interessam pelo termo (DevOps), preferindo “Continuous Delivery” e outras denominações. Eu ficaria satisfeito com um conjunto de termos e definições amplamente reconhecidos, que cada um possa adotar e seguir mais ou menos, para que as empresas possam continuar a implantar e usar essas tecnologias. Ou seja, mais “agir continuamente” do que “debater continuamente”.
Sarah Polan (Field CTO da HashiCorp) diz não. Em seu blog “Platform Engineering – What We've Got Wrong”, ela afirma: “Descobrimos que a parte fácil em grandes empresas, como de costume, é a tecnologia. Facebook, Apple, Amazon, Netflix e Google talvez consigam comprar esses unicórnios míticos de DevOps. O resto do setor tem que se contentar em remendar arquiteturas quebradiças.” Sarah Polan – assim como eu – está convencida de que algumas empresas, devido à falta de habilidades e à rotatividade no setor de TI, que no ano passado chegou a 30 %, têm dificuldades para escalar o DevOps de forma consistente.1
Quais outras razões podem apontar para um fracasso do DevOps? Scott Finnie, ex-editor da Computerworld.com, estava no caminho certo quando escreveu em seu blog „The Top 5 Ways DevOps Fails“ („Os 5 principais motivos pelos quais o DevOps falha“) que: „Não se pode ignorar a cultura“.2
Quero dar continuidade ao argumento de Finnie: desenvolvedores e profissionais de operações têm características diferentes: os primeiros são pensadores criativos, originais e solucionadores de problemas; os últimos são pragmáticos, pensam estrategicamente e evitam riscos. Admito que isso é uma generalização, mas às vezes me pergunto se a visão de colaboração entre grupos tão diferentes não é idealista demais. Mais ainda: será que o DevOps foi talvez uma “conspiração” para que os desenvolvedores controlem totalmente a infraestrutura de nuvem e tirem o poder dos proprietários tradicionais de infraestrutura? Em certos círculos, hoje espera‑se que os desenvolvedores conheçam todos os aspectos de seu ambiente de nuvem, incluindo Site Reliability e Site Observability!
Notável é, inicialmente, como nossa indústria define Platform Engineering de maneira inconsistente, dependendo de quem se segue e do que se lê. Comecemos com a premissa. Os principais objetivos do Platform Engineering são racionalizar e padronizar o processo de desenvolvimento, bem como reduzir a carga cognitiva dos desenvolvedores.
Para alcançar esse estado paradisíaco, um ecossistema unificado de ferramentas compartilhadas e reutilizáveis e recursos de autoatendimento é montado e disponibilizado. Em resumo, Platform Engineering é uma plataforma que os desenvolvedores podem usar sem se preocupar com a infraestrutura subjacente.
Platform Engineering é a prova de que muitas empresas têm dificuldade em se beneficiar do DevOps. Ainda assim, me preocupa que o Platform Engineering supostamente seja vantajoso para o desenvolvedor, mas na realidade lhe imponha um caminho que ele não deseja seguir, especialmente ao lhe impor suas ferramentas.
Li muitos debates sobre como o Platform Engineering influenciará os papéis profissionais. Como e se vamos colocar os funcionários em compartimentos depende do tamanho e dos objetivos de cada empresa. Um ciclo de desenvolvimento de software ideal requer uma equipe versátil, em que cada membro saiba exatamente o que se espera dele, e possa trabalhar de acordo com suas habilidades, de modo que se sinta valorizado. Sem dúvida haverá sobreposições e borrões de fronteiras, mas o novo termo “Plattform-Teams” está gradualmente entrando no vocabulário dos desenvolvedores.
Como uma abordagem tecnológica emergente (ou talvez melhor, “salvadora”), o Platform Engineering deve disponibilizar aplicações e gerar valor de negócio mais rapidamente.
Os cinco principais objetivos do Platform Engineering (há mais):
O objetivo principal do Platform Engineering é criar uma „Internal Developer Platform” ou um „Internal Developer Portal” (IDP), como alguns chamam apaixonadamente. O IDP é uma coleção cuidadosamente selecionada de ferramentas, Soluções, funcionalidades e processos que permitem aos desenvolvedores o autoatendimento. O foco está em padronizar as práticas internas de desenvolvimento de uma empresa, a fim de criar um „caminho dourado” que facilite a jornada das desenvolvimentos apoiados até a produção.
Como já expliquei, não estou de forma alguma convencido de que os desenvolvedores se deixem “impulsionar” por um padrão corporativo ou, para ser mais diplomático, “unir‑se”, para então não poder mais experimentar com suas próprias ferramentas e plataformas de desenvolvimento.
Como eu vejo, Platform Engineering não é uma alternativa ao DevOps, mas sim uma parte dele (portanto o DevOps não está morto?). Considere o DevOps como um framework mais amplo, no qual Platform Engineering cobre certos aspectos do processo de desenvolvimento, enquanto outros elementos, como por exemplo SRE, completam a sobreposição que agora parece fazer parte da definição de todo o processo de desenvolvimento.
Platform Engineering pode otimizar o ciclo de desenvolvimento de software (Software Development Lifecycle; SDLC), mas não é uma solução mágica para todos os problemas no desenvolvimento ágil. Se o fluxo de trabalho do SDLC será bem‑sucedido ainda depende muito de fatores como colaboração em equipe, comunicação clara e gestão eficaz.
Seja como chamarmos Platform Engineering; eu me pergunto como isso impactará as empresas que já investiram fortemente em modelos e estruturas de equipe DevOps.
O volume dos investimentos em DevOps realizados varia consideravelmente de empresa para empresa, mas totaliza vários bilhões de dólares. Portanto, pode‑se afirmar com segurança que frequentemente se trata de valores muito altos.
Platform Engineering é, sem dúvida, outra mudança cultural, na qual equipes “tradicionais” de DevOps são transferidas para a nova abordagem. Os desenvolvedores precisam lidar com novas plataformas, ferramentas, interfaces e, possivelmente, até linguagens, tudo em nome da padronização. Vamos fazer uma breve pausa para esclarecer o seguinte: de profissionais experientes, que aperfeiçoaram seu ofício ao longo de anos, esperamos que mudem drasticamente suas práticas de desenvolvimento para essa forte transformação.
As consequências para papéis e responsabilidades também se tornarão evidentes. Podemos realmente assumir com segurança que todos estão dispostos a se submeter a esse novo ditado? É fácil imaginar que alguns não concordarão. Os potenciais conflitos e talentos perdidos podem ser aceitáveis para algumas empresas.
Enquanto eu apresentei acima os benefícios percebidos do Platform Engineering, cabe a todos nós, especialmente aos fornecedores e prestadores de serviços de TI, apoiar nossos clientes nessas mudanças. Acho que ainda temos muito “Engineering” pela frente!
Primeiro, precisamos reconhecer que todo esse assunto tem natureza temporária, que devemos encontrar um consenso abrangente sobre o significado de todos esses termos e desenvolver uma abordagem coerente à qual as empresas possam aderir. Sim, apesar de todo o caos, devemos conseguir tudo isso e, talvez, com a ajuda de nossos parceiros de tecnologia e serviço, encontrar nosso próprio caminho para alcançar os objetivos da nossa empresa.
Em relação ao Platform Engineering ainda há necessidade de mais discussões. Por exemplo, isso realmente reduzirá a sobrecarga cognitiva dos desenvolvedores? Afinal, muitos deles precisam primeiro enfrentar uma curva de aprendizado íngreme. Essa sobrecarga poderia, a longo prazo, passar inadvertidamente para as equipes de Ops e SRE, quando tentarem integrar os resultados do Platform Engineering em seus fluxos de trabalho?
Enquanto as empresas devem ser capazes de transferir o valor do DevOps para o Platform Engineering, elas precisam descontinuar outros investimentos desenvolvidos para a abordagem “clássica” do DevOps, como ferramentas, processos e dinâmica de equipe. Será interessante ver como suas equipes financeiras quantificam tudo isso. Até agora, aparentemente ninguém quer ou pode responder a essas perguntas. Quem ainda não teve nada a ver com o DevOps pode preferir aguardar para ver como tudo isso se desenvolve.
Enquanto as empresas ponderam suas opções, talvez uma nova mudança para a esquerda transforme todo o cenário. Tenho uma postura mais pragmática e realista a respeito: brinquedo já temos de sobra. Precisamos apenas abandonar nossa complacência, chegar a um consenso sobre alguns termos do setor e continuar ajudando os clientes a enfrentar a transição para um futuro nativo em nuvem.
1 Artigo de Engenharia de Plataforma, Sarah Polan, 2024, Pulse
2 As 5 Principais Formas de Falha do DevOps, Scot Finnie, 2018, DevOps
