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.