Se os elementos da arquitetura são projetados de forma a não manter estado (stateless), ou seja, que eles sejam capazes de realizar suas funções apenas com os parâmetros presentes nas requisições, fica mais fácil replicá-los para dividir a carga de requisições entre as réplicas. Basta apenas que seja definido uma balanceador de carga para distribuir as chamadas entre estes elementos. Note que se a demanda aumenta, pode-se também aumentar o número de elementos stateless para suprimir a demanda sem muito esforço. Basta então informar ao balanceador sobre os novos elementos para que ele os considere na distribuição de novas requisições.

É importante observar que nem todos os elementos arquiteturais podem ser stateless. Por exemplo, elementos de dados essencialmente mantêm estado (e, portanto, são stateful). Assim, é possível que, em algum ponto da arquitetura, os diversos elementos stateless precisem de dados ausentes nos parâmetros das requisições e portanto terão que fazer novas requisições aos elementos stateful. Se os elementos que mantêm estado não forem capazes de responder a eseta carga de novas requisições, eles se tornarão o gargalo da arquitetura, prejudicando o desempenho de todo o sistema.

Para melhorar o desempenho e a escalabilidade de elementos de dados, podemos dividir o conjunto de dados entre elementos de execução. Cada um destes elementos que possui parte dos dados é chamado de partição (ou shard). Há duas técnicas de partição de dados que merecem ser citadas: a partição horizontal e a partição vertical.

Primeiro, vamos apresentar a partição horizontal por meio de um exemplo. Se pensamos em dados relacionais, que estão organizados em linhas e colunas, a partição horizontal é a divisão em grupos de linhas entre os elementos arquiteturais de dados em execução. Por exemplo, se temos um banco de dados com dois milhões de usuários e temos dois servidores, A e B, executando esse banco de dados, os usuários com índices de zero a um milhão devem estar localizados no servidor A e o restante dos usuários devem estar localizados no servidor B. A partir desta divisão, para um cliente do banco de dados encontrar as informações de um dado usuário, agora ele deve ser capaz de localizar em qual servidor os dados estão de acordo com o índice que procura. Note que isso é uma forma de dividir a carga de requisições entre elementos de execução, mesmo usando elementos stateful.

Já a partição vertical consiste na seleção de algumas colunas do modelo de dados para serem servidas por elementos de execução diferentes. Assim, se temos novamente os servidores A e B, informações sobre todos os usuários estão em ambos os servidores. No entanto, informações mais requisitadas (por exemplo, nome do usuário e grupo de permissões o qual ele pertence no sistema) podem ser encontradas no servidor A, que dispõe de hardware melhor, enquanto informações menos requisitadas podem ser encontradas no servidor B. Da mesma forma que no caso anterior, o cliente deve ser capaz de localizar em qual servidor os dados estão. Só que agora, a localização é feita de acordo com o tipo de dados requisitados e não o seu índice.

Em um sistema, existem algumas informações que são mais requisitadas que outras. Por exemplo, a página de alguém muito popular numa rede social ou as notícias de primeira página de um portal de notícias. Portanto, podemos nos aproveitar desta característica ao projetar sistemas.

Se algumas informações são muito mais requisitadas que outras, o desempenho aparente de um sistema pode ser melhorado se conseguirmos servir essas informações com melhor desempenho. Uma forma de conseguir isso é usando um cache. Um cache é um elemento arquitetural capaz de servir informações com maior desempenho do que o elemento de dados que guarda essas informações originalmente. Portanto, ao requisitar alguns dados, o cliente pode primeiro requisitar ao cache. Caso o cache possua os dados requisitados, eles serão retornados mais rapidamente do que se o cliente tivesse requisitado apenas ao elemento de dados original. No entanto, precisamos observar que para desempenhar melhor do que os servidores de dados, o cache normalmente armazena um conjunto limitado de dados. Esta limitação o obriga a implementar as chamadas políticas de caching, que são diferentes formas de comportamento para maximizar a quantidade de “acertos” nas requisições de disponibilidade de informação e manter a consistência entre o cache e o elemento de dados original.

Entre as táticas de processamento para melhorar o desempenho da aplicação (em oposição às táticas de dados vistas anteriormente: partição de dados e caching), podemos citar: partição, paralelização e distribuição de processamento.

A partição de processamento é a divisão do processamento entre elementos arquiteturais distintos para tirar proveito das características de cada elemento de execução do software. Um exemplo simples é distribuir um grande processamento de dados entre os elementos da arquiteturais mais próximos a esses dados, com a finalidade de evitar ao máximo a transferência de arquivos. Assim, a característica do elemento de execução procurada para realizar a distribuição é se o elemento possui ou não os dados necessários para o processamento. Por exemplo, se observarmos a arquitetura de um sistema de processamento de grandes conjuntos de dados chamado MapReduce12 (ou de sua implementação open source, o Hadoop13), percebemos que ele divide o processamento em tarefas menores e tenta associar cada tarefa ao processador que esteja mais próximo dos dados necessários. Com esta política de atribuição de tarefas, o MapReduce consegue processar grandes massas de dados em tempo relativamente pequeno.

Já a paralelização de processamento consiste em permitir que linhas de execução independentes, por exemplo, chamadas de usuários diferentes em um sistema web, ocorram simultaneamente. Essa paralelização pode ser realizada de diferentes maneiras: em diferentes threads dentro de um mesmo processo, em diferentes processos dentro de um mesmo sistema operacional e em diferentes elementos de execução de um sistema (tipicamente, em diferentes servidores). Esta paralelização melhora o desempenho porque aumenta a vazão de respostas e pode utilizar recursos, inicialmente, ociosos.

Por fim, há a distribuição de processamento ao longo do tempo. Esta tática consiste em permitir que algumas tarefas de processamento requisitadas pelo usuário não sejam executadas sincronamente e, portanto, não fazendo com que ele espere pelo processamento de algo que não utilizará no momento. Assim, aumentamos o desempenho aparente do software. Um exemplo de distribuição de processamento ao longo do tempo é o de tratamento de imagens em sistemas de redes sociais. Quando um usuário faz o upload de uma imagem, essa imagem precisa ser otimizada para ocupar menos espaço de armazenamento no sistema. No entanto, este tratamento não é feito de forma síncrona, ou seja, quando o usuário envia a imagem, mas sim é agendado para ser executado em algum momento no futuro.

Apesar de projetar um sistema em diversas camadas de abstração melhorar o reuso (pela possibilidade das camadas serem reusadas), o entendimento (porque diferentes camadas representam diferentes níveis de abstração, facilitando o controle intelectual da complexidade) e até mesmo a testabilidade do sistema (dado que as camadas podem ser desenvolvidas e testadas separadamente), a presença de muitas camadas em um sistema pode prejudicar seu desempenho. Isto ocorre porque quanto mais camadas de abstração existem no design, principalmente se desnecessárias, mais recursos serão consumidos. Entre os recursos consumidos, podemos citar a memória, uma vez que mais camadas de implementação significam mais camadas a serem carregadas durante a execução, e mais ciclos de processamento, para realizar a comunicação entre diferentes camadas.

Podemos observar que as táticas que acabamos de apresentar aumentam a complexidade da arquitetura, uma vez que apresentam novos elementos tanto em nível de design, quanto em nível de execução. Em nível de design, os novos elementos podem prejudicar a modificabilidade e a compreensibilidade do software, dado que adicionam novas relações e conceitos e até sugerem a diminuição dos níveis de abstração. Já em nível de execução, novos elementos podem dificultar: a segurança, porque agora os dados estarão ainda mais distribuídos no sistema e mais entidades poderão acessá-los; a tolerância a falhas, porque podem surgir mais pontos únicos de falhas; e a operabilidade, considerando que os novos elementos de execução impõem mais tarefas de configuração.

O princípio do menor privilégio consiste em garantir ao usuário, cliente do software ou módulo do sistema apenas os privilégios necessários para que sejam capazes de concluir suas tarefas. Assim, caso este usuário, cliente ou módulo sejam comprometidos (passem a se comportar de forma nociva ao sistema), a quantidade de dano que poderão causar ao sistema será limitada.

O princípio de falha com segurança (fail-safe) é o de garantir que em caso de qualquer problema, seja de comunicação, autenticação ou falta em um serviço, o comportamento padrão seja um comportamento seguro. Por exemplo, se um usuário com privilégios de acesso tenta ler um arquivo privado e o sistema de autorização está indisponível, o comportamento padrão do sistema de leitura deve ser o de negar o acesso ao arquivo. Dessa maneira, mesmo que usuários autorizados sejam privados do acesso aos seus arquivos, os não-autorizados não conseguirão acesso indevido. O mesmo princípio deve ser aplicado, por exemplo, em sistemas de controle de tráfego. Se os indicadores de estado dos semáforos estão com problemas, os semáforos devem falhar no estado “pare”, uma vez que fazer com que todos os veículos parem nas vias de um cruzamento é mais seguro do que fazer com que mais de uma via seja indicada para seguir.

O princípio da defesa em profundidade sugere que a arquitetura deve aplicar diferentes técnicas de segurança em diferentes níveis do software. Por exemplo, um cliente autenticado do software deve não só ser autorizado a chamar uma função, mas a função chamada deve também ser autorizada a acessar as informações necessárias para o dado cliente. Esta técnica tanto permite que medidas de segurança mais específicas ao contexto possam ser utilizadas, quanto permite manter a segurança do software mesmo durante a falha de alguma medida de segurança adotada.

Podemos observar que, assim como as táticas de desempenho e escalabilidade, as táticas de segurança aumentam a complexidade da arquitetura. Isto ocorre porque também adicionam novos elementos arquiteturais à solução. Estes novos elementos, por serem novos conceitos, prejudicam a compreensibilidade do sistema em tempo de design e a operabilidade durante a execução. Além disso, as táticas de segurança também requerem a execução de passos adicionais de processamento (por exemplo, criptografar uma mensagem ou checar se senha inserida é válida), o que prejudica o desempenho da aplicação.

Se muitas funcionalidades dependem de apenas um serviço que executa em apenas um recurso computacional, todo o sistema estará comprometido se esse único serviço falhar. Este único serviço ou recurso computacional no qual o sistema depende é o que chamamos de ponto único de falhas. Portanto, para que o software não seja completamente dependente de um único elemento, o arquiteto deve se preocupar em evitar os pontos únicos de falhas a partir do design. Para isso, ele pode distribuir responsabilidades entre diferentes elementos da arquitetura ou mesmo replicar processamento, de forma que o ponto único seja eliminado.

Já mostramos que a partição de dados é benéfica para o desempenho e a escalabilidade do sistema. No entanto, ao particionarmos os dados por diversos elementos de armazenamento, distribuímos também as responsabilidades do servidor de dados. Portanto, se um dos elementos de armazenamento falha, ainda podemos ter o sistema disponível para parte dos usuários (aqueles os quais as informações ainda estão disponíveis por meio dos elementos de armazenamento que não falharam).

Obtemos benefícios semelhantes aos de particionar os dados quando particionamos e distribuímos processamento por diferentes elementos da arquitetura. Diferentes responsabilidades atribuídas a diferentes elementos da arquitetura permitem que o software continue funcionando, mesmo que parcialmente, em caso de faltas.

Além disso, quando usamos processamento síncrono, amarramos a confiabilidade no processamento aos dois ou mais elementos que estão relacionados sincronamente. Por exemplo, se o elemento A realiza uma função que precisa chamar uma função síncrona no elemento B, a função de A só será executada com sucesso caso B também esteja disponível. No entanto, se a chamada a B for assíncrona, a função chamada em A pode ser executada com sucesso mesmo que B esteja indisponível temporariamente. Dessa maneira, assim que B estiver novamente disponível, sua função poderá ser executada.

Não só podemos distribuir diferentes responsabilidades de processamento a diferentes elementos da arquitetura, como também podemos atribuir a mesma responsabilidade a diferentes elementos. Assim, durante a execução, em caso de qualquer problema com um dos responsáveis, outro pode assumir seu lugar e retornar corretamente a resposta. Isso é o que chamamos de atribuir redundância a alguns elementos da arquitetura, sejam elementos de dados ou de processamento. Vale observar que não basta apenas replicar a responsabilidade do elemento em questão, mas decidir (1) se o elemento redundante ficará sempre ativo ou apenas entrará em execução quando a falha do original for identificada, (2) como as falhas serão identificadas durante a execução e (3) como os clientes do elemento que falhou redirecionarão suas chamadas para o elemento redundante.

Como as táticas de tolerância a faltas se aproveitam de algumas táticas de desempenho e escalabilidade, elas proporcionam as mesmas desvantangens em relação à compreensibilidade, modificabilidade e operabilidade, uma vez que aumentam a complexidade da solução de design.

O operador só é capaz de agir sobre o software, se ele possuir informações sobre seu estado interno. Para isso, é vantajoso que a arquitetura permita a monitoração do estado de seus elementos mais importantes durante a execução. Note que em um grande sistema, o conjunto de elementos monitorados pode ser grande, gerando assim uma grande massa de dados de monitoração. Portanto, a monitoração pode ser tornar um problema, uma vez que a geração e o consumo dos dados pode necessitar de muitos recursos computacionais (canal de comunicação, caso os dados sejam transferidos entre elementos do sistema, e armazenamento, caso os dados sejam armazenados, e processamento, para extrair informações dos dados). Portanto, a arquitetura deve proporcionar meios de geração e análise dos dados de monitoração, mas deve também implementar meios de agregação e compactação dos dados de forma que poupem o consumo de recursos computacionais.

Uma forma ainda mais eficiente de proporcionar operabilidade ao software é a de delegar tarefas que antes seriam de responsabilidade do operador ao próprio software. Portanto, permitir que o software seja capaz de pôr ou retirar de execução servidores, realizar backups, ou realizar outras atividades para a melhoria da qualidade de serviço. Realizar automaticamente estas e outras atividades baseadas apenas no estado atual do sistema e sem intervenção humana é o que chamamos de computação autonômica. Para permitir a adição de aspectos de computação autonônica ao software, sua arquitetura deve estar preparada de forma que dados sobre o estado atual do sistema não sejam apenas coletados, mas também sejam analisados automaticamente e os resultados dessa análise sejam capaz de ativar automaticamente tarefas de administração do sistema.

Como já mencionamos anteriomente, a monitoração e a análise do estado atual do sistema podem consumir muitos recursos computacionais, impactando negativamente no desempenho. Por outro lado, ao possibilitarmos a análise do software em tempo de execução, podemos identificar problemas inicialmente desconhecidos na arquitetura, como gargalos de desempenho ou pontos únicos de falhas. Com estes problemas identificados, o arquiteto pode então corrigi-los na arquitetura, melhorando assim o desempenho e a tolerância a faltas do software.