Construir vs. Comprar: O Guia do Engenheiro de Plataforma

Construir ou comprar uma plataforma de desenvolvedor interna (IDP) é uma dúvida comum para organizações que estão iniciando sua jornada de engenharia de plataforma. No entanto, não existe uma resposta única para todos. Ambas as opções têm prós e contras que podem ajudá-lo a tomar a melhor decisão para sua organização.

Plataforma de desenvolvedor interno ou plataforma como serviço?

O que significa construir ou comprar? O white paper sobre plataformas da Cloud Native Computing Foundation (CNCF) usa a definição de Martin Fowler e Evan Bottcher de uma plataforma de desenvolvedor interna (ou plataforma digital):

“Uma plataforma digital é uma base de APIs de autoatendimento, ferramentas, serviços, conhecimento e suporte… organizados como um produto interno atraente. Equipes de entrega autônomas podem usar a plataforma para entregar recursos de produtos em um ritmo mais acelerado, com coordenação reduzida.”

Alguns argumentam que esta definição significa que os deslocados internos devem ser construídos e não podem ser comprados. No entanto, esta distinção pode ser confusa, uma vez que alguns fornecedores anunciam os seus produtos como deslocados internos. Compreender quais qualidades distinguem as plataformas construídas das compradas é mais valioso.

Um IDP que pode ser adquirido costuma ser chamado de Plataforma como Serviço (PaaS). Enquanto um IDP é uma coleção de diferentes tecnologias e ferramentas coladas, um PaaS é um ferramenta que cobre algumas (mas não necessariamente todas) das mesmas funcionalidades.

Outra distinção importante é quem decide como os desenvolvedores trabalham. Com uma PaaS, o fornecedor define a experiência do usuário e os limites da plataforma. Com um PDI sob medida, a empresa define a experiência do usuário e os limites da plataforma; as limitações decorrem das competências, do orçamento e do contexto empresarial da equipa da plataforma.

Construir um PDI internamente do zero e comprar uma PaaS são dois extremos de um espectro: construir vs. comprar não é uma escolha binária.

Dada a natureza restritiva das ofertas de PaaS, não veremos muitas organizações comprando uma PaaS e construindo o restante da plataforma em torno dela. No entanto, eles podem comprar um portal de desenvolvedor interno, um construtor de plataforma, um plano de controle, uma plataforma DevOps, uma plataforma de entrega de aplicativos ou algum outro tipo de ferramenta de plataforma de um fornecedor e construir internamente apenas o que for necessário. A maioria das organizações utiliza alguma combinação de ferramentas construídas, compradas e de código aberto para sua plataforma.

Manter esse espectro de abordagens em mente é útil ao analisar suas vantagens e desvantagens.

Construindo uma plataforma interna para desenvolvedores: prós e contras

Prós da construção

É difícil acertar a engenharia de plataforma, mas ela está ganhando força de qualquer maneira – por um bom motivo. A construção de um PDI capacita as organizações, especialmente as empresas, a criar algo perfeitamente adequado às suas necessidades. Muitas organizações constroem seu PDI devido a estas vantagens:

• Personalização:Construir um IDP dá às organizações controle total sobre suas especificações e roteiro de recursos. Essa autonomia permite que as equipes da plataforma adaptem o IDP às necessidades e fluxos de trabalho específicos de seus desenvolvedores, sem esperar por um fornecedor. A personalização é especialmente valiosa para organizações em setores altamente regulamentados com requisitos de conformidade rigorosos.
• Escalabilidade:As organizações que vivenciam um rápido crescimento descobrem que as opções fornecidas pelos fornecedores não conseguem acompanhar. As equipes internas da plataforma estão mais bem equipadas para dimensionar a plataforma junto com o negócio.
• Extensibilidade:As equipes de plataforma podem arquitetar seu IDP para facilitar a troca de seus componentes quando necessário. Essa flexibilidade pode ser extremamente valiosa à medida que a plataforma amadurece.
• Integração com sistemas legados:A maioria das empresas deve construir pelo menos alguns dos seus PDI para garantir a integração total com as tecnologias internas existentes. Como explica o vice-presidente de capacitação de engenharia da CVS Health, Jim Beyers: “…quando você atinge uma certa escala, não sei se há coisas por aí que se encaixem… provavelmente teremos que construí-la nós mesmos.”

Resumindo, a construção personalizada de um IDP oferece controle e compatibilidade incomparáveis ​​com sistemas existentes para organizações com necessidades específicas, requisitos de conformidade rígidos ou hipercrescimento. A experiência da CVS Health enfatiza que as soluções PaaS não fazem sentido em um determinado tamanho.

Contras da construção

Construir um PDI não é isento de desafios. Se você acompanha a conversa sobre engenharia de plataforma há algum tempo, provavelmente já ouviu histórias de guerra de organizações que rapidamente se envolveram na construção de sua plataforma. As organizações que adotam esta abordagem devem considerar:

• Custos antecipados:Construir um PDI internamente requer tempo e muito dinheiro. As equipes de plataforma devem seguir uma abordagem de plataforma como produto para ajudar as partes interessadas relevantes a compreender o investimento necessário. Sem uma adesão sustentada, as iniciativas de plataforma podem ser abandonadas antes de se concretizarem.
• Manutenção: À medida que a plataforma se expande, aumenta também a responsabilidade da equipe da plataforma de acompanhar novos padrões, atualizações tecnológicas e ferramentas. Em Estratégia de nuvem Na palestra PlatformCon 2022 do autor Gregor Hohpe, ele explica como as equipes de plataforma podem entender e comunicar quanto da plataforma planejam manter:

“O que você fará com sua plataforma quando a plataforma base crescer? … Você pode deixar a sua plataforma igual porque você investiu todo esse dinheiro, e a gente chama isso de plataforma que afunda conforme o nível da água sobe, né; pode ser justificado pelo investimento, mas você está duplicando coisas que agora estão disponíveis na plataforma base. …Ou você constrói uma ‘plataforma flutuante’ onde, quando a plataforma base ganha os recursos que você construiu, você diz ‘Oh, perfeito! Não preciso mais dessa parte. Posso deixar a plataforma base cuidar disso e posso inovar ainda mais.’”

Fonte: “The Magic of Platforms” de Gregor Hohpe entregue na PlatformCon 2022

• Perigos de copiar outros deslocados internos:Copiar os deslocados internos do Google, Netflix ou Amazon é uma receita para o fracasso. Há mais exemplos e recursos de engenharia de plataforma do que nunca, mas as equipes de plataforma ainda precisam entender as necessidades exclusivas de sua organização.

A melhor maneira de mitigar esses desafios é seguir uma abordagem de plataforma como produto: conduzir pesquisas de usuário, criar um roteiro de produto, solicitar feedback do usuário, iterar e melhorar continuamente e obter a adesão interna de todas as partes interessadas. Essa abordagem não apenas ajudará sua equipe de plataforma a evitar armadilhas comuns, mas também ajudará você a construir uma plataforma que os desenvolvedores realmente desejam usar.

Comprar uma plataforma como serviço: prós e contras

Prós de comprar

Algumas organizações não possuem o número de funcionários, os sistemas legados ou o rápido crescimento que exigem um PDI personalizado. Para essas organizações, uma PaaS pode ser um investimento mais sensato. Os benefícios da PaaS para essas organizações incluem:

• Carga de recursos reduzida:A compra de um PaaS alivia o trabalho pesado de desenvolvimento e manutenção de suas equipes internas. Comprar libera recursos internos valiosos, permitindo que eles se concentrem em problemas específicos da organização.
• Suporte ao fornecedor: Os provedores de PaaS têm interesse em manter sua plataforma competitiva. Os fornecedores podem dedicar mais recursos a melhorias contínuas, acréscimos de recursos, atualizações de segurança e suporte.
• Tempo de valorização mais rápido: O cronograma para implementar uma PaaS é muito mais curto do que construir um PDI do zero. Com uma PaaS, você pode desenvolver e colocar novos aplicativos em produção com muito mais rapidez.
• Segurança básica: A maioria das soluções PaaS oferece alguns recursos de segurança integrados e atualizados. Embora possam ser insuficientes para indústrias com requisitos de conformidade específicos, podem aliviar a carga das equipas internas em espaços menos regulamentados.
• Baixo custo inicial: A compra de uma PaaS acarreta um custo inicial mais previsível e muitas vezes mais baixo, tornando-a uma opção mais econômica para organizações menores.

Em suma, a PaaS capacita organizações menores com menos tecnologia legada a desbloquear o poder de um PDI sem o esforço e as despesas monumentais de construir do zero. Para aqueles sem necessidades específicas ou sistemas legados extensos que necessitam de uma plataforma personalizada, a PaaS oferece um caminho econômico e com suporte para melhorar a experiência do desenvolvedor.

Contras de comprar

Conforme mencionado anteriormente, o PaaS não é adequado para todos os tipos de organizações devido a algumas desvantagens significativas:

• Flexibilidade limitada:A PaaS pode ser muito teimosa ou rígida para configurações maduras. Como explica Camille Fournier: “Tende a ficar óbvio quando você precisa construir sua própria plataforma. Se você estiver usando o Heroku, você atingirá os limites de escala e verá as equipes se separarem e fazerem suas próprias coisas.”
• Potencial dependência do fornecedor: Os clientes de PaaS devem comprar com uma estratégia de saída em mente. Caso contrário, correm o risco de ficar presos às abordagens e fluxos de trabalho dos seus fornecedores.
• Incompatibilidade com sistemas legados: É improvável que uma PaaS seja totalmente compatível com sistemas legados extensos. As incompatibilidades causam sérios desafios de integração e segurança para empresas com extensa tecnologia legada.

Dadas estas limitações, as organizações que esperam superar o seu PaaS no curto prazo devem considerar a criação de um PDI. Caso contrário, você forçará seus desenvolvedores a seguirem os fluxos de trabalho e abordagens de um fornecedor apenas para alterá-los para algo diferente logo em seguida. Grandes mudanças frequentes na plataforma podem aumentar a carga cognitiva e piorar a experiência do desenvolvedor.

Construir e comprar?

A maioria das organizações constrói algumas partes do seu PDI e compra outras, aproveitando uma combinação de ferramentas de código aberto, comerciais e internas em sua plataforma. Essa abordagem de construir e comprar permite que eles aproveitem mais benefícios e, ao mesmo tempo, mitiguem as desvantagens.

No entanto, esta abordagem traz consigo os seus desafios. A paisagem da CNCF, ilustrada abaixo, é tão vasta quanto confusa. As equipes de plataforma geralmente precisam de ajuda para entender como escolher as ferramentas certas e a melhor forma de uni-las. No entanto, a comunidade de engenharia de plataforma fez um ótimo trabalho ao criar um cenário novo e aprimorado de ferramentas de plataforma.

Fonte: CNCF

Em geral, os especialistas em engenharia de plataformas recomendam evitar reinventar a roda sempre que possível. Abby Bangser do Syntasso escreve:

“Em geral, à medida que os componentes da plataforma se tornam mais uma mercadoria na indústria, torna-se mais provável que você deva adquirir uma solução para se beneficiar do investimento que outras organizações estão fazendo para manter seus produtos em um cenário competitivo”.

Este conselho se aplica tanto ao início quanto à continuação de sua jornada de engenharia de plataforma. Portanto, ao tomar sua decisão de construir ou comprar, é importante entender como sua plataforma pode evoluir e quais ferramentas sua organização pode utilizar ao longo do caminho.

Observe também que a abordagem construir e comprar ainda corre o risco de dependência do fornecedor e altas taxas de assinatura. Em teoria, os deslocados internos construídos e comprados são mais extensíveis, mas devem ser bem arquitectados para serem extensíveis na prática. O custo dos componentes da plataforma de terceiros pode aumentar rapidamente e tornar-se incontrolável se as equipes da plataforma não tomarem cuidado. As organizações devem fazer a devida diligência, seja comprando uma PaaS completa ou um componente de plataforma.

Principais considerações para construir ou comprar uma plataforma de desenvolvedor interna

Não existe uma resposta única para a questão de construir ou comprar um PDI. Ao considerar cuidadosamente os prós e os contras de cada abordagem e obter feedback dos usuários e de outras partes interessadas, você poderá tomar a melhor decisão para sua organização.

Os principais fatores a serem considerados ao decidir construir ou comprar seu PDI incluem:

• Configuração existente:Quanta tecnologia legada você precisará manter? Quais necessidades de integração sua equipe de plataforma deve estar atenta?
• Tamanho:Quantos desenvolvedores existem em sua organização? Espera-se que esse número cresça rapidamente?
• Metas de longo prazo:Como é o roteiro do seu produto? Quais soluções de terceiros podem apoiar a evolução da sua plataforma?

Mais importante ainda, nenhuma abordagem (construção, compra ou ambas) pode garantir o sucesso da sua plataforma. Há muito mais na engenharia de plataformas de som.

Para obter mais informações, confira este guia gratuito sobre como evoluir para uma empresa de plataforma.

O post Construir vs. Comprar: O Guia do Engenheiro de Plataforma apareceu pela primeira vez no The New Stack.