Categoria: Arquitetura de software

O cubo da escalabilidade AFK é um modelo tridimensional que representa diferentes estratégias de escalabilidade de sistemas. Ele é composto por três eixos (X, Y e Z), cada um correspondendo a uma abordagem distinta para escalar aplicações, bancos de dados e até organizações.

Ele foi criado por Abbott, Fisher e Kimbrel, daí a sigla AFK, e foi introduzido no livro “The Art of Scalability”.

O ponto de origem do cubo, definido por x = 0, y = 0, z = 0, representa um sistema monolito ou uma organização composta por uma única pessoa que realiza todas as tarefas, sem qualquer especialização ou divisão com base na função, no cliente ou no tipo de solicitação. À medida que se move ao longo de qualquer um dos eixos, X, Y ou Z, o sistema se torna mais escalável por meio de diferentes estratégias, como a separação por funcionalidades, segmentação por tipo de cliente ou usuário, e replicação para distribuição de carga.

A imagem a seguir apresenta o cubo específico para aplicações.

Eixo X

Representa uma forma de escalar sistemas clonando a aplicação. Isso significa criar várias cópias idênticas do mesmo sistema e distribuir as requisições entre elas. Essa distribuição é feita por um balanceador de carga (load balancer), que envia os pedidos dos usuários para uma das instâncias disponíveis.

Esse tipo de escalabilidade é muito comum e fácil de entender. Ele funciona bem para lidar com o aumento do número de acessos, melhorando a capacidade (mais usuários ao mesmo tempo) e a disponibilidade (mais chances de continuar funcionando se uma instância falhar). Além disso, é uma solução de baixo custo e simples de aplicar, já que basta copiar o sistema que já existe.

No entanto, o eixo X tem limitações. Como todas as instâncias são iguais, se o sistema for muito grande ou tiver muitos dados, ele pode ficar lento. Isso porque, mesmo com mais cópias, o sistema ainda é um monolito, e esse tipo de estrutura não lida bem com crescimentos muito complexos.

Eixo Y

Trata da divisão da aplicação por funcionalidades. Isso significa separar o sistema em partes menores, chamadas de serviços, onde cada um cuida de uma função específica, como gerenciamento de pedidos ou de clientes.

Essa divisão ajuda a resolver problemas que surgem quando a aplicação cresce e fica mais complexa. Com essa separação, cada serviço pode funcionar de forma independente, o que melhora o desempenho, facilita a manutenção e evita que falhas em uma parte do sistema afetem as outras.

Apesar de ser mais cara que outras formas de escalabilidade, como duplicar servidores (eixo X), a escalabilidade pelo eixo Y é muito eficaz para organizar o código e permitir que ele cresça de forma sustentável.

Essa abordagem é a base da arquitetura de microsserviços, onde a aplicação é formada por vários serviços pequenos e especializados. Cada um desses serviços pode ser escalado separadamente, conforme a necessidade.

Eixo Z

Trata da separação do trabalho com base em atributos dos pedidos, como o cliente ou o usuário que está fazendo a requisição. Ou seja, em vez de cada instância da aplicação cuidar de todos os dados, cada uma cuida apenas de uma parte, como um grupo específico de usuários.

Essa abordagem ajuda a escalar o sistema quando há crescimento no número de clientes, transações ou volume de dados. Cada instância da aplicação fica responsável por uma “fatia” dos dados, o que reduz o tempo de processamento e melhora o desempenho geral.

Embora o software não precise ser dividido em vários serviços como no eixo Y, ele precisa ser escrito de forma que permita essa separação, o que pode aumentar o custo e a complexidade da implementação.

Em resumo, a escalabilidade pelo eixo Z é ideal para lidar com grandes volumes de dados e usuários, dividindo a carga de forma inteligente entre diferentes instâncias da aplicação.

Combinando os três eixos, o cubo da escalabilidade AFK oferece uma visão completa e prática de como evoluir sistemas conforme crescem em uso, dados e complexidade. Cada eixo resolve diferentes tipos de desafios: o X melhora capacidade e disponibilidade com cópias idênticas; o Y reduz a complexidade por meio da divisão funcional; e o Z permite lidar com grandes volumes de dados e usuários por meio da segmentação. Juntos, esses eixos ajudam arquitetos e desenvolvedores a escolher as melhores estratégias de escalabilidade de acordo com as necessidades do sistema, promovendo soluções mais eficientes, resilientes e preparadas para o crescimento.

Referências:

ABBOTT, Martin L.; FISHER, Michael T.. The Art of Scalability: scalable web architecture, processes, and organizations for the modern enterprise. Boston: Addison-Wesley, 2010.

RICHARDSON, Chris. Microservices Patterns. Shelter Island: Manning, 2019.

Os microsserviços são um padrão de arquitetura de software no qual o sistema é dividido em vários serviços pequenos e independentes que se comunicam entre si. Cada serviço funciona como uma unidade modular isolada, com barreiras bem definidas. Em vez de acessarem diretamente funções ou pacotes uns dos outros, os serviços interagem exclusivamente por meio de APIs. Isso promove um baixo acoplamento entre os componentes do sistema.

Essa abordagem é especialmente útil no desenvolvimento de sistemas grandes e complexos. À medida que o sistema cresce, torna-se cada vez mais difícil mantê-lo como o monolito (conforme discutido em Monolito: um começo inteligente, não um erro), além de ser mais complicado para uma única pessoa compreendê-lo por completo.

Os principais benefícios dos microsserviços são:

Cada serviço é pequeno e fácil de manter (não é à toa o prefixo “Micro”)

Cada serviço deve ser pequeno, o que facilita sua manutenção e evolução ao longo do tempo. Por conta do tamanho reduzido, o código torna-se mais simples de entender, tanto em relação ao que o serviço deve fazer quanto à forma como ele realiza suas tarefas. Esse fator também impacta positivamente o desempenho da aplicação, pois serviços menores tendem a ser desenvolvidos e executados mais rapidamente, o que, por sua vez, contribui para o aumento da produtividade das equipes de desenvolvimento.

Serviços são independentes

Cada serviço pode ser entregue e escalado de forma independente, sem depender diretamente de outros serviços. Isso acelera a entrega de soluções ao mercado e aos clientes, reduz o tempo de resposta para corrigir bugs que afetam o usuário e aumenta a satisfação do cliente ao permitir entregas constantes de valor.

Além disso, cada equipe dentro da empresa pode ser responsável por um ou mais serviços específicos, o que facilita a autonomia dos times. Assim, cada equipe consegue desenvolver, implantar e escalar seus serviços sem depender do andamento dos demais times, promovendo agilidade e especialização.

Ponto de atenção

Quando é necessário implantar soluções que envolvem múltiplos serviços, é fundamental que essa implantação seja cuidadosamente coordenada entre os times. Isso evita que alterações em um serviço causem falhas em outro. É necessário criar um plano de implementação que respeite as dependências entre os serviços, definindo uma ordem lógica de implantação. Essa abordagem contrasta com o monolito, na qual é possível atualizar vários componentes de forma conjunta e atomizada.

Isolamento de falhas

A independência de cada serviço garante o isolamento de falhas dentro do sistema. Por exemplo, se um erro crítico acontece no serviço A, o serviço B pode continuar operando normalmente. Esse isolamento evita que falhas se propaguem, aumentando a resiliência da aplicação como um todo. Em contraste com o monolito em que uma falha em um componente pode derrubar o sistema inteiro.


Permite experimentos e adoção de novas tecnologias

Como os serviços são pequenos e isolados, reescrevê-los utilizando novas linguagens ou tecnologias se torna uma tarefa viável e de baixo risco. Essa flexibilidade permite que equipes experimentem soluções mais modernas e eficientes. Caso a nova abordagem não traga os resultados esperados, o serviço pode ser descartado ou revertido sem comprometer o restante do sistema.

Mas nem tudo são flores…

No mundo da tecnologia, não existe uma bala de prata.

Como qualquer abordagem arquitetural, os microsserviços também apresentam desvantagens que devem ser cuidadosamente consideradas antes da adoção.

Definir cada serviço é custoso

Não existe uma metodologia universal e precisa para decompor um sistema em serviços. Essa tarefa exige conhecimento profundo do domínio do negócio e experiência em design de sistemas. Uma decomposição mal feita pode resultar em um monolito distribuído, que consiste em um conjunto de serviços fortemente acoplados que precisam ser implantados juntos. Esse cenário combina o pior dos dois mundos: a rigidez do monolito com a complexidade dos microsserviços, sem os reais benefícios de nenhum dos dois.

Sistemas distribuídos são complexos

Ao optar por microsserviços, os desenvolvedores precisam lidar com a complexidade natural de sistemas distribuídos. A comunicação entre serviços se dá por mecanismos de comunicação entre processos, como chamadas HTTP ou mensagens assíncronas, que são mais complexas do que simples chamadas de método dentro de uma aplicação monolítica. Além disso, os serviços devem ser preparados para lidar com falhas parciais, como indisponibilidade de outros serviços ou alta latência nas respostas.

Essa complexidade técnica exige que os times tenham habilidades mais avançadas em desenvolvimento, arquitetura e operações. Além disso, há uma carga operacional significativa: múltiplas instâncias de diferentes serviços precisam ser monitoradas, escaladas, atualizadas e gerenciadas em produção. Para que os microsserviços funcionem bem, é necessário investir em um alto grau de automação, incluindo integração contínua, entrega contínua, provisionamento de infraestrutura e observabilidade.

Decidir quando adotar microsserviços é desafiador

Outro desafio importante está relacionado ao momento certo de adotar a arquitetura de microsserviços. Em muitos casos, especialmente no início do desenvolvimento de um novo sistema, os problemas que os microsserviços resolvem ainda não existem. A escolha por uma arquitetura distribuída desde o início pode tornar o desenvolvimento mais lento e oneroso. Isso é particularmente crítico em startups, cujo foco inicial costuma ser validar o modelo de negócio e lançar rapidamente. Para essas situações, começar com um monolito pode ser a melhor decisão, com a possibilidade de migrar para microsserviços à medida que a aplicação cresce e a complexidade exige uma arquitetura mais escalável.

Como é possível perceber, a arquitetura de microsserviços oferece diversos benefícios, mas também impõe desafios técnicos, operacionais e organizacionais significativos. Por isso, sua adoção deve ser feita com cautela e alinhada às reais necessidades do projeto. No entanto, para aplicações complexas, como sistemas web ou soluções SaaS, os microsserviços frequentemente se mostram a escolha mais adequada, especialmente no longo prazo.

Referência: RICHARDSON, Chris. Microservices Patterns. Shelter Island: Manning, 2019.

Na arquitetura de software, o monolito é um estilo em que todas as camadas do sistema (como front-end, back-end, lógica de negócio e acesso a dados) estão agrupadas em um único arquivo executável ou componente de deploy.

Apesar de muitas vezes ser mal visto pela comunidade, esse modelo pode trazer diversos benefícios em aplicações pequenas ou em estágios iniciais do projeto, como:

• Desenvolvimento simplificado – IDEs e outras ferramentas de desenvolvimento funcionam muito bem com aplicações únicas, tornando o desenvolvimento mais ágil.
• Facilidade para mudanças radicais – Como todo o código está no mesmo lugar, é possível alterar APIs, regras de negócio e chamadas ao banco de forma centralizada e consistente.
• Testes facilitados – Testes de integração e end-to-end são mais diretos, pois é possível iniciar toda a aplicação, invocar APIs REST e testar as interfaces.
• Deploy direto – A publicação é simplificada, geralmente bastando copiar o artefato gerado da compilação para o servidor de aplicação.
• Escalabilidade simples – Basta executar múltiplas instâncias da aplicação e utilizar um balanceador de carga (load balancer) para distribuir as requisições.

No entanto, com o crescimento da aplicação, tarefas como desenvolvimento, testes, deploy e escalabilidade tendem a se tornar mais complexas. Essa complexidade, por sua vez, acaba desmotivando os desenvolvedores que precisam lidar com o sistema.

Corrigir bugs ou implementar novas funcionalidades passa a consumir muito tempo. Pior ainda, forma-se uma espiral negativa: o código difícil de entender leva a alterações mal feitas, o que só aumenta a complexidade e os riscos.

Outro problema comum em monolitos que crescem demais é o tempo necessário para realizar o deploy. Como todo o sistema está em uma única base de código, qualquer pequena alteração exige a publicação da aplicação inteira. Se algo der errado nesse processo, há o risco de toda a aplicação ficar indisponível.

Além disso, o monolito pode gerar mais duas complicações importantes. Mesmo sendo simples de escalar horizontalmente, não é possível escalar apenas partes específicas da aplicação, por exemplo, um módulo que recebe um tipo específico de requisição com alto volume. A escalabilidade é sempre feita de forma integral.

A obsolescência tecnológica também é uma preocupação. A linguagem de programação ou framework escolhidos no início do projeto tendem a permanecer até o fim da vida útil do sistema. Isso ocorre porque atualizar toda a base de código pode ser tão trabalhoso que, muitas vezes, é mais viável reescrever o sistema do zero do que atualizá-lo.

Em resumo, o monolito é uma boa escolha no início de um projeto pela sua simplicidade. Porém, com o crescimento da aplicação, surgem desafios que podem comprometer a escalabilidade, manutenção e agilidade. Nesses casos, pode ser necessário repensar a arquitetura para acompanhar a evolução do sistema.

Referência: RICHARDSON, Chris. Microservices Patterns. Shelter Island: Manning, 2019.

Um padrão é uma solução reutilizável para um problema que ocorre em um contexto específico.

A ideia surgiu dos projetos de arquitetura e engenharia do mundo real, que vão de grandes soluções, como distribuir o acesso à água em uma cidade, até menores, como definir a posição de uma janela em um quarto para garantir a melhor luminosidade durante o dia. Cada um desses soluciona um problema organizando os objetos físicos dentro de um escopo específico.

Essa abordagem se mostrou útil para a arquitetura de software. Desde os anos 90, desenvolvedores vêm documentando inúmeros padrões de projeto que resolvem problemas arquiteturais, definindo um conjunto de elementos do sistema de forma colaborativa.

Um dos motivos pelos quais os padrões são valiosos é que eles descrevem o contexto em que se aplicam. A ideia é que um padrão oferece uma solução para um contexto específico e pode não funcionar bem em outros contextos. Por exemplo, a solução que resolve o problema do alto número de requisições que o MercadoLivre recebe por dia talvez não seja a melhor para uma startup que está começando agora.

Além de exigir que o contexto do problema seja especificado, um padrão obriga a descrever outros aspectos críticos da solução, como as forças em conflito, as consequências da aplicação e os trade-offs envolvidos.

Um padrão de projeto inclui três características básicas:

• Forças: representam os fatores e interesses em conflito que precisam ser considerados ao resolver um problema dentro de um determinado contexto. Essas forças podem entrar em conflito, e é necessário definir quais têm prioridade (dependendo do contexto), pois pode ser impossível atender a todas. Por exemplo, ao projetar um sistema de login, é preciso equilibrar a usabilidade (permitir que o usuário acesse rapidamente) com a segurança (exigir autenticação forte), duas forças que podem entrar em conflito. Ou, de forma mais simples, o código deve ser tanto simples quanto performático, mas um sistema síncrono (mais simples) não é tão performático quanto um assíncrono, que é mais complexo.

• Resultado: descreve as consequências da aplicação do padrão, trazendo tanto os benefícios — ou seja, as forças que ele resolve — quanto as desvantagens, que incluem forças não resolvidas e problemas que podem surgir com a aplicação do padrão. Esse resultado fornece uma visão mais completa e equilibrada da solução, permitindo decisões arquiteturais melhores.

• Padrões relacionados: como o próprio nome indica, essa característica descreve as relações entre o padrão em questão e outros padrões. Existem cinco tipos principais de relações entre padrões.
  • Predecessor: é aquele que dá origem ou motiva a aplicação de outro padrão. Por exemplo, o padrão de Microsserviços é predecessor de outros padrões, como Service Discovery e API Gateway.
  • Sucessor: é aquele que resolve um problema introduzido pelo seu predecessor. Por exemplo, ao adotar o padrão de Microsserviços, surgem desafios como roteamento de requisições e gerenciamento de serviços — problemas que padrões como API Gateway e Service Discovery ajudam a resolver.
  • Alternativo: é aquele que oferece uma solução alternativa ao padrão escolhido. Por exemplo, o Monolito é uma alternativa aos Microsserviços; deve-se escolher um ou outro.
  • Generalização: é aquele que oferece uma solução mais ampla e genérica para um tipo de problema. Por exemplo, o padrão Cliente-Servidor é uma generalização de arquiteturas como Microsserviços ou Monolito, pois descreve a ideia básica de separar clientes e servidores, independentemente da complexidade da solução adotada.
  • Especialização: é aquele que representa uma forma mais específica de outro padrão mais geral — o oposto da generalização.

Além disso, é possível organizar padrões que tratam de questões em uma determinada área de problema em grupos.

Por exemplo, pode-se agrupar os padrões API Gateway e Service Discovery, pois ambos lidam com problemas típicos de sistemas distribuídos.

Compreender e organizar os padrões, suas características e relações permite construir soluções de software mais robustas e adaptáveis, ajudando desenvolvedores e arquitetos a tomar decisões conscientes que equilibram requisitos técnicos e de negócio.

Referência: RICHARDSON, Chris. Microservices Patterns. Shelter Island: Manning, 2019.