Em minhas consultorias, quando questionado sobre escalabilidade, recorro sempre ao scale cube, compartilhado no excelente livro “The Art of Scalability”, como abstração para indicar as opções disponíveis.
A proposta é pensar alternativas para escalabilidade em três dimensões. Cada eixo, representando uma estratégia distinta, porém não exclusiva as demais.
- Eixo X – Rodar múltiplas instâncias de um mesmo serviço, acessadas via balanceador de carga. Costumamos chamar aplicações que escalam dessa forma como “escaláveis na horizontal”, dado que o suporte a mais demanda é resolvido com a adição de mais unidades de computação (um outro servidor).
- Eixo Z – Assim como ocorre no Eixo X, temos múltiplas instâncias de servidor, rodando exatamente o mesmo código. A grande diferença é que cada servidor trata apenas uma parcela dos dados. No lugar de um balanceador de carga, temos um Router identificando a demanda de cada requisição e encaminhando para o servidor responsável. Nesta dimensão, estamos falando sobre sharding.
- Eixo Y – Diferentemente dos eixos X e Z, que rodam múltiplas instâncias idênticas da aplicação, a estratégia para o eixo Y é decompor a aplicação em diferentes serviços. Cada serviço, responsável por uma ou mais atividades relacionadas. Esta é a estratégia mais próxima da arquitetura baseada em microsserviços.
As três abordagens são extremamente poderosas e não excludentes. Podemos ter réplicas (Eixo X) tratando de um mesmo pedaço de dados (Eixo Z), por exemplo. A forma de pensar a escala será parte da definição arquitetural.
Se tiver interesse em entender mais sobre microsserviços, recomendo que acesse o Guia de Conteúdo para Microsserviços deste site.
Capa: Vladimir Kudinov
