Arquitetura em projetos de aplicações em nuvem - noções iniciais

Hoje o foco é arquitetura para uma aplicação que será implantada na nuvem. Em primeiro lugar, o que motiva colocar uma aplicação na famosa nuvem? Se você pensou algo do tipo "deve ser melhor, porque todo mundo está fazendo", quero que você reflita mais sobre suas decisões.

Existem motivações para se colocar uma aplicação em nuvem. Cito algumas: necessidade de começar com pouco investimento em infraestrutura e crescer sob demanda; possibilidade de escalar a aplicação horizontalmente em resposta rápida a uma quantidade de acessos maior que o normal; de forma análoga, a capacidade de diminuir a escala da aplicação e evitar servidores ociosos (e seus custos) em momentos de calmaria; menor preocupação com infraestrutura e sua gestão; alta disponibilidade; facilidade de criar ambientes de homologação e fazer o chaveamento entre estes e produção. Bem, existem outros fatores, certamente, mas vamos focar nesses.

Para se conseguir obter os benefícios de uma aplicação em nuvem é preciso arquitetar de forma a se adequar a premissas e restrições que o seu parceiro fornecedor de serviços de nuvem oferece. Uma preocupação recorrente é a criação de aplicações stateless, para poder escalar horizontalmente ou mesmo ter alta disponibilidade - caso o servidor caia, outro pode assumir, de forma transparente ao usuário. Se a aplicação for um site, é preciso pensar em como lidar com as variáveis de sessão. A grosso modo, o ideal é simplesmente não usar. Mas, e se eu precisar? Uma alternativa é externar o seu armazenamento, desvinculando do servidor de aplicação.

Muitos se preocupam com a segurança de uma aplicação em nuvem. Ora, se o fornecedor for sério, como a Amazon, a Google, a IBM ou outros desse calibre, é muito provável que a oferta deles seja mais segura que se você gerenciasse a sua aplicação. É claro que não é só fazer o deploy na nuvem e está a oitava maravilha do mundo. No entanto, existem ofertas de um ferramental de segurança que ajuda muito, desde os tradicionais firewalls e uso de certificados digitais até WAFs, incluindo proteção contra DDoS, mascaramento do IP real por meio de serviços de DNS dinâmicos e tantas outras opções. Recomendo a leitura da documentação do fornecedor e a ajuda de um especialista. É verdade que segurança deve ser uma preocupação constante, mas se o trabalho for bem feito, principalmente no início do projeto, não será nada para tirar o sono.

Minha dica para aplicações em nuvem é experimentar. Sim, monte um ambiente, faça a configuração que você julga que vá gerar o efeito desejado e exercite a mesma. Faça testes de cargas, pen tests, coloque a dita cuja a prova. Se não surtir efeito, descarte, a la "lean startup" (aliás, recomendo fortemente a leitura desse livro). É preciso validar a arquitetura e nada melhor que fazer na prática. O gasto que você terá ao fazer isso no ambiente de testes será baixo e se pagará ao ver que o seu sistema está mais robusto/estável/confiável. Aplicar uma nova configuração, descoberta empiricamente, deve ser tarefa fácil.


Provocações finais

Quais requisitos, em especial os não funcionais, o seu fornecedor de nuvem atende ou facilita a conformidade? Quais ele não atende? O que motivou a escolher esse fornecedor? E por que a sua solução está na nuvem? Como foi o seu planejamento, em especial para validar a sua arquitetura? Quais os limites da sua aplicação? Quantos usuários simultâneos ela suporta? Como é o consumo de processador, memória, disco e rede? Como você acompanha ou monitora? Uma mais complexa: quanto é o vendor lock-in (dificuldade de migrar sua solução para outro fornecedor)?

Comentários

Postagens mais visitadas deste blog

Documento de arquitetura

Requisitos conflitantes e dilemas no projeto de software

Levantamento de requisitos