Elasticidade é um dos principais conceitos e provavelmente o que traz mais benefícios na cloud computing.
É a capacidade de aumentar ou diminuir sua capacidade de forma rápida e fácil. Você pode utilizar a elasticidade de forma manual ou utilizar recursos automáticos, como o auto scalling no caso da AWS.
Seguindo o padrão de cobrança do serviços em nuvem, você paga apenas o utilizado, não precisando dimensionar sua infraestrutura para um crescimento futuro.
As arquiteturas tradicionais consideram a carga em momentos de pico para dimensionamento da infraestrutura. Com a elasticidade você pode dimensionar a infraestrutura para a demanda atual e fazer o crescimento vertical ou horizontal de acordo com sua necessidade.

Escalabilidade vertical (scale up) é quando adicionamos novos recursos aos servidores existentes, fazendo upgrade de memória, CPU, HDs etc.
Escalabilidade horizontal (scale out) é quando adicionamos novos servidores, geralmente com capacidade igual ou parecida ao anterior, pois dividiremos a carga entre eles. Quando fazemos escalabilidade horizontal temos que tomar cuidado para que a arquitetura das aplicações estejam preparadas para isso.

A elasticidade pode ser usada para crescimentos naturais baseado no aumento da empresa ou para eventos pontuais, como grandes ações de marketing, datas comemorativas, black friday. Onde é muito comum que as empresas não tenham controle sobre a quantidade de acessos aos sistemas e podem configurar o auto scalling para gerenciar a criação de novos servidores baseado na carga dos servidores atuais.

Princípios importantes da elasticidade:
– Loose coupling: é o conceito onde um recurso não pode depender unicamente de um outro, por exemplo a sua aplicação não pode apontar diretamente para o IP do servidor de Banco de Dados ou uma aplicação que depende de outra aplicação não pode apontar diretamente para o IP desse servidor, tem que apontar para o IP de um elastic load balancer que fará o controle de qual servidor utlizar.
– Staying Stateless: não podemos controlar o estado das sessões nos próprios servidores de aplicação, pois podemos responder as requisições de servidores diferentes. Temos que manter o estado em um recurso externo, DynamoDB por exemplo.

Em breve criarei um artigo com a implementação prática do conceito na AWS.