PDI vs. Portal de autoatendimento: um confronto de engenharia de plataforma

Em 2007, o mundo conheceu o DevOps. Essa abordagem envolve reunir equipes de desenvolvimento e operações para acelerar implantações e melhorar a eficiência e a colaboração no ciclo de vida de desenvolvimento de software. É creditado por ser duas vezes mais rápido que uma abordagem tradicional.

No entanto, de acordo com o mais recente relatório State of DevSecOps 2023, apenas 9% das empresas utilizam exclusivamente DevOps e apenas 20% utilizam-no para mais de metade dos desenvolvimentos. Por que a aceitação é tão baixa quando os benefícios são tão claros? O relatório também revela que 80% das organizações tiveram dificuldades com a adoção do DevOps nos últimos cinco anos.

Melhorar a experiência do desenvolvedor (DevX) foi identificado como fundamental para impulsionar a aceitação. Uma experiência positiva do desenvolvedor aumentará a produtividade. O DevX afeta a eficiência com que os desenvolvedores escrevem, testam e implantam código. É mais provável que os desenvolvedores adotem e defendam ferramentas e tecnologias que ofereçam uma experiência contínua e intuitiva.

O foco, no entanto, evoluiu da criação de melhores condições para os desenvolvedores para tornar os processos mais intuitivos e envolventes. Para atingir esse objetivo, vimos o nascimento da engenharia de plataforma e a criação de plataformas internas para desenvolvedores (IDPs) que oferecem ferramentas e serviços selecionados — pipelines de CI/CD, conteinerização, ferramentas de monitoramento e assim por diante — para permitir o autoatendimento do desenvolvedor.

Até agora, tem sido útil para os desenvolvedores. Mas e quanto às outras partes interessadas menos técnicas dentro de uma organização que também estão envolvidas no consumo da infraestrutura de TI? Os arquitetos de soluções, opts, DevOps, FinOps, equipes de segurança e equipes de rede contribuem para o negócio, mas não são desenvolvedores dedicados.

Embora a definição de engenharia de plataforma do Gartner se concentre fortemente no DevX, é apenas uma peça do quebra-cabeça. Uma plataforma verdadeiramente impactante não é apenas para desenvolvedores; é para uma variedade muito maior de equipes.

Portais de autoatendimento

Na melhor das hipóteses, é fácil se perder no mar de siglas de TI, e o ecossistema de engenharia de plataforma é o mesmo, especialmente considerando que essas duas opções parecem prometer coisas semelhantes, mas entregar de forma bastante diferente. Para muitas organizações, escolher ou construir um IDP pode ser o que elas consideram necessário para salvar seus desenvolvedores do trabalho repetitivo enquanto procuram um portal de autoatendimento (SSP) para agilizar a automação.

Usado corretamente, um SSP pode se tornar o coração da jornada de transformação digital de uma organização. Eles fornecem recursos de governança para definir funções, um catálogo de serviços para aumentar a eficiência e automação que cuida de tarefas manuais e, ao mesmo tempo, reduz erros humanos para todas as equipes de uma organização que consomem infraestrutura de TI, mas, principalmente, não são desenvolvedores dedicados.

Servindo como uma ponte entre as equipes, usuários como gerentes de projeto, testadores de controle de qualidade e até mesmo partes interessadas de negócios podem se beneficiar do acesso a ferramentas úteis de governança e automação por meio de um SSP. Essas ferramentas capacitam “não desenvolvedores” a acompanhar projetos, identificar gargalos e obter insights sobre o processo de desenvolvimento sem a necessidade de conhecimento técnico profundo.

Os SSPs também incentivam a colaboração, que deve estar presente em todos os cantos do portal. Os repositórios compartilhados permitem que usuários que normalmente dependeriam das habilidades técnicas de um desenvolvedor dedicado armazenem código com controle de versão automatizado para manter tudo funcionando perfeitamente, bem como revisões de código para garantir que todos estejam na mesma página.

Esse trabalho contínuo entre plataformas para uma gama muito mais abrangente de usuários é benéfico, então qual é o problema?

O efeito boneca russa

Primeiro, trata-se de identificar uma necessidade. Para muitas organizações, adquirir ou construir um IDP que irá corrigir despesas gerais de operações e permitir o autoatendimento do desenvolvedor parece uma decisão simples, mas há alguma confusão em torno de identificar o que realmente é um IDP e como obtê-lo.

Backstage, a plataforma de código aberto do Spotify, tem causado grande impacto no espaço de engenharia de plataforma ao oferecer um sistema de plug-in que torna um IDP extremamente personalizável e colaborativo. A realidade, porém, é um pouco diferente, e essa abordagem DIY pode tornar todo o processo ainda mais confuso.

É aqui que uma visão holística é útil para permitir a supervisão do desenvolvimento. Isso fornece a todos os usuários que participam do jogo — gerentes, CFOs e até mesmo executivos de sustentabilidade — a capacidade de se afastar das tarefas diárias de desenvolvimento de software e ter uma visão mais ampla.

Ao fornecer uma interface amigável para definir e implantar recursos de nuvem, um SSP libera tempo e esforço necessários para definir configurações complexas de infraestrutura. A centralização de recursos fornece supervisão, ao mesmo tempo que permite o estabelecimento de barreiras de proteção para proteger contra a implantação de “TI paralela”. Isto não só ajuda a identificar recursos que não estão sendo usados ​​para economizar dinheiro, mas também ajuda a tornar as práticas de nuvem mais ecológicas, removendo recursos desnecessários.

Esta é a principal diferença entre um SSP e um IDP, e compreender quais capacidades uma organização precisa é fundamental para garantir uma jornada tranquila de engenharia de plataforma. Como uma boneca russa, um IDP é uma camada sobre um SSP que oferece ferramentas para agilizar todo o ciclo de vida de desenvolvimento de software. O SSP trata de funcionalidade e automação para todos os envolvidos.

A grande boneca é a plataforma de engenharia – a parte complicada que explica por que uma jornada de engenharia de plataforma leva cerca de três anos. Esta solução abrangente transcende as fronteiras dos SSPs e dos deslocados internos. A plataforma de engenharia é um conceito abrangente que abrange muitas funcionalidades, incluindo gerenciamento de recursos, colaboração de ecossistema e integração de plug-ins. Projetado para atender indivíduos de todos os níveis de habilidade, oferece uma interface amigável e recursos personalizáveis ​​para atender a diversas necessidades e fluxos de trabalho.

A relação entre as três camadas é como um quebra-cabeça onde cada pequeno detalhe é importante, mesmo que pareça insignificante à primeira vista. Conforme mencionado inicialmente, o DevOps percorreu um longo caminho desde 2007. Mas graças ao recente advento da engenharia de plataforma, bem como aos IDPs que são todos facilmente acessíveis através de um SSP, agora temos o potencial para acelerar melhorias na disciplina e criar soluções sem atrito. ambientes de autoatendimento que abrem o desenvolvimento para a força de trabalho mais ampla.

O post IDP vs. Portal de autoatendimento: um confronto de engenharia de plataforma apareceu pela primeira vez em The New Stack.