BT

Início Notícias De microservices para monólitos - Por que a Segment retrocedeu

De microservices para monólitos - Por que a Segment retrocedeu

Favoritos

Embora quase todas as equipes de engenharia de software tenham pensado em mudar a arquitetura para microservices em algum momento, as vantagens só aparecem em conjunto com pesadas desvantagens. Na QCon London, Alexandra Noonan contou como a Segment dividiu seu monólito em microservices e, alguns anos depois, voltou atrás para uma arquitetura monolítica. Nas palavras de Noonan, "Se os microservices forem implementados de maneira incorreta ou usados ​​como um band-aid sem abordar algumas das principais falhas sistemáticas da arquitetura, não poderemos desenvolver novos produtos pois iremos nos afogar na complexidade".

Os microservices foram introduzidos pela primeira vez para tratar o problema de isolamento de falhas limitado do monólito da Segment. Porém, à medida que a empresa se tornou mais bem-sucedida e se integrou a mais serviços externos, a sobrecarga operacional para suportar esta arquitetura ficou insustentável. A decisão de voltar ao monólito veio com uma nova arquitetura que considerou os pontos problemáticos do dimensionamento relacionados ao crescimento da empresa. Ao fazer sacrifícios em prol da modularidade, isolamento de ambiente e visibilidade, o monólito abordou a principal questão de sobrecarga operacional e permitiu à equipe de engenharia voltar o desenvolvimento de novos recursos.

Noonan explicou vários pontos-chave na evolução da arquitetura da Segment. Os problemas enfrentados e as decisões tomadas na época pareciam familiares a qualquer engenheiro de software experiente. Somente com a vantagem da retrospectiva ficou claro quais decisões poderiam ter sido melhores. Noonan explicou os pontos principais de decisão em uma linha do tempo e anotou os prós e contras de cada estado da arquitetura do sistema.

Em 2013, a Segment começou com uma arquitetura monolítica. Isso proporcionou uma sobrecarga operacional baixa, mas sem qualquer tipo de isolamento de ambiente. A funcionalidade da Segment é baseada na integração de dados de vários fornecedores. No monólito, os problemas na conexão com o destino do provedor podem ter um efeito adverso em todos os demais destinos no sistema como um todo.

A falta de isolamento dentro do monólito foi resolvida com a mudança para microservices, com um serviço trabalhando para um destino. Os microservices também aprimoraram a modularidade e a visibilidade de todo o sistema, permitindo que a equipe observasse facilmente os comprimentos das filas e identificasse os serviços problemáticos. Noonan apontou que a visibilidade pode ser incorporada a um monólito, mas a empresa obteve isso gratuitamente com os microservices. No entanto, eles vieram com maior sobrecarga operacional e problemas com a reutilização do código.

Um período de hiper-crescimento no segmento, por volta de 2016-2017, adicionou mais de 50 novos destinos, algo em torno de três novos destinos por mês. Ter um repositório de código para cada serviço era gerenciável para um punhado de destinos, mas tornou-se um problema à medida que a escala começou a aumentar. Bibliotecas compartilhadas foram criadas para fornecer um comportamento semelhante a todos os trabalhadores. No entanto, isso criou um novo gargalo, onde as alterações no código compartilhado poderiam exigir uma semana de esforço do desenvolvedor, principalmente devido a restrições de teste. A criação de versões das bibliotecas compartilhadas tornou as alterações do código mais rápidas de serem implementadas, mas reverteu o benefício que o código compartilhado pretendia fornecer.

Noonan apontou as limitações de uma abordagem única para os microservices. Como havia muito esforço só para adicionar novos serviços, as implementações não foram personalizadas. Uma regra de dimensionamento automático foi aplicada a todos os serviços, apesar de cada um ter necessidades de recursos de CPU e carga muito diferentes. Além disso, uma solução adequada para o verdadeiro isolamento de falhas seria um microservice por fila por cliente, mas isso exigiria mais de 10.000 microservices.

A decisão de 2017 de voltar ao monólito considerou todas as vantagens e desvantagens, incluindo a sensação de perder os benefícios do microservice. A arquitetura resultante, denominada Centrifuge, é capaz de lidar com bilhões de mensagens por dia enviadas para dezenas de APIs públicas. Agora existe um repositório de código único e todos os trabalhadores de destino usam a mesma versão da biblioteca compartilhada. O maior trabalho é mais capaz de lidar com os picos de carga. Adicionar novos destinos não adiciona mais despesas operacionais, e as implantações levam apenas alguns minutos. O maior benefício vem para os negócios, onde foram capazes de começar voltar a criar novos produtos. A equipe sentiu que todos esses benefícios compensavam a modularidade reduzida, a falta de isolamento de ambiente e a diminuição da visibilidade fornecidos gratuitamente com os microservices.

Os participantes da QCon estavam discutindo a apresentação como se fossem engenheiros ingressando em um projeto que possuía uma longa história. Comentários rápidos como, "obviamente não devemos fazer o que eles fizeram", foram rebatidos com as vozes da experiência, indicando que a maioria das decisões são tomadas com base nas melhores informações disponíveis naquele momento. Uma das principais conclusões foi que gastar alguns dias ou semanas para fazer mais análises poderia evitar uma situação que levaria anos para ser corrigida.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

  • Falha no desenho da arquitetura

    by Fabio V Soares /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Pelas informações que foram dadas, houve uma falha no desenho da arquitetura. Em vez de criarem uma esteira comum a todos os clientes, e parametrizável para atender workloads diferentes e/ou regras personalizadas, acabaram criando microserviços não reutilizáveis, que criou milhares de branches impossíveis de gerenciar.

  • Nem todo problema é um prego e nem toda a solução é um martelo mas...

    by Daniel Amaral /

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    De acordo com o cenário exposto houveram gaps de arquitetura e de governança também.

    Além disso será que a empresa lidou com o alto volume de demandas da melhor forma?

    Não acredito em balas de prata mas problemas relacionados a gestão de demandas, arquitetura e governança podem detonar qlq projeto, indiferente a abordagem tecnológica utilizada.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.