Search for a command to run...
No comments yet. Be the first to comment.
Do zero ao "Não to mais tão perdido"
Back To Stage blog
2 posts
Uma das temáticas que tem ganhado cada vez mais força é a tal da experiência do desenvolvedor, ou Developer Experience (para os mais chegados no inglês).
Dentre muitas dos assuntos que podemos falar sobre esse tema, um que tem ganhado cada vez mais destaque é o Internal Developer Portal (IDP), ou portal do desenvolvedor interno.
Se eu fosse resumir do que se trata um IDP, eu diria que é uma ferramenta interna usada para abstrair complexidades de operação (seja de infraestrutura, tooling, ou padronização) permitindo que o desenvolvimento seja mais focado no negócio em si.
Não se preocupe se isso não ficou tão claro, ao longo do artigo nós vamos explorar melhor essa definição.
I'm convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them.
Mas porque diabos eu to falando dessa IDP num texto sobre o Backstage?
Eu vou deixar esse vídeo oficial porque ele é bonito demais e merece ser visto (infelizmente ele é apenas em inglês):
Se você acessar o site oficial, vai encontrar logo de cara: (tradução livre) “Uma plataforma aberta para a construção de portais de desenvolvedores”.
Agora as coisas começaram a se conectar, certo? Nós podemos usar o Backstage para construir nosso IDP!
Mas para a gente começar a fazer isso, precisamos primeiro entender suas principais funcionalidades (e quais problemas elas resolvem)
Uma das primeiras coisas que começam a acontecer em uma empresa conforme ela vai crescendo é o surgimento da tal “planilha de donos”, que diz qual time é responsável por qual serviço, quem faz parte do time, quem você pode procurar para tirar dúvidas.
No começo é muito legal, mas com o tempo a manutenção dela começa a ficar inviável. Novos serviços não aparecem por lá, antigos donos não atualizam informações, pessoas responsáveis deixam a empresa e o nome continua lá.
Uma das coisas que o Backstage ataca é esse problema, com uma funcionalidade chamada Software Catalog, o famoso Catálogo de Serviços.
O catálogo é o coração das funcionalidades que o Backstage entrega, ele reúne diversas informações e relaciona isso de maneira a entregar para o usuário uma maneira fácil e simples de achar quem é o dono.
Visão do Catalogo de Serviços em https://demo.backstage.io/
O catálogo pode ser alimentado (o que a gente chama de ingestão) com dados de diversas fontes: Github, Gitlab, Okta, Azure, LDAP e por aí vai. Existem muitas integrações prontas já, mas mesmo quando você não encontrar o que precisa, adicionar um novo mecanismo de ingestão é bem simples (no futuro eu posso fazer um texto fazendo algo do tipo).
Você faz um estudo de solução e chega a conclusão: Precisamos de um novo serviço em produção. Mas por onde começar? E mesmo que você tenha essa resposta, como garantir segurança, observabilidade, que ele segue os padrões da área de engenharia,e que ao final disso tudo ainda vai ser adicionado no Backstage com as informações necessárias para identificar os donos dele?
Uma das funcionalidades que o Backstage tem é chamada de Software Templates.
A ideia é simples: você tem um template, define parâmetros de entrada, os passos e o Backstage cria o novo serviço para você.
Spotify tem um conceito chamado “Golden Path” que tira muito valor disso: o melhor caminho para uma determinada tarefa.
Pensa aí na sua empresa: existe uma linguagem dominante (Java, Ruby, JavaScript, Go ou qualquer outra), existem algumas ferramentas padrões (docker, maven, yarn), bibliotecas internas e externas (log, trace, autenticação) e uma série de boas práticas que precisam ser feitas toda as vezes, normalmente conhecido como Boilerplate.
Agora imagina um mundo onde você só diz o nome do serviço e ganha tudo pronto, rodando até em produção em poucos minutos. Esse é o objetivo aqui, o software template te permite criar templates de acordo com a necessidade da sua empresa.
Você criou seu serviço, escreveu uma documentação explicando a arquiteta, como rodar, colocou informações relevantes da Stack, uma seção de problemas, tudo maravilhoso.
Mas as pessoas ficam o tempo todo te mandando mensagem perguntando as mesmas coisas que estão na doc.
Depois de perguntar se elas olharam na documentação, você recebe a seguinte indagação: “Mas que documentação? Onde está isso?”
Você mostrou o lugar e todos felizes. Meses depois você volta na doc para rodar seu serviço localmente, mas não funciona.
A maneira como o serviço funcionava mudou, mas ninguém atualizou a documentação.
Você sabe que agora é a hora que eu falo do Backstage, a funcionalidade que ele tem se chama TechDocs.
A ideia é simples: mantenha a documentação relevante para o serviço perto dele.
Através de arquivos Markdown, você mantém os documentos no mesmo repositório e garante que isso vá ser atualizado junto com alterações que impactam a documentação. Além disso, ele permite que na página do serviço seja exibido um website renderizado a partir desses arquivos tornando ainda mais fácil as pessoas encontrarem essa informação junto ao serviço.
Visão da da aba de documentação em https://demo.backstage.io/
Vou inclusive deixar um vídeo da Kubecon onde o time do Spotify fala mais sobre essa ideia, ele é bem curtinho e vale a pena:
Você colocou o Backstage no ar, mas tem um problema: como as pessoas encontram as coisas?
Como achar o serviço, a documentação, o template, ou até mesmo aquela informação que não está no Backstage mas em um sistema diferente.
Encontrabilidade é um fator chave para o sucesso de uma iniciativa de produtividade. Não adianta sua ferramenta ser a melhor, se ninguém achar nada nela.
O Backstage resolve isso com o Search. Imagine você ter o Google para procurar coisas na sua empresa. Essa é ideia aqui, você tem recursos para indexar diferentes fontes de informação e permitir uma busca centralizada no Backstage.
Além disso, ele fornece indexadores para o seu catálogo, então fica fácil achar a informação que já está ali dentro.
Até aqui você percebe que tem muita coisa legal no Backstage. Mas e se eu te disser que tem mais?
Uma das coisas que torna o Backstage uma ferramenta tão poderosa é seu sistema de plugins.
Com uma interface clara e bem definida, ele permite que você adicione funcionalidades apenas instalando novos plugins.
Quer exibir os PRs do Github? Tem plugin
Os builds do CircleCI? Tem plugin
Bitbucket? Todo list? Verificações de qualidade?
Tem plugin para isso e muito mais.
E se você não achar o plugin, é bem simples desenvolver um! Com um pouco de conhecimento de express e/ou react você consegue criar novas funcionalidades (nos plugins para o front-end você usa react e nos plugins para backend você usa express).
Além disso, a comunidade é extremamente receptiva. Tem uma documentação legal (e melhorando), Github muito ativo e até uma central de aprendizado
Essa resposta depende da maturidade da sua empresa. A developer experience tem cada vez mais se tornado essencial para que o valor do negócio possa emergir do time de desenvolvimento mais rápido, com maior qualidade e segurança.
O Backstage é uma ferramenta que, sem dúvidas, pode te ajudar nisso. Se sua empresa ainda não tem um time dedicado para isso, recomendo dar uma olhada no Roadie, uma solução SaaS do Backstage que pode te ajudar a reduzir custos de manutenção (e acelerar seu início, pois em apenas alguns minutos você consegue tudo rodando sem maiores dificuldades).
Aqui na RD Station (onde eu atualmente trabalho) o Backstage já é uma realidade para nosso time de engenharia. Nosso catálogo está 100% mapeado, e nosso time faz uso dos templates tanto para criar novos serviços Rails, quanto Micro Frontends.
Claro, ainda temos um longo caminho a evoluir (como time e com a ferramenta), além de dificuldades ainda não solucionadas (não é trivial garantir que o catálogo não fique desatualizado com a realidade da empresa por exemplo).
Mesmo assim, nós já vimos a engenharia sair de quase dois meses para criar um novo serviço para menos de uma semana. E só vamos parar quando levar menos de cinco minutos.
Existem outras ferramentas no mercado de IDP, e o seu cenário pode te fazer optar por diferentes escolhas, mas em termos de flexibilidade nenhuma delas vai te oferecer o que o Backstage oferece. Em contrapartida, você pode se ver obrigado a construir coisas internamente para se adequar ao seu caso de uso.
Como tudo em engenharia, são escolhas.
Me conta, o que você quer saber mais do Backstage?
Referencias:
How we are improving developer experience at QuintoAndar with backstage.io | by Gabriel Dantas
Tech Talks — Como desenvolvemos o developer portal usando o Backstage.io
I spent two years trying to do what Backstage does for free — Stack Overflow Blog
