Alejandro Olchik // segunda-feira, 22/08/2011 15:52
Como pode ser que uma empresa como a Netflix, cliente dos serviços de Cloud Computing da Amazon, praticamente não foi afetada pelo incidente de indisponibilidade da Amazon, ocorrido no final de Abril, enquanto muitas outras empresas chegaram a ficar fora de operação?
Sorte? Com certeza não. Assim como a Netflix, as empresas devem planejar a transição para a nuvem, colocando-se como coresponsáveis pelo nível de segurança de suas operações baseadas em Cloud Computing.
A Netflix é líder no streaming de vídeo através da Internet. A empresa tem um faturamento superior a 2 bilhões de dólares e mais de 25 milhões de assinantes nos Estados Unidos e no Canadá. A Netflix acredita que é fundamental ser capaz de atender seus clientes, sem sobressaltos, mesmo na ocorrência da perda completa de um de seus datacenters. Quando migraram os seus sistemas para a nuvem, no lugar de replicar o modelo de operação que mantinham em datacenter local, optaram por desenhar uma nova arquitetura que tirasse o maior valor possível dos serviços de Cloud Computing.
A Netflix utiliza uma arquitetura onde os sistemas estão distribuídos geograficamente através dos vários datacenters da Amazon. Todos os datacenters estão ativos de forma simultânea. A capacidade é provisionada de forma que, caso um datacenter seja perdido, os restantes conseguem absorver a carga a ser redistribuída. Do ponto de vista de desenho de arquitetura, eles têm uma preocupação bastante grande com o uso de serviços que não demandem a preservação de estado (stateless services). Nesse cenário, qualquer instância (ou máquina virtual) é capaz de atender qualquer requisição em tempo aceitável; a falha da instância não afeta o serviço ao usuário final. Além de seguir esse padrão de arquitetura, a Netflix é pouco tolerante em relação ao tempo de resposta, derrubando as instâncias logo que seus serviços começam a degradar. Essa abordagem elimina da operação as instâncias com comportamento instável. As funcionalidades não críticas têm versões simplificadas que entram em operação quando o desempenho começa a ficar degradado. As funcionalidades não críticas também podem ser removidas, mediante configuração, para garantir que funcionalidades críticas sejam mantidas em operação. A preocupação com a resiliência é tanta, que a Netflix tem uma aplicação chamada de “macaco caótico” (chaos monkey). Essa aplicação simula falhas aleatórias nos sistemas de forma rotineira apenas para verificar se a arquitetura atual é efetivamente capaz de lidar com as falhas sem necessidade de intervenção humana. Como os desenvolvedores já sabem que seus sistemas serão necessariamente alvos de falhas aleatórias, já os projetam considerando essa realidade.
No caso específico da falha da Amazon, o problema foi tão significativo que a equipe da Netflix precisou intervir manualmente. Internamente, eles notaram incremento na taxa de erros e nos tempos de resposta. Porém, do ponto de vista dos clientes, não houve incremento significativo nos chamados de suporte, nem os clientes perderam a capacidade de encontrar e ver os filmes.
Evidente que esse grau de disponibilidade demanda investimento e custo operacional, mas essa característica independe do serviço estar rodando em nuvem ou não. A nuvem oferece vantagens que uma infraestrutura tradicional não consegue oferecer, como elasticidade e automação.
Quando empresas migram um serviço para a nuvem é importante identificar os riscos que realmente precisam ser mitigados. Recentemente a Ribbit, uma empresa que oferece plataforma online para o desenvolvimento de aplicações de voz, anunciou que seus clientes têm 60 dias para parar de usar o serviço, pois a plataforma não será mais comercializada para os usuários finais.
Essa situação nos remete a importância de verificar a portabilidade e interoperabilidade dos nossos provedores de Cloud Computing. Interoperabilidade e portabilidade é um “hot topic” em Cloud Computing.
Várias são as iniciativas de padronização: IEEE P2301, IEEE P2302, Open Cloud Computing Interface, Open Virtualization Format, API da Rackspace, vCloud API da VMWare, EC2 API da Amazon, e por aí vai. Antes de cair de cabeça em algum padrão é importante ter clareza sobre o tipo de risco que estamos tentando mitigar, pois toda a portabilidade tem um custo.
Queremos poder migrar entre provedores? Queremos poder trazer novamente a operação para dentro de casa? Queremos apenas sobreviver a queda de um datacenter? A Cloud Alliance tem recomendações específicas com relação a portabilidade que podem ser um bom guia para quem quer começar a fazer as perguntas certas.
Dúvidas comentários e sugestões? Comente!
Interessado nos mitos anteriores? Aqui a lista:
- Mito #1: Empresas que realmente se preocupam com segurança não estão migrando para a nuvem
- Mito #2: A nuvem nunca conseguirá entregar a transparência necessária
- Mito #3: Provedores públicos de Cloud Computing são inseguros
- Mito #4: Manter sistemas dentro de casa é mais seguro que mantê-los na nuvem pública