Arquivo do Autor: Guillermo Hess

Grande redução dos preços AWS não foi piada de 1º de abril

Ontem, 1º de abril de 2014, a Amazon Web Services (AWS) anunciou mais uma redução nos preços dos seus serviços. E dessa vez a redução foi grande. Como grandes empresas de TI gostam de fazer brincadeiras no dia dos bobos – vide todo o histórico da Google- esperei para ver se era verdade. Acabei de conferir no site da AWS e os preços realmente caíram.

A seguir mostro algunes exemplos das reduções de preço percebidas:
EC2, modelo on-demand, Linux

região tipo preço anterior(USD) novo preço(USD) % reducao
North Virgina (us-east-1) m3.large 0.226 0.14 38%
São Paulo (SA-East-1) m3.medium 0.16 0.095 40%

 

No S3 a redução de armazenamento foi ainda maior, embora o preço da transferência de dados não tenha sido alterada
S3 (Simple Storage Service)

região preço anterior(USD), por GB armazenado novo preço(USD), por GB armazenado % reducao armazenamento
North Virgina (us-east-1) 0.095 0.03 68%
São Paulo (SA-East-1) 0.13 0.04 68%

 

Vários outros serviços também tiveram redução de preço. Por exemplo, o serviço de banco de dados relacional (RDS), em uma implantação do tipo Multi-AZ na região São Paulo (SA-East-1) com uma instância db.m3.large caiu de USD 0.65/hora para USD 0.47/hora. Isso significa uma economia de 27% para o usuário.

Com preços ainda mais competitivos, fica cada vez mais atrativo migrar para a nuvem da AWS e experimentar os benefícios que cloud computing pode trazer.

Outage da Amazon no Brasil separa o joio do trigo

Hoje, 18 de dezembro de 2013, uma das availability zones (AZ, ou datacenter) da Amazon Web Services (AWS) no Brasil ficou fora do ar. Na realidade, no momento da escrita deste post o problema persistia. Os principais serviços de processamento (EC2, RDS, ELB) ficaram indisponíveis no datacenter de São Paulo. Segundo a AWS, problemas de conectividade, conforme mostra a imagem a seguir, extraída as 09:00 AM (horário de Brasília) do service health dashboard.

AWS health dashboard

Pessoas me ligaram perguntando o que havia acontecido, mensagens foram postadas em foruns, todos desesperados porque seus sistemas estavam fora do ar. Isto mostra que a oferta da Amazon no Brasil não é confiável? Não, muito antes pelo contrário. Para todos eu expliquei a mesma coisa: A AWS trabalha com, no mínimo, 2 datacenters (as Availability Zones) em cada região, cada uma com rede de energia e dados independentes, justamente porque estas coisas podem acontecer. Os sistemas dos usuários da AWS terem ficado fora do ar mostra que suas infraestruturas não foram pensadas para a nuvem.

E é aí que separamos o joio do trigo. Ou seja, é aí que vemos quem simplesmente transferiu sua infraestrutura para a nuvem da Amazon e quem fez, efetivamente, uma migração para a AWS. Uma arquitetura montada para a nuvem deve prever que falhas ocorrerão e ser capaz de se recuperar sozinha, automaticamente, nestes casos. Apenas é necessário saber o que e como fazer. Existem ferramentas e serviços da própria AWS, tais como o Elastic Load Balancer (ELB) e o auto scaling, que servem para que sejam montadas arquiteturas resilientes, altamente disponíveis. Na figura abaixo apresento uma arquitetura de uma aplicação web simples, mas que suporta tranquilamente outage de uma AZ, ou seja, garante a alta disponibilidade da aplicação.

Arquitetura AWS com alta disponibilidade

Todo o tráfego entra para o ELB, o balanceador de carga. Este encaminha o tráfego para a(s) instância(s) EC2 que estiver(em) no ar e saudáveis (de tempos em tempos o ELB faz uma espécie de ping para ver se a instância responde e só manda tráfego real se ela estiver respondendo). Estas instâncias fazem parte de um auto scaling group, que é configurado para, por exemplo, ter sempre no mínimo 1 instância abaixo do ELB e que pode subir instâncias em qualquer uma das AZs da região. Caso a instância não esteja respondendo ao ELB, o auto scaling “mata” esta instância e sobe outra, possivelmente em uma AZ diferente, e que provavelmente estará funcionando. E, com isso, a aplicação não ficará fora do ar.

Do lado do banco de dados, o serviço de relational database service (RDS) da Amazon permite que se trabalhe com multi-AZ (exceto o SQL Server), o que faz com que o banco de dados rode no modelo master-slave, sendo que o master está em uma AZ e o slave, sincronizado em tempo real, em outra AZ. O slave fica em stand-by e, caso o master caia, ele assume como master.

Tudo isso tem um custo? Sim, mas certamente é menor do que o sistema ficar fora do ar.

Curiosamente, nenhum dos nossos clientes telefonou dizendo que sua infraestrutura estava inacessível ou fora do ar :-).

Ionatec é parte da Amazon Partner Network

Parceira da Amazon Web Services (AWS) para prestação de serviços de consultoria em cloud computing desde maio de 2011, a ionatec foi credenciada oficialmente nesta semana no programa Amazon Partner Network (APN).

Este credenciamento atesta o conhecimento da ionatec em cloud computing e nos serviços AWS, e a capacidade da ionatec em realizar consultoria, assessoria e treinamento em cloud.

Nossas informações junto à Amazon, bem como os cases que temos com cloud computing e AWS podem ser encontrados no diretório de parceiros AWS.

AWS Consulting partner logo

FailCon 2013 – Falhar é aprender

No dia 19 de outubro, a ionatec e a Woompa estarão, mais uma vez, organizando a versão brasileira da FailCon. O evento, que foi criado em São Francisco por Cassandra Phillips e Diane Loviglio, já possui edições em mais de 10 países. Depois do sucesso da primeira FailCon brasileira, ocorrida em Maio de 2012, o próximo evento promete ser ainda melhor.

Falhar ainda é um tabu em diversos lugares no mundo, inclusive no Brasil. O fracasso é, muitas vezes, visto como algo negativo e vergonhoso. A FailCon surgiu justamente para quebrar esse tabu, mostrando que podemos aprender muito mais com as nossas falhas (e a dos outros) do que com o sucesso.

Sabemos que a estatística é a nossa maior inimiga: 9 entre 10 startups fracassam. Ao invés de escondermos nossas falhas debaixo do tapete e seguir em frente, será que não conseguimos tirar nada de tudo isso?

Durante o evento os palestrantes irão compartilhar seus fracassos profissionais, mostrando que lições tiraram dessas experiências. O objetivo é humanizar a falha, mostrando que ela faz parte do processo; ninguém atinge o sucesso sem antes ter fracassado.

Mais informações sobre o evento: www.brazil.thefailcon.com

Por que a maioria das startups falham

O modelo mental de muitos empreendedores no mundo digital está focado em buscar parceiros capazes de colocar suas ideias de negócios no ar, ao invés de procurar formas efetivas de validar seus modelos de negócios. Sem dúvida, essa é uma das principais razões para a baixa taxa de sucesso das startups.

A paixão pela ideia e a vontade de criar algo que impacte a vida das pessoas pode se tornar uma armadilha perigosa. Se por um lado é fundamental acreditar nesse sonho, por outro é vital entender onde estão os principais riscos do negócio. Ao contrário do que a maioria pensa, o software é o item de menor risco nesse processo; qualquer equipe de desenvolvimento qualificada tem a capacidade de desenvolver o que o empreendedor deseja. O verdadeiro risco não é tecnológico, mas sim, de negócio. Para quem vamos vender? Como vamos vender? Quanto o cliente está disposto a pagar? Qual o custo de aquisição do cliente? Qual o conjunto de funcionalidades que atende à demanda do cliente? Só faz sentido começar a pensar no software no momento em que essas perguntas forem respondidas. O problema é que o empreendedor acredita já ter essas respostas. Dessa forma, todo seu foco está voltado para o desenvolvimento da solução.

Passar pelo processo de validação é fundamental para reduzir a chance de fracasso de qualquer startup. Vale salientar que não existe uma fórmula mágica que garanta o sucesso. O processo de validação é focado no aprendizado. Quanto mais eu aprendo sobre o modelo de negócios proposto, mais informações eu tenho para tomar a próxima decisão, seja ela de ir adiante no projeto, de mudar o rumo, ou de desistir.

Como diz Steve Blank, nenhum plano de negócios ou um business model canvas resiste ao primeiro contato com o cliente. Investir até o último centavo no modelo inicial, ignorar as reais necessidades dos clientes, e não ser receptivo a mudança, possivelmente levará a sua startup ao fracasso.

Auto scaling para alta disponibilidade

Seguidamente, seja nos cursos de cloud computing ou em migrações, me questionam se configurar auto scaling e usar balanceador de carga é útil para pequenos sistemas online. Aqueles que, tipicamente, rodam em um único servidor. A resposta é sim, é útil e recomendado.

Quando utilizamos, em conjunto, um serviço de monitoramento, balanceamento de carga e auto scaling corretamente, podemos chegar em um cenário no qual praticamente conseguimos garantir que o sistema estará no ar sempre. Vou exemplificar a partir do uso do CloudWatch (monitoramento), elastic load balancer – ELB (balanceamento de carga) e autoscaling da Amazon Web Services (AWS). Primeiro, configura-se o autoscaling com uma regra que diz que no mínimo tem que ter 1 instância (máquina virtual – VM) rodando, podendo-se definir também o número máximo de instâncias que podem estar em execução. Depois, cria-se um ELB que faz o roteamento do tráfego para a(s) instância(s) do grupo de autoscaling criado. Por fim, cria-se um alarme no CloudWatch que, quando este detectar que a instância que recebe o tráfego encaminhado no ELB não está respondendo, dispara um alarme, o qual chama o autoscaling para subir uma nova instância em substituição àquela não responsiva. Quando esta nova instância esta pronta, ela passa a receber o tráfego do ELB e aquela não responsiva é eliminada.

Tudo isso de forma 100% transparente para o usuário e automática. E nada precisa ser alterado, porque tráfego é sempre direcionado para o ELB. Com isso, o sistema estará sempre disponível. E se quisermos garantir que o sistema continuará no ar caso o datacenter todo caia, basta configurar que uma instância pode rodar em qualquer uma das availability zones (datacenter) de uma determinada região AWS e fazer com que o ELB enxergue todas estas zonas.

Resumo: mesmo com 1 única instância pode ser útil o uso de balanceador de carga e de autoscaling para garantir a resiliência s do sistema, serviço ou site web.

SAP startup forum no RS

A SAP, gigante mundial de sistemas ERP, no Brasil com sede em São Leopoldo/RS, está promovendo no próximo dia 4 de abril o “SAP Starup Forum”, com foco no banco de dados in memory chamado Hana. A empresa está apostando muito forte no Hana, tendo já uma plataforma como serviço de cloud computing para sua utilização, assim como tem uma oferta dele na nuvem da Amazon Web Services (AWS).

A ideia do evento é promover um espaço no qual empresas startups possam apresentar suas ideias de negócio envolvendo Big Data (volumes monstruosos de dados) e o banco de dados Hana. As ideias escolhidas como mais inovadoras e interessantes do ponto de vista de negócios da SAP terão espaço para apresentar suas propostas e, eventualmente, podem ser selecionadas para receber financiamento para o desenvolvimento do produto.

Além disso, o evento pretende também trazer mais conhecimento aos profissionais de TI sobre o banco de dados in memory SAP Hana, esclarecendo benefícios e cenários nos quais é vantajoso utilizá-lo.

Detalhes do evento em http://www.saphana.com/community/learn/startups/forums/sao-leopoldo.

Cloud Computing no SAP Forum Brasil

Está ocorrendo, entre os dias 19 e 21 de março, o SAP Forum Brasil, em São Leopoldo, Rio Grande do Sul. Neste evento da gigante mundial dos ERPs diversos assuntos, novidades e cases de parceiros estão sendo apresentados, com espaço também para discussões. Entre os temas centrais do evento estão o banco de dados em memória SAP Hana e também soluções SAP utilizando computação em nuvem. A Amazon Web Services (AWS), parceira na oferta de produtos SAP em nuvem, inclusive, está presente com diversas palestras e discussões.

Mais big players de cloud computing no Brasil

Quando falamos em cloud computing, e mais especificamente de serviços de infraestrutura (IaaS), imediatamente pensamos na Amazon Web Services (AWS). Entretanto, existem outros provedores bastante interessantes, tais como a Rackspace, Terremark, Joyent e Bluelock, só para citar algumas que estão listadas em um recente ranking das top 10 cloud providers.

Entretanto, fora a Amazon, todas as outras ofertas são de fora do Brasil. Até agora. Gigantes que não tem marketshare considerável em cloud estão de olho neste mercado e o Brasil parece ser um caminho estratégico para elas.

A aposta da Dell é em se diferenciar oferecendo não apenas infraestrutura, mas também o que está sendo chamado de custom service. A ideia é auxiliar o cliente em todo o processo de migração e operação da nuvem, desde o planejamento e contratação de serviços. Essa oferta ainda não está disponível no Brasil, mas em breve deve chegar.

A IBM, desde o ano passado, está com a SmartCloud sendo oferecida no Brasil. Os clientes podem optar pela nuvem pública ou pela nuvem híbrida (pública + privada), e escolher os recursos de hardware desejados, incluindo processamento, armazenamento, banco de dados, entre outros. Uma estratégia interessante da IBM para cloud é a “venda indireta”, ou seja, o cliente paga pelo licenciamento de software da IBM (Cognos, Tivoli, etc) e este roda na nuvem deles.

A HP também está já com algumas páginas da Nuvem Convergente e do HP CloudSystem traduzidas para o português. O ideia da HP é fornecer soluções completas de infraestrutura, mas também serviços de treinamentos (workshops) e consultoria, os quais ainda não estão disponíveis no Brasil.

Amazon Web Services com tudo nesse início de ano

O começo de 2013 da Amazon Web Services (AWS) está turbinado de lançamentos e novidades.

No final de 2012 foram anunciadas as instâncias de segunda geração Extra-Large (M3.XL, com 15GB de RAM e 13 ECUs) e Dupla Extra Large (M3.2XL, com 30GB de RAM e 26 ECUs). Inicialmente disponíveis somente nas regiões US-East, US-West-Oregon, US-West-California e EU-East (Irlanda), a partir do começo do mês de Fevereiro estes tipos de instâncias estão disponíveis também nas regiões SA-1 (South America, em São Paulo), AP-1 (Asia-pacific-1, em Cingapura), AP-2 (Asia-pacific-2, no Japão) e AP-3 (Asia-pacific-3, na Australia). Além disso, no início de Fevereiro houve uma redução no valor-hora de processamento de instâncias EC2 em todas as regiões, na ordem de 10 a 20%.

Também em fevereiro a AWS lançou o serviço de datawarehousing RedShift. Trata-se de um serviço gerenciado de warehouse, e em escala de petabytes. O Amazon Redshift gerencia todo o trabalho necessário para configurar, operar e dimensionar um cluster de warehouse de dados, do provisionamento de capacidade ao monitoramento e backup do cluster, à aplicação de patches e upgrades. Segundo a AWS, pode trabalhar com quase qualquer ferramenta de business inelligence (BI) existente no mercado.

O Redshift possui arquitetura de armazenamento colunar e compactação de dados para reduzir a quantidade de E/S para realizar consultas, e roda em hardware otimizado para datawarehousing, com armazenamento vinculado local e conexões de rede de 10 GigE entre nós. A arquitetura de processamento foi projetada para ser massivamente paralela. Os clusters do redshift podem ser compostos de instâncias extra large (XL) ou óctupla extra large (8XL).

Na semana passada, dia 19 de fevereiro, foi lançado mais um serviço, o Amazon OpsWork. Trata-se de uma plataforma visual, acessível pelo AWS Console, para provisionamento e gerenciamento de uma infraestrutura na nuvem AWS. É possível configurar a(s) instância(s) EC2 desejada(s), já indicando o tipo de uso que se fará dela(s), como por exemplo, servidor de aplicações Rails ou PHP, ou servidor de banco de dados, entre outros. Além disso, toda a política de auto scaling e o próprio deploy da aplicação e carga do banco de dados é feita através de um wizard, sem a necessidade de se fazer um script ou acesso via SSH. Pelo que deu para experimentar, é uma evolução do CloudFormation, para gerenciamento de um stack (pilha) de forma visual.