Para aqueles que não viram, alguns serviços da AWS ficaram indisponíveis no dia 20/Set (http://status.aws.amazon.com/) afetando alguns clientes famosos, como Netflix, Airbnb, IMBd e Tinder. (para esse último, felizmente o downtime foi no domingo... se fosse no sábado a noite poderia ter estragado o final de semana de vários solteiros)
Nos próximos meses essa notícia vai ser ecoada, de forma mais ou menos sutil, entre outros provedores de nuvem pública ou privada, como uma forma de alegar que as aplicações não estão seguras na AWS e que os clientes deveriam migrar para a solução de Cloud “A” ou “B”, ou dizer que a solução segura é na nuvem privada.
E essa é simplesmente a conclusão ERRADA sobre o problema... que atire a primeira pedra quem nunca teve um downtime :)
Então que conclusões, ou melhor ainda, que lições podemos aprender com isso?
1. Tenha um catálogo de serviço que inclua também informações como nível acordado de serviço para cada serviço/aplicação (ITIL). Essa informação já constitui o primeiro filtro para saber AONDE colocar essa aplicação. Nuvens publicas possuem SLA definidos para seus serviços como por exemplo, AWS ECS: https://aws.amazon.com/ec2/sla/ e Azure Virtual Machine http://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_0/
Se o SLA oferecido não atende os seus requisitos você precisa buscar outras soluções, como por exemplo: cluster entre múltiplos Availabilities Zone (no caso da AWS), ou usar uma private cloud – desde que você consiga montar um ambiente com SLAs melhores e esteja Ok com esse custo – lembrando que quando disponibilidade tende a 100% o custo tende a infinito. :)
2) Tenha sempre um plano de fuga! Se por qualquer razão (custo e/ou qualidade de serviço) determinada solução – no caso, provedor de nuvem pública – não atender mais as suas necessidades, como fazer para portar as suas aplicações para outro lugar?
Infelizmente não existe a Portabilidade Universal de Nuvem e algumas nuvens são muito mais difícil de sair!
Esse é outro fator relevante na escolha da solução ou do seu CSP (Cloud Service Provider). Por exemplo, eu escrevi AQUI, sobre a preocupação das empresas sobre diminuir o grau de dependência dos vendors de infraestrutura, porém como diminuir a dependência com provedores de nuvem publica?
Por definição, uma empresa não pode construir a sua própria nuvem publica, mas você pode escolher um provedor que te dê mais flexibilidade/mobilidade dos workloads.
Essa mobilidade pode acontecer na camada de Infraestrutura (VMs) e em geral envolve compatibilidade de hypervisors. Por exemplo, se você escolher o Azure como sua nuvem publica, você poderá mover workloads entre o Azure e uma infraestrutura privada, baseada em Hyper-V. Idem para nuvens públicas baseadas no vCloud Air e hypervisor VMware.
Outra opção, pelo menos para parte de suas aplicações, é adotar o conceito das Cloud Native Applications, aplicações menos dependente da infraestrutura. (tradicional, virtualizada ou “as-a-Service”), que podem ser portadas facilmente entre nuvens (escrevi um pouco sobre isso AQUI).
Se o SLA oferecido não atende os seus requisitos você precisa buscar outras soluções, como por exemplo: cluster entre múltiplos Availabilities Zone (no caso da AWS), ou usar uma private cloud – desde que você consiga montar um ambiente com SLAs melhores e esteja Ok com esse custo – lembrando que quando disponibilidade tende a 100% o custo tende a infinito. :)
Infelizmente não existe a Portabilidade Universal de Nuvem e algumas nuvens são muito mais difícil de sair!
Esse é outro fator relevante na escolha da solução ou do seu CSP (Cloud Service Provider). Por exemplo, eu escrevi AQUI, sobre a preocupação das empresas sobre diminuir o grau de dependência dos vendors de infraestrutura, porém como diminuir a dependência com provedores de nuvem publica?
Por definição, uma empresa não pode construir a sua própria nuvem publica, mas você pode escolher um provedor que te dê mais flexibilidade/mobilidade dos workloads.
Essa mobilidade pode acontecer na camada de Infraestrutura (VMs) e em geral envolve compatibilidade de hypervisors. Por exemplo, se você escolher o Azure como sua nuvem publica, você poderá mover workloads entre o Azure e uma infraestrutura privada, baseada em Hyper-V. Idem para nuvens públicas baseadas no vCloud Air e hypervisor VMware.
Outra opção, pelo menos para parte de suas aplicações, é adotar o conceito das Cloud Native Applications, aplicações menos dependente da infraestrutura. (tradicional, virtualizada ou “as-a-Service”), que podem ser portadas facilmente entre nuvens (escrevi um pouco sobre isso AQUI).
Em resumo, conheça/defina os SLAs para as suas aplicações, analise as ofertas de mercado (não existe solução única para tudo), e tenha sempre um plano de fuga!
