O verdadeiro DevOps - “você o constrói, você o executa” – tem sido a metodologia orientadora por trás de muitas equipes de desenvolvimento há anos. No entanto, a dura realidade é que a maioria dos desenvolvedores não gosta de lidar com infraestrutura. Não é apenas uma fonte de carga cognitiva significativa, mas também leva tempo longe de seu trabalho principal de escrever, depurar e executar aplicativos.

É aqui que as Plataformas Internas de Desenvolvedores (IDPs) apresentam uma vantagem significativa. Ao empregar engenheiros de plataforma para abstrair essa complexidade dos desenvolvedores, as organizações podem se afastar do modelo de DevOps desatualizado para uma solução mais adequada aos seus negócios.

Chris Stephenson, CTO da Humanitec, juntou-se recentemente à Sid Palas da DevOps Directive para discutir como os IDPs e a engenharia de plataforma são o futuro da entrega de software.

A engenharia de plataformas é o futuro

Fonte: Sid Palas post no Twitter “A maioria dos desenvolvedores não gosta de lidar com infraestrutura”

Embora algumas empresas possam ter alguns aspectos básicos de um IDP já em vigor (gráficos e scripts Helm semi-padronizados, fluxos de trabalho básicos do GitOps, etc.), elas precisam deengenhariade plataforma para fornecer esse propósito e direção internos da plataforma. O crescimento não direcionado geralmente leva a scripts não mantidos que mal estão conectados e que geralmente causam mais problemas do que resolvem. Este é particularmente o caso quando as novas tecnologias evoluem e impedem as organizações de usar essas práticas padronizadas.

Em comparação com isso, a engenharia de plataforma adota uma abordagem mais geral.

De acordo com Luca Galante, “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 umaPlataforma Interna de Desenvolvedores, cobrindo as necessidades operacionais de todo o ciclo de vida de um aplicativo.”

Em vez de olhar para ferramentas para resolver um problema específico, as organizações precisam olhar para o futuro e prever onde elas estarão. Isso requer um investimento significativo em uma equipe de engenharia de plataforma que possa gerenciar essa visão, mas garante que as organizações possam evoluir continuamente e manter uma pilha de tecnologia coesa.

Resolvendo problemas organizacionais com um IDP

Fonte: Sid Palas post no Twitter”Developer Comfort Zone”

O primeiro passo é dar um passo para trás e olhar para os problemas que o IDP precisa resolver. Isso é algo que muitas vezes é negligenciado na empolgação de construir um IDP, mas, nesses casos, as organizações não consideram que seu IDP é um produto. Chris diz:

“Você precisa pensar nisso como qualquer outro tipo de produto, seja B2C ou B2B. Seu IDP tem usuários, por isso tem clientes. Você precisa conversar com seus desenvolvedores e descobrir como você pode melhorar a experiência do desenvolvedor deles. Você precisa conversar com as operações para ver quais desafios elas estão enfrentando. E você precisa conversar com a gerência de engenharia para discutir quaisquer métricas que sejam importantes para sua organização.”

Embora o feedback do cliente seja vital para o sucesso de um IDP, sempre haverá alguns temas amplos que se apresentam durante o desenvolvimento da plataforma. O autoatendimento do desenvolvedor é uma parte fundamental de qualquer IDP, pois isso permite que os desenvolvedores executem seu código com dependências mínimas de outras pessoas. Não só isso, mas dá às equipes de operações e plataforma uma maneira de fornecer ferramentas, mantendo os padrões de segurança e outras práticas recomendadas.

O autoatendimento também não beneficia apenas os engenheiros. À medida que reduz o tempo necessário para executar ações básicas, os IDPs podem economizar dinheiro das organizações a longo prazo. Isso ocorre melhorando a eficiência da engenharia, reduzindo a carga cognitiva e usando a padronização para garantir que o código siga os padrões internos.

As plataformas internas estão em constante evolução à medida que a tecnologia evolui, o que significa que as organizações sempre precisarão de novas maneiras de padronizar o processo de desenvolvimento. Os engenheiros de plataforma desempenham um papel vital não apenas na construção de uma plataforma, mas também na garantia de que a plataforma atenda às expectativas das partes interessadas.

Com o autoatendimento do desenvolvedor desempenhando um papel significativo em qualquer IDP, esse envolvimento das partes interessadas é vital. Isso garante que a equipe de engenharia de plataforma saiba quais tarefas precisam ser padronizadas e encontre o nível correto de abstração. Chris explica:

“Um IDP precisa satisfazer as necessidades de autoatendimento de seus desenvolvedores e as necessidades de controle da equipe da plataforma sem forçar nenhum engenheiro a escapar das abstrações que projetamos. É uma maneira de estruturar o processo de desenvolvimento, em vez de construir um sistema pesado que está agitando uma carga de rodas.”

Quando as organizações devem criar um IDP?

Normalmente, uma Plataforma como Serviço (PaaS) oferece muitos benefícios para as organizações quando elas começam a aumentar suas equipes de engenharia. No entanto, esses benefícios não duram. Por exemplo, muitas empresas começam a desenvolver a Heroku porque ela fornece a funcionalidade que suas equipes precisam para iniciar e gerenciar software. Muito poucas organizações podem escalar com sucesso a Heroku e continuar usando PaaS à medida que crescem, portanto, essa não é uma opção realista para todas as organizações.

Fonte: Sid Palas post no Twitter “À medida que uma empresa / organização cresce, suas necessidades podem “superar” as restrições impostas pelas ofertas de FaaS e PaaS”

À medida que as organizações crescem, elas geralmente precisam de escalabilidade específica, integrações de software ou apenas mais controle do que essas ferramentas de PaaS oferecem. A primeira coisa que muitas organizações fazem é recorrer ao Kubernetes. No entanto, o que eles não consideram é que seus desenvolvedores - que estão acostumados com a facilidade das ferramentas de PaaS - agora precisam gerenciar muito mais infraestrutura. Os desenvolvedores são jogados em uma grande curva de aprendizado, onde agora precisam entender o gerenciamento de namespace, os manifestos e as ferramentas apenas para fazer seu trabalho.

Isso apresenta uma questão significativa tanto a curto quanto a longo prazo. Não só os desenvolvedores atuais estão enfrentando um aumento significativo na carga cognitiva, mas isso torna o processo de integração para novos desenvolvedores excessivamente complexo. Chris diz:

“No momento em que você está empregando o desenvolvedor 101, essa pessoa provavelmente não consegue entender tudo o que está acontecendo porque se perde em um grande mar de complexidade. Neste ponto, faz sentido criar um IDP porque você quer que os novos desenvolvedores se tornem produtivos rapidamente. Você não quer que eles gastem tempo descobrindo os intrincados detalhes de como seu pipeline de desenvolvimento funciona.”

Nesta fase, as empresas também podem começar a descobrir que grande parte da carga de trabalho de um desenvolvedor é ocupada executando as mesmas tarefas repetidamente. Isso pode ser algo como solicitar infraestrutura, encontrar as ferramentas de que precisam e executar seus aplicativos em escala para teste. É um padrão que se repete em várias empresas, especialmente quando as organizações precisam implantar código e executá-lo em escala.

É aqui que entram as plataformas internas. A coisa fundamental que os deslocados internos devem fazer é, de acordo com Chris:

“Um IDP é uma ponte entre os desenvolvedores e as equipes de plataforma para que os desenvolvedores possam fazer seu trabalho sem serem bloqueados pelas operações. Por outro lado, as operações podem garantir que os padrões sejam aplicados e que as coisas sejam escaláveis sem ter que colocar isso nos ombros do desenvolvedor.”

Embora todos os deslocados internos devam compartilhar esse objetivo central, não há dois deslocados internos que sejam idênticos. Grandes e pequenas organizações enfrentam problemas diferentes, e as plataformas internas devem evoluir à medida que a tecnologia muda e as empresas crescem. Chris elabora: “fazer autoatendimento para 2.500 desenvolvedores é muito diferente de 25 desenvolvedores”.

No final, a criação de um IDP é menos sobre quando você o constrói e mais sobre o benefício que ele trará aos desenvolvedores. Chris diz:

“Em uma grande empresa, você pode ter milhares de desenvolvedores, todos construindo pequenas partes de um aplicativo enorme com muitos microsserviços para gerenciar. Tem desafios muito diferentes para, por exemplo, uma startup com cinco a dez engenheiros que têm uma maior compreensão de como o sistema se encaixa.”

Da mesma forma, não há uma métrica de qualificação que indique quando uma organização precisa criar um IDP, pois isso dependerá da organização e de suas necessidades. As organizações devem considerar a criação de um IDP quando começarem a superar as plataformas de terceiros ou não forem capazes de fornecer uma ótima experiência de desenvolvedor para seus engenheiros e precisarem de soluções que melhor se ajustem aos seus problemas.

Fonte: Sid Palas post no Twitter”O sistema resultante é o que é conhecido como uma “Plataforma Interna de Desenvolvedores” (IDP)”

Obrigado a Sid Palas na DevOps Directive por hospedar esta conversa envolvente e informativa com Chris. Certifique-se deassistir a toda a palestra no YouTubepara obter a história completa de Sid e Chris, ouleia o tópico de resumo de Sid no Twittere participe da conversa.

Artigo Original