É interessante ver que existem novos aplicativos da web em construção que ainda não estão preparados para a nuvem. Isso significa que se eles obtiverem o que já foi chamado de “efeito slashdot”, eles simplesmente terão dificuldade para atender às solicitações. Algo inaceitável para 2013. Decidi então compartilhar o que vejo como uma arquitetura padrão para webapps modernos baseados em REST. Isso é altamente influenciado pela Arquitetura de Referência da Amazon chamada “Web Application Hosting” , mas com duas diferenças:
- O CloudFront está à frente de todas as solicitações, incluindo conteúdo dinâmico.
- Separação de bancos de dados de dados críticos para ficar por trás de aplicativos especializados
O primeiro item é um truque que aprendi durante o último AWS Summit, e o objetivo principal é manter a AWS perto do usuário final, mesmo quando você não tem servidores em uma região próxima ao usuário (Japão, por exemplo) . Nesse caso, o usuário se conecta ao CloudFront e o CloudFront se conecta aos seus servidores em sua região. No pior cenário, a velocidade é a mesma que o usuário teria sem o CloudFront, mas o raciocínio é que a conexão da AWS com seus próprios recursos é melhor do que a conexão de outro ISP. O truque é continuar servindo conteúdo estático como de costume do CloudFront e definir o TTL como 0 para recursos dinâmicos.
O segundo ponto pode parecer desnecessário, mas considerando a quantidade de aplicativos que ainda estão sendo comprometidos diariamente, acho que deve ajudar na proteção de dados críticos, como informações do usuário (nome, e-mail, senha, …) e aplicativos de terceiros dados (que manipula os dados do usuário em nome do usuário). Algumas outras vantagens incluem:
- Você pode alterar o tipo de armazenamento de dados para os dados do usuário e os dados do aplicativo. Por exemplo, você pode usar um banco de dados NoSQL para eles.
- Você pode implementar facilmente novos controles de segurança, sem afetar o aplicativo principal. Por exemplo, é trivial adicionar auditoria e registro extensivos à parte de informações do usuário, sem afetar o desempenho do seu back-end.
- Você pode dimensionar apenas as partes que precisam ser dimensionadas.
- Você pode se dar ao luxo de fazer coisas que não são perfeitas na área de “desempenho”, porque você tem apenas esse pequeno serviço ali. E se isso se tornar um problema, altere o algoritmo ou deixe-o aumentar.
- E, claro, o mais óbvio é que os dados do seu usuário não vazarão se você obtiver uma injeção SQL em sua maior base de código (back-end ou front-end). Os dados do seu usuário estão mais protegidos.
E para apimentar um pouco, você pode agrupar alguns recursos de segurança em torno dele, usando os grupos de segurança da AWS:
- Apenas instâncias no sg-front-end podem falar HTTP com instâncias em sg-user-info (e semelhante para sg-back-end> sg-app-info)
- As máquinas em sg-user-info ou sg-app-info não podem iniciar uma conversa (exceto, talvez, para falar com os servidores Chef e / ou repositórios de atualização de software)
- SSH é aceito apenas se for de um sg-ssh-bastion (não mostrado na imagem)
E o preço ainda não é ruim: para um ambiente de desenvolvimento (sem os ELBs), você gastaria algo entre 0,50 USD por mês (40 horas / semana) até cerca de 50 USD, para microinstâncias 24×7 para cada camada . E para uma configuração de produção, como mostrado na imagem, você gastaria cerca de 150 USD / mês para instâncias “reservadas” de 3 anos (1200 USD iniciais). Certamente não é a opção mais barata que existe, mas com certeza, a opção mais barata neste tipo de arquitetura altamente disponível e segura.