Netflix + Azure Traffic Manager + Migração Access/MySQL para SQL Azure

Para quem não soube, o serviço de nuvem da Amazon teve problemas no início do mês que atrapalhou boa parte dos seus usuários.

Erros acontecem, e a Amazon descreve o que aconteceu neste link: https://aws.amazon.com/message/65648/. Até aqui, nada de tão interessante.

No entanto, como resultado desta falha surgiram aprendizados. Dos que eu li, o texto mais interessante foi o da Netflix, que descreve o porquê o serviço da Netflix não sofreu muitos danos. O texto completo você pode encontrar aqui, mas, aqui vai um resumo:

Pontos relevantes da arquitetura Netflix:

1) Os serviços são stateless, isto é, por não armazenarem estados nos servidores a falha deles não é tão impactante para o usuário final;

2) Os dados são armazenados em várias geografias, aumentando a disponibilidade através da “redundância”;

3) O sistema foi projetado para falhar, usando princípios como:

     a. “falhar rápido” com timeouts curtos que fazem os processos caírem se os tempos não forem obedecidos;

     b. “Recuo” (“fallback”): se uma funcionalidade não pode ser mostrada, outra de menor qualidade/funcionalidade pode entrar em ação e substituí-la;

     c. “Remoção de funcionalidades”: se uma funcionalidade não é importante e há problemas de desempenho, ela pode ser desativada temporariamente;

4) Redundância N+1: alocam-se sempre mais recursos do que necessário para uma reserva de capacidade;

5) Uso de consistência eventual: nada de sistemas relacionais para armazenamento (veja mais neste post)

É claro que estes direcionamentos de design são importantes apenas para quem precisa de alta disponibilidade para milhões de usuários. Sistemas com requisitos menores podem ser mais simples, usar bancos de dados relacionais, etc. Nem todo mundo precisa do SLA da Netflix.

A boa notícia é que está cada vez mais fácil e barato usar critérios de design como os usados pela Netflix. A “Table” do Azure, por exemplo, já é elástica por natureza e deve ser usada levando em conta que oferece consistência eventual. O provisionamento automático da computação é simples e pode ser feito usando sistemas como o System Center ou via uso de API’s de monitoração/gerenciamento.

Uma boa novidade, que foi pouco falada até agora, é a chegada do Azure Traffic Manager que está em CTP. Aqui vai a descrição encontrada aqui:

Windows Azure Traffic Manager é um novo recurso que permite aos clientes balancear a carga do tráfego para múltiplos serviços hospedados. Os desenvolvedores podem escolher entre três métodos de balanceamento de carga: desempenho, “failover”, ou “Round Robin”. O Traffic Manager irá monitorar cada conjunto de serviços hospedados em qualquer porta HTTP ou HTTPS. Se ele detecta que o serviço está off-line, o Traffic Manager irá enviar o tráfego para o próximo melhor serviço disponível.

Isto implica em colocar o sistema e dados em datacenters distintos e contar com o Traffic Manager para distribuir a carga entre eles. Em caso de falha de um datacenter ou da comunicação com ele, a carga será direcionada para um dos datacenters alternativos. Cool!

Já existe um laboratório disponível que trata só do Azure Traffic Manager no SDK do Azure. Vale uma leitura e teste.

 

Outras notícias:

Foram anunciados Toolkits para facilitar a chamada de serviços do Azure a partir de dispositivos com o iOS, o Windows Phone 7 e o Android (este ainda em desenvolvimento). Vale conferir aqui.

Já saíram duas versões do SSMA (SQL Server Migration Assistant) que tratam agora do SQL Azure: o SSMA for Access e o SSMA for MySQL. Vale conferir.

O Condé colocou no seu último post mais novidades sobre o SQL Azure. Vale a leitura.

Abraços