Princípios de Arquitetura – Escalabilidade

Bom dia a todos !

Recentemente estive envolvido em um projeto, onde escalabilidade era o tema do dia, este projeto precisava ter um design que conseguisse crescer e atender cada vez um número maior de requisições e ainda manter a desempenho dentro do aceitável. Não vou me delongar em falar do projeto, até mesmo que é confidencial, mas gostaria de compartilhar com vocês, uma reflexão sobre escalabilidade.

Bem, desde que a tecnologia da informação assumiu o seu papel na nossa sociedade, toda e quaisquer informações que geramos e trocamos, começaram a ganhar uma faceta digital (taxa de digitalização de informação). Se pensarmos que nós, seres humanos, somos geradores/consumidores de informação 24 horas por dia, então, vocês podem ter uma idéia abstrata de qual é a quantidade de informação que é gerada/consumida por dia em planeta de 6,7 bilhões de pessoas (acompanhe em tempo real em: https://www.worldometers.info/). Um estudo da Universidade de Berkeley na California fez um estudo sobre a quantidade de informação gerada pelo mundo, indica que no ano de 2003 uma pessoa gerou cerca de 800 MB de informação, isto multiplicado pela quantidade de pessoas mundo temos cerca de 6 Exabytes de dados (eu disse, Exabyte = 1 152 921 504 606 846 976 de bytes). São números realmente astrônomicos, isto no ano de 2003, uma época pré-Web 2.0, SOA.

E é neste ponto, que surge a pergunta “Como projetar soluções que possam lidar com cada vez com mais informação e manter o desempenho dentro de parâmetros aceitáveis?” , fundamentado nesta pergunta, surgiu o princípio de Arquitetura, a qual damos os nome de Escalabilidade. Se for para definir sobre escalabilidade (com devido respeito às definições amplamente divulgadas na internet), diríamos que é a capacidade que uma solução tem em absorver mais requisições (independente da definição do teremo) e ao mesmo tempo manter desempenho dentro de parâmetros definidos.

Para nos orientar nesta reflexão, a escalabilidade segue duas linhas-mestre:

• Escalabilidade horizontal:Consiste em adicionar mais máquinas (computadores reais/virtuais) ao desenho da sua solução de tal modo que possa distribuir as requisições entre elas.
• Escalabilidade vertical:Consiste em melhorar os componentes de hardware (memória, cpu) da atual solução.

Identificar o uso destas linhas dentro do desenho de uma solução é o trabalho de equilibrar o desempenho X crescimento, ao mesmo tempo que mantendo a transparência do consumo da solução pelo cliente/visitante/usuário. Vamos a um cenário simples, suponha que está se pensando em construir um site de comércio eletrônico para um cliente qualquer, quais os componentes preciso observar para definir uma arquitetura?

• As camadas lógicas (apresentação, regras de negócios e dados) estão relativamente desacopladas entre si?
• A modelagem de classes permite identificar classes consumidores de serviços e classes fornecedoras de serviços?
• Como foi pensado sobre a afinidade do visitante ao seu perfil de compras?
• Hospedarei em hardware próprio? Datacenter tercerizado? Ou plataformas de Cloud?
• Como foi definido o gerenciamento de conflitos quando 2 ou mais visitantes quiserem o mesmo produto ao mesmo tempo?

Veja que neste exemplo de cenário, foram levantadas tantas perguntas técnicas, como perguntas de requisitos, mas por quê? O motivo de que desenhar soluções com escalabilidade, consiste em equilibrar requisitos funcionais x requisitos técnicos. Um exemplo, é se você pensou construir sua aplicação somente com stored procedures, provavelmente terá dificuldade em escalar a camada lógica de acesso à dados. Ou, se você pensa em usar afinidade por sessão do ASP.Net por ter dificuldade em criar um Web farm.

Neste ponto, é que nos últimos anos surgiram várias plataformas de desenvolvimento na Web, por exemplo o Azure, através de sua estrutura de virtualização/provisionamento de servidores, um site de comércio eletrônico pode contratar uma capacidade ilimitada de plataforma e assim atender a mais requisições ao mesmo tempo. Para tanto, desenvolver nesta plataforma exige outros conhecimentos que vão além de simplesmente criar um site de comércio eletrônico em 3 camadas, outros mindsets de conhecimento são exigidos. Um post interessante é do Waldemir Cambiucci (Arquiteto na MS e companheiro de depto), sugiro a leitura: https://feeds.feedburner.com/~r/wcamb/~3/479264277/o-desenvolvimento-live-e-o-windows-azure-o-coment-rio-que-virou-post.aspx

Então, não existe solução ideal? Eu acredito que não, o que existe é identificar restrições, situações e procurar um equilíbrio adequado dentro da sua solução. Assim, no seu próximo projeto, procure:

• Identificar os serviços funcionais que o seu produto disponibilizará ao mundo (internet ou corporativo)
• Identificar como estes serviços são orquestrados internamente e quais as camadas (dados, regras de negócios, segurança, etc) se relacionam entre si.
• Identificar quais ofertas tecnológicas de fornecedores podem lhe auxiliar no melhor desenho da sua arquitetura
• Pensar fora da caixa, às vezes, nem tudo é resolvido simplesmente por banco de dados ou por código. A resposta pode estar em hardware, fornecedor ou em novos algoritmos.

Balancear os requisitos técnicos e funcionais, atendendo as demandas dos nossos clientes e procurando manter em mente, quais são as ofertas novas são os segredos para o sucesso de uma solução.

Referência:

Post Waldemir Cambiucci: https://feeds.feedburner.com/~r/wcamb/~3/479264277/o-desenvolvimento-live-e-o-windows-azure-o-coment-rio-que-virou-post.aspx

Azure: https://www.microsoft.com/azure/default.mspx

Estatísticas em tempo real: https://www.worldometers.info/

Estudo sobre a quantidade de informação gerada no mundo: https://www2.sims.berkeley.edu/research/projects/how-much-info-2003/

abs e obrigado !
Condé

versão 1.35

Comments

• Anonymous
  February 09, 2009
  Boa noite a todos ! Antes de escrever, gostaria de fazer uma correção, quando comecei a falar sobre estes