AWS Summit
Bom, é um evento informativo a respeito do Amazon Web Serviçes, suas soluções, serviços, tecnologia e cultura. Além da possibilidade de exposição das soluções de parceiros para o AWS.
O AWS Summit possibilitou a todos uma visão geral da nova "modalidade" de infraestrutura em TI, a computação nas nuvens. Mostrou casos onde a aplicabilidade desta solução viabilizou um negocio com um baixo TCO, alta flexibilidade de gerenciamento e possibilidade de crescimento dimensionado.
A abertura do Werner Vogels nos mostrou que o novo passo para uma TI moderna, segura e confiável está nas nuvens e os parceiros Amazon explicaram como o cloud os ajudou a solucionar problema de forma ágil e concreta e em alguns casos possibilitou até a criação de empresas.
Primeira foto do dia, um dos parceiro da Amazon a redhat.
Um trecho de um documento da Intel, outro parceiro, sobre a crescente importância do cloud.
Aqui começa o AWS
A Amazon tem uma filosofia de redução do preço cobrado pelos seus serviços na media em que você vai utilizando cada vez mas. Ela até ensina como você pode otimizar seus gastos com o AWS.
O funcionamento do serviço de rede do AWS
Um slide sobre o funcionamento do serviço de storage da Amazon
Nosso amigo Werner Vogels da Amazon, de longe o melhor palestrante do evento. Muito carismático.
Um novo serviço que acaba de ser lançado pela Amazon nos USA, o Glacier. Diferente do S3, que é uma storage, o Glacier é um archive, sua principal função e armazenar dados pouco utilizados, ex. backups. O custo do Glacier é inferior se comparado com o S3, provavelmente pela diferença de desempenho na disponibilização de dados. Sendo assim os backups que hoje são guardados no S3 poderão ser guardado no Glacier, otimizando o gasto com os custo do armazenamento nas nuvens.
VPC - Um link entre seu datacenter físico e o datacenter na nuvem.
Uma palestra sobre como montar na Amazon um cenário a prova de falhas. Uma explicação de como melhor usar os recursos disponibilizados por ela.
Nosso palestrante que fala muito rápido em inglês. Ryan Holland.
O que eu pude entender bem da palestra do Ryan é o conceito de Monitorar, Identificar e Automatizar.
Numa aplicação hospedada no AWS ou um servidor hospedado na Amazon, podemos Monitorar o seu comportamento, monitorar a utilização do recurso. A importância do Monitoramento é a identificação de padrões do comportamento da aplicação/servidor. Assim conseguiremos mensurar uma necessidade de aumento de um recurso quando a aplicação estiver sobre pico de uso, protegendo-a de uma lentidão ou do congelamento do servidor, evitando uma falha. Conseguimos também diminuir esse recurso quando a aplicação estiver com seu consumo de recursos normalizados ou fora do pico de utilização. Com a união do monitoramento e da identificação poderemos Automatizar o processo de adequação de recursos para as instâncias e assim deixar nossos sistemas e aplicações completamente a prova de falhas.
Esse slide e os dois próximos eu achei um pouco estranho. O primeiro fala sobre uma topologia que não esta de acordo com os padrões de tolerância a falhas. Dois slides abaixo ele mostra como deveria ser uma topologia de tolerância a falhas na Amazon.
Bom minha opinião quanto a isto é que a Amazon tem 3 data center em são paulo, para que esta região não fique offiline. Então qual o motivo que eu vou usar uma solução de redundância da Amazon? Para gastar mais dinheiro.
Concordo com o uso do Elastic IP apontado para duas maquinas igual com o mesmo sistema no caso de que você pode executar uma atualização em uma das maquinas, retirar ela do Elastic, e testar uma nova versão de software, antes de decidir se vai subir em produção ou não. Isso na verdade é um procedimento de homologação de produto que deveria ser o padrão sempre.
Mas criar um backup do seu site inteiro na Amazon para caso uma das regiões apresente problemas é muita loucura. Se a região de são paulo parar (lembrando dos 3 data centers) o menor dos meus problemas será os servidores da minha empresa. Eu imagino algo como no Duro de Matar 4 quando a cidade inteira esta destruída, ou o novo modern warefare 4, ou o Bane querendo destruir São Paulo, porque Gothan ele não ficou satisfeito com a destruição que ele fez. Se até a Stark Tower parou quando a cidade foi destruída......
Aqui são as diretrizes que devemos seguir para termos um sistema totalmente a prova de falhas.
Aqui começa a melhor palestra do dia. Tanto pelo conteúdo quanto pelo palestrante. O Jinesh Varia, um indiano, é muito bom palestrante e fala muito bem inglês. Quando eu vi o nome dele, eu pensei que seria muito difícil de entender a palestra. Mas até que não. Em alguns momentos ele falou muito rápido, mas não atrapalhou muito o entendimento do conteúdo.
A ideia principal desta palestra realmente é bem representada pela foto abaixo. Você usa e paga somente o que precisa. Quando você quer sentar em uma praça você não precisa pagar por todo o assento, somente pela parte que você irá utilizar. Caso chegue a sua namorada, você contrata ondemand uma outra parte de assento, e paga extra pelo tempo que você ficarem sentados juntos. Quando você for embora não esquece de desconfigurar o assento adicional. :-p
Aqui ele mostra a configuração de uma empresa onde podemos verificar que ela possui servidores em load balance para aguentar o alto processamento ou trafego de arquivos. Imagina uma aplicação pesada rodando. Agora olhe o próximo slide.
Essa aplicação não terá um alto processamento ou trafego de utilização quando seus clientes estiverem dormindo correto? Então pra que deus você vai deixar suas maquinas ligadas. O Jinesh sugere a você desligar uma parte sua infra lógica, Assim você tem uma economia, pois você somente deve ligar os outros servidores em momentos de picos de processamento ou nos horários onde é uma maior utilização. No caso deste exemplo, as maquinas adicionais ficam ligadas apenas no período comercial. nas 12h restante apenas uma parte do ambiente esta ligada, somente para que a aplicação não fique offiline.
Aqui tem um pouco mais de teoria sobre ligar/desligar as máquinas em horários. O auto scaling ele deverá ser configurado para possibilitar esse processo de ligar e desligar conforme um horário.
Alem da configuração do horário, podemos criar uma policy, e configurá-lá para detectar por exemplo a utilização de CPU. Caso essa utilização atinja 60% a policy pode ligar a máquina secundária automaticamente.
Aqui um resumo das Best Practices sobre o auto scaling
Aqui uma recomendação de uma policy de auto scaling de CPU
