De microsites independentes a arquitetura orientada ao contexto
Como passamos de 12 repositórios separados para 6 microsites específicos de contexto, aprendendo com os desafios de engenharia excessivos, quatro anos atrás, no Subito.it, adotamos totalmente a abordagem microsite. Cada página ou pequeno grupo de páginas tinha seu próprio repositório, seu próprio pipeline de implantação e sua própria infraestrutura. Foi a era do artigo “Nossa arquitetura de microsite” publicada no blog de tecnologia da Adevinta, onde descrevemos orgulhosamente como “aceleraram a frequência dos lançamentos e a independência das equipes aplicando uma abordagem de microsite”. O que é um microsite? Um microsite é uma abordagem arquitetônica em que páginas individuais ou pequenos grupos de páginas relacionadas são desenvolvidas, implantadas e mantidas como aplicações completamente separadas. Cada microsite normalmente possui seu próprio: oleoduto de repositório e base de código CI/CD e infraestrutura de processos de implantação e pilha de tecnologia do ambiente de hospedagem (que pode diferir de outros microsites) a propriedade e a responsabilidade da equipe contrasta com os aplicativos monolíticos tradicionais, onde todas as páginas fazem parte de uma única base de código grande. Os microsites visam fornecer a autonomia máxima da equipe e a independência da implantação, permitindo que diferentes equipes trabalhem em diferentes partes de um site sem interferir entre si. Today, in 2025, we have an update on this architecture: we’ve found a better balance between agility and maintainability through continuous learning and optimization The Microsite Era: When Everything Seemed Perfect The microsite approach we had adopted seemed like the ideal solution for our problems: Lean pipelines: each microsite had a fast and independent deploy pipeline Team autonomy: each team could work on their own piece without interference Independent releases: no mutual blocking between teams Over time, however, we started noticing As primeiras questões: proliferação não controlada do repositório, o que havia começado como estratégia para páginas importantes também começaram a ser aplicadas a páginas secundárias. Distributed Technical Debt, with 12 repositories to maintain, some pages started falling behind in dependency updates and security patches Excessive Infrastructure Overhead, each microsite required: Monitoring configuration Alerting setup Pipeline maintenance CDN Configuration The New Strategy: Context-Driven Microsites Instead of going completely back to a monolith (which would have reintroduced the problem of overly long pipelines), we chose a middle path: context-specific microsites. Princípios do novo contexto de arquitetura primeiro: agrupamos páginas que compartilham o mesmo domínio de negócios Clear Propriedade: Cada microsite permanece de propriedade de um tamanho específico da equipe: grande o suficiente para justificar a infraestrutura, pequena o suficiente para permanecer manutenção de todas as novas páginas de arquitetura consolidam as páginas de autentação de conteúdo de conteúdo de conteúdo de conteúdo público e sero-refrente de conteúdo de conteúdo de conteúdo de conteúdo de conteúdo de conteúdo seo-renome Serviço de transação de inscrição: todo o serviço de opções pagas do ecossistema de transação: serviços pagos e opções de premium Serviço de gerenciamento de usuários: gerenciamento de área e perfil pessoal O processo de transição nossa migração segue uma abordagem estruturada com três fases principais: Fase 1: Preparação e configuração A fase inicial se concentra na preparação do alvo para receber a funcionalidade de alvo de alvo em relação ao alvo de alvo em migração: a configuração dos layouts e os componentes de alvo de alvo no alvo em migração. variables and configuration management Establish monitoring and alerting for the new consolidated service Phase 2: Quality Assurance and TestingBefore going live, we conduct comprehensive checks: Execute automated end-to-end (E2E) and manual tests Validate third-party integrations (eg, GTM) Verify page headers, caching policies, and security configurations Confirm monitoring and metrics collection are correctly implemented Phase 3: Production Migration and CleanupThe final phase involves the actual cutover and decommissioning of legacy systems: Gradual Rollout: Route traffic progressively from legacy to consolidated microsite Monitor performance and error rates during the transition Legacy Cleanup:Following our established Service End-of-Life procedures, we systematically decommission the old microsite: Destroy monitoring, alerts, and dashboards Archive repositories and remove deployment configurations Clean up infrastructure resources (Bancos de dados, funções de IAM, etc.) Atualize o roteamento e adiciona redirecionamentos quando necessário conclusões, nossa jornada de microsites para uma abordagem mais consolidada não foi uma falha na arquitetura microsite, mas uma maturação de nossa compreensão de quando e como aplicá -lo. What we learned: Architecture must evolve with business and team needs Not everything needs to be a microservice/microsite – like any architectural pattern, it has its trade-offs Context is fundamental – group by business context, not technical convenience Pages that belong to the same user flow should probably stay together Today, with our 6 context-driven microsites, we’ve found a balance that allows us to maintain team autonomy and deployment speed while significantly reducing maintenance overhead. O caminho para a arquitetura perfeita não existe, mas o caminho para a arquitetura sempre melhorada.
Fonte
