Na Sportradar, conduzimos regularmente workshops de experiência do desenvolvedor, em que pedimos que nossa comunidade interna de engenheiros fale sobre suas experiências e desafios. Isso é útil em vários aspecto, e esses workshops sempre me deixam cheio de ideias sobre como podemos estender nossos suporte para os desenvolvedores. Uma das maneiras que fizemos isso foi introduzindo uma abordagem coesiva à engenharia de plataforma, permitindo que as equipes de desenvolvimento se tornassem autossuficientes e multifuncionais.
Como uma empresa líder de tecnologia esportiva, a Sportradar continua criando produtos e serviços de ponta para fãs de esportes e federações no mundo inteiro. Nossa abordagem de juntar tecnologia e observabilidade modernas com um conjunto de princípios de engenharia com foco no produto continua a impulsionar nossas equipes de desenvolvimento para frente e entregar resultados positivos para nossos clientes.
Acredito que um elemento essencial da engenharia de plataforma é ouvir o que seus clientes e sua comunidade precisam ou querem e atender isso. E para nossas equipes na prática de DevOps e na plataforma centralizada, nossos clientes são desenvolvedores da Sportradar.
Empregamos a engenharia de plataforma de quatro maneiras na Sportradar.
1. Reestruture as equipes para a autossuficiência
Na Sportradar, nos baseamos no modelo da Spotify, que conta com que cada time, incluindo DevOps, tenha a experiência necessária para criar recursos e aplicativos para a sua base de usuários finais. Começamos o nosso próprio processo de reorganização "Spotify" em meados de 2019, e agora está totalmente atualizado. Como muitas empresas, uma maneira que a Sportradar cresce é por meio de aquisição, então há sempre um período de transição conforme adquirimos novas empresas e ajudamos a alinhar as pessoas com nosso modelo. Em nosso modelo "Spotify", as equipes de plataforma têm uma função central, enquanto especialistas de DevOps integram os times.
Embora os times estejam atingindo metas e gerando benefícios para toda a empresa, alguns desafios surgiram. Cada equipe tem seu próprio conjunto de objetivos e princípios que guiam a tomada de decisões, então contar com recursos comuns para algo como usar o Kubernetes ou configurar o monitoramento da observabilidade pode gerar dificuldades.
Para acabar com isso, criamos um novo grupo de ativação de engenharia para dar suporte ao uso das práticas recomendadas em cada equipe, o que alinha DevOps e engenheiros de plataforma em torno de princípios e objetivos comuns, além de difundir abordagens e ferramentas centralizadas. Nessa equipe recém-formada, miramos os grandes desafios de engenharia e, então, produzimos frameworks e ferramentas para lidar com eles. Também trabalhamos duro para garantir que haja um alinhamento total entre DevOps nos times e na equipe de plataforma principal.
2. Use vias pavimentadas para tarefas de desenvolvimento comuns
O grupo de ativação de engenharia usa a abordagem de vias pavimentadas para acelerar novos projetos e reduzir atritos de desenvolvimento. Outras empresas podem chamar isso de padrões ou caminhos clássicos, mas como quer que você chame, isso significa que os engenheiros vão chegar aos resultados com muito mais rapidez.
Quando desenvolvedores criam aplicativos, querem que sejam eficientes, encantem os clientes e gerem receita. Se você sai da via pavimentada, ainda pode chegar a esses resultados, mas vai demorar um pouco mais. Na via pavimentada, você remove grande parte da complexidade. É aí que entra a união da ativação de engenharia, da plataforma centralizada e das equipes de DevOps. As funções centrais definem os serviços gerenciados necessários para dar suporte aos desenvolvedores adotarem a abordagem das vias pavimentadas, compartilhando um stack comum que apoia a observabilidade, decisões dobre o ciclo de vida do desenvolvimento de software, pipelines de CI/CD e outros frameworks e soluções.
3. Crie um conjunto principal de métricas comuns
Em vias pavimentadas, a função de observabilidade da New Relic torna-se mais disponível e padronizada em toda a organização. Todos os times medem três métricas principais: disponibilidade, confiabilidade e desempenho. Ao iniciar um novo projeto, os desenvolvedores pegam um stack de vias pavimentadas, incluindo a New Relic e aplicativos da New Relic criados especificamente, a fim de introduzir essas métricas principais, permitindo que os desenvolvedores partam para a escrita do código do aplicativo, em vez de ficar construindo e gerenciando uma plataforma de aplicativo.
No fim das contas, a New Relic está removendo a complexidade: por ser um serviço gerenciado, os desenvolvedores não têm que ficar cuidando de servidores. A complexidade é baixa porque, com a instrumentação automática, os desenvolvedores podem colocar o agente nos aplicativos. Também podemos usar alguns dos outros frameworks existentes em um modelo de vias pavimentadas para testar sinteticamente os aplicativos em um ambiente que não é de produção. As métricas comuns em um modelo de vias pavimentadas ajudam você a reunir tudo isso, e o tempo de comercialização é significativamente reduzido.
4. Publique um catálogo de serviços gerenciados
Um portal para desenvolvedores interno fornece um indicador de desempenho de todos os nossos aplicativos e serviços. Um catálogo de serviços é usado para inicializar o projeto e para adicionar o serviço ao portal para desenvolvedores. Os desenvolvedores do time selecionam o que querem, e o catálogo fornece um stack opinativo com todos os componentes do aplicativo ou serviço que desejam criar. Isso garante que os desenvolvedores possam focar-se no que é importante para eles: criar ótimos aplicativos. A equipe de plataforma fornece todas as soluções de hospedagem gerenciada e os serviços principais, ou seja, resolução, rede e o que mais for necessário. A equipe centralizada de DevOps fornece as capacidades de observabilidade e pipeline automatizado. O modelo dessa via pavimentada é inicializado e o desenvolvedor pode focar apenas as complexidades dos aplicativos, e não necessariamente no ecossistema em torno disso.
Também temos um responsável pelo produto no grupo de ativação de engenharia, cujo trabalho é olhar especificamente para todas as funções de DevOps e toda a plataforma, a fim de garantir que os produtos que estamos criando fazem sentido e que essas implementações de vias pavimentadas formam um conjunto coerente e atendem efetivamente às necessidades dos desenvolvedores.
As opiniões expressas neste blog são de responsabilidade do autor e não refletem necessariamente as opiniões da New Relic. Todas as soluções oferecidas pelo autor são específicas do ambiente e não fazem parte das soluções comerciais ou do suporte oferecido pela New Relic. Junte-se a nós exclusivamente no Explorers Hub ( discuss.newrelic.com ) para perguntas e suporte relacionados a esta postagem do blog. Este blog pode conter links para conteúdo de sites de terceiros. Ao fornecer esses links, a New Relic não adota, garante, aprova ou endossa as informações, visualizações ou produtos disponíveis em tais sites.
