Usando cloud no EC2 da Amazon

Com a crescente popularidade do modelo Cloud Computing e da proposta da Amazon (como a plataforma EC2), tenho observado que varios fornecedores de software anunciam ofertas especificas para este ambiente. Entretanto, estes anúncios muitas vezes tendem a ser um tanto exagerados e acabam criando uma percepção um tanto enganosa para o mercado. Vamos analisar um pouco mais detalhadamente o que é a oferta EC2 da Amazon e validar se estas ofertas são realmente tão milagrosas assim.

 A plataforma EC2 oferece basicamente um ambiente virtualizado de servidores x86, suportado pelo sistema de virtualização Xen. Um servidor virtual ou uma instância (Amazon Machine Image ou AMI) é na verdade é uma imagem virtualizada de um servidor com sistema operacional como o Linux. Quando um fornecedor de software diz que suporta a plataforma EC2 ele está criando uma ou mais AMIs, adicionando seu software e os middlewares necessários. 

 Na imensa maioria das vezes estas ofertas são os mesmos softwares que rodam em servidores x86 tradicionais, com pequenas alterações para suportar os sistemas de arquivos da Amazon (Elastic Block Store, EBS) ou S3 (Simple Storage Service). Isto é necessário, pois ao contrário dos servidores tradicionais, uma AMI não embute automaticamente persistência em disco. Além disso, o software pode ser otimizado para rodar no EC2, como por exemplo considerando que os discos virtuais (S3, por exemplo) não são locais e portanto demandam latência tipica de discos remotos. Também,  uma vez que a Amazon cobra por numero de operações de I/O no EBS, otimiza-se o código diminuindo a demanda do software aos discos. Taí uma boa questão: o fornecedor ao dizer que suporta EC2 está fazendo alguma otimização para este ambiente ou está deixando o software exatamente como funciona nos servidores fisicos?

 Outra carateristica tipica do EC2 é que a escalabilidade da Amazon é horizontal, ou seja, abre-se mais instâncias. Mas, de maneira geral os softwares tradicionais aumentam sua escalabilidade através de mais recursos computacionais da mesma máquina, ou seja explorando a capacidade de servidores de maior potência. O problema é que a Amazon, ao detetar que a utilização de CPU de uma determinada instância atingiu um limite determinado, abre automaticamente uma nova instância. O efeito prático é o de instalar um novo servidor fisico quase instantaneamente. A questão é: o software consegue tirar proveito deste novo servidor? Na verdade estamos concluindo que colocar uma aplicação no EC2 não a torna automaticamente uma aplicacao “cloud”, mas sim que ela usa uma infraestrutura em cloud. A escalabilidade da infraestrutura não se reflete automaticamente na escalabilidade da aplicação.

 Outro aspecto que nem sempre é “lembrado” nas ofertas dos fornecedores: que modelo ou modelos de licença são adotados? Aí podemos ter vários tipos, como licenças voltadas para usos exploratórios, ou seja, propostas para testar o software no ambiente de cloud, mas sem permissão ou condições para uso em produção, ou licenças específicas para o EC2, como cobrança por instância e/ou por tamanho da AMI. Recomendo olhar as licenças com atenção, para evitarmos surpresas nos custos de propriedade.

 E já que falamos em custo de propriedade (TCO), sugiro enfáticamente avaliar o TCO da solução EC2 versus o modelo tradicional. Apenas pelo fato de estar na Amazon não garante à empresa que seus custos de TI serão menores. Instâncias virtuais não tem capex (capital expenses), como servidores físicos, mas dependendo de como serão gerenciadas e das licenças de softwares adotadas, podem até apresentar opex (operating expenses) mais elevados.

 Um bom exemplo de flexibilidade no uso da plataforma EC2 da Amazon é o da IBM. Vejam em http://aws.amazon.com/ibm/ .

 Mas, é indiscutível que o modelo de cloud computing ainda é um work in progress e a cada dia aprendemos um pouco mais. Recentemente a Amazon criou uma oferta bem interessante chamada de Spot Instances. A idéia é simples: a Amazon faz leilão automático de recursos computacionais. Se a demanda pela nuvem da Amazon diminui, os recursos tendem a baratear. Caso aumentem, os recursos tornam-se mais caros. É uma estratégia de precificação dinâmica. Funciona assim: baseada na lei da oferta e procura a Amazon determina um valor mínimo para as intâncias. Estes preços flutuam livremente, de acordo  com a demanda, influenciados, por exemplo, pela hora do dia.  O usuario dá seu lance. Se o seu lance é maior que o preço esperado pela Amazon, a instância é alocada a ele, que pode começar a executar. Quando o preço da instância torna-se maior que o lance oferecido, a instância é suspensa e só volta a rodar quando o lance se tornar maior novamente. Toda a operação é automática. Claro que esta oferta só vale para determinados tipos de aplicação, que não sejam dependentes de tempo.

 O que isto sinaliza? Que ainda estamos dando os primeiros passos de novos e inovadores modelos de negócio em cloud, quebrando a mesmice dos modelos atualmente praticados. Teremos dias bastante interessantes.

Um pouco do GAE (Google Application Engine)

Ultimamente tenho recebido alguns emails indagando minha opinião sobre o GAE (Google Application Engine) e sua aplicabilidade em ambientes corporativos. Então, para começar, vamos detalhar um pouco o que é o GAE e suas funcionalidades. O GAE é a oferta do Google para a camada de cloud computing que chamamos de PaaS ou Platform-as-a-Service. O GAE se propõe a criar uma plataforma para desenvolvimento e execução de aplicativos Web, que rodarão na nuvem do próprio Google.

 É uma tecnologia bastante recente, apresentada ao mercado em abril de 2008, tanto que com algumas exceções, como o Google Moderator (http://moderator.appspot.com/), as aplicações do próprio Google Apps não foram escritas usando o GAE.

 A integração com sistemas on-premises é feita via um recurso chamado SDC (Secure Data Connector), mas que é viável apenas para integrações relativamente simples. Na verdade, a estratégia do Google tem sido claramente bottom-up, oferecendo o GAE basicamente para desenvolvedores, sem propor seu uso para ambientes corporativos. A sua proposição de valor não tem alcançado os CIOs ou CTOs das grandes corporações. Aliás, o DNA cultural do Google não é voltado para grandes empresas e sim para usuários finais e desenvolvedores.

 Mas, o que o GAE propõe aos desenvolvedores? Que eles construam e testem suas aplicações em máquinas locais (fazendo o download do AppEngine Software Development Kit) e uma vez tendo a aplicação pronta, com um simples upload, torná-la disponível diretamente da nuvem do Google. Estas aplicações podem estar abertas ao mundo todo ou serem limitadas apenas aos funcionários de sua empresa. Existe um domínio especifico para estas aplicações, chamado appspot.com, onde a aplicação pode ter qualquer nome que o usuário deseje.

 Uma caracteristica interessante do modelo GAE é que o custo para começar a usá-lo é zero. Todas as aplicações podem usar uma quota de até 500 MB de memória e um razoável tempo de CPU, bem como  atender até 5 milhões de page views por mês, sem pagar absolutamente nada. Mas o consumo de recursos acima das quotas vai obrigar ao que o usuário pague os excedentes ao Google.

 Existem vantagens e desvantagens. Com o GAE o desenvolvedor não precisa se preocupar com questões como disponibilidade de middleware ou gerenciamento do sistema. Estas facilidades são disponibilizadas de forma automática e transparente para os seus usuários.

 Por outro lado, algumas restrições incomodam, como por exemplo, a possibilidade de se apenas escrever programas em Python e Java (até agora nada se falou em PHP ou Perl…), voltadas para Web, e que devem retornar resultados em  uma janela de tempo de 30 segundos. Se a aplicação demorar mais, o request é encerrado e a nuvem retorna um código de erro ao usuário. Outra restrição é o numero de resultados que podem retornar em resposta a uma query: máximo de 1000. 

 Também a ausência de uma base de dados relacional é outra restrição bem desconfortável. A persistência dos programas GAE é feita via BigTable, sistema de banco de dados não relacional, que suporta a própria estrutura de dados da nuvem do Google. Embora o BigTable seja amplamente escalável, é otimizado para operações de leitura, típicas dos acessos do motor de busca do Google.  O acesso ao BigTable é efetuado por um conjunto de APIs que não suportam a linguagem SQL. Além disso, por não ter visão relacional, deixa a validação da integridade dos dados a cargo do desenvolvedor.

Outro ponto negativo é que o GAE não suporta aplicações baseadas no estilo SOA (Service Application Architecture), no qual existe uma clara separação entre as camadas de software através de interfaces formais e abertos. SOA é fundamental para integração entre sistemas e o GAE, não suportando padrões SOAP e WSDL cria um grande entrave, pois não se imaginam aplicações corporativas, salvo raras exceções, que não tenham grande demanda de integração com outras.

 Na minha opinião, estas restrições impedem que uma aplicação GAE evolua para ser corporativa e integrada a ambientes legados. Além disso, ainda não existem casos práticos de uso em aplicações corporativas e eu, pessoalmente, recomendo que o GAE seja usado, pelo menos por enquanto, apenas para aquelas novas e pequenas aplicações Web de âmbito departamental ou stand-alone, sem integração com aplicações legadas.

Mais um pouco de Cloud Computing

Nas duas últimas semanas participei de algumas entrevistas com a midia abordando Cloud Computing. E este mesmo tema foi assunto dominante de algumas reuniões com executivos de empresas clientes. A conclusão óbvia é que o tema está bombando. Que tal então, resumirmos um pouco do que debatemos? 

 Na minha opinião, Cloud Computing vai se tornar mainstream em 3 a 5 anos, mas enquanto isso muitas pedras terão que ser retiradas do caminho. Hoje, por exemplo, ainda não vejo uma clara percepção de seus beneficios e mesmo restrições por parte de muitos executivos de TI. A percepção de valor da computação em nuvem ainda não está clara para muita gente.

O problema deste ainda “desconhecimento” é a possibilidade de empresas embarcarem em projetos de cloud que poderão ser custosos em tempo e  investimento, sem conseguirem obter os resultados desejados. Aliás, já vimos este filme antes. Quando o cliente-servidor surgiu, várias empresas afoitadamente desligaram seus mainframes, sem uma estratégia adequada para uso e gestão da computação distribuida. O resultado foi um TCO muito alto e inesperado…

 O que venho abordando nas reuniões é que o valor da computação em nuvem seja claramente percebido, antes de iniciar qualquer projeto mais abrangente. Disparar um projeto de prova de conceito (proof-of-concept) é uma boa estratégia para se consolidar estas percepções. Recomendo, portanto, um projeto POC.

 Venho observando também que os executivos de TI tendem, na média, a serem mais cautelosos que os executivos das áreas de negócio quanto ao uso da computação em nuvem. Sua percepção de valor muitas vezes concentra-se na redução de custos (infra e suporte) e de capex (investimentos em capital). Em muitas das conversas identifiquei que nem sempre estão buscando serem proativos na estratégia de cloud.

 Por sua vez, os usuários com quem venho falando mostram-se mais animados e olham a computação em nuvem (principalmente Software-as-a-Service ou SaaS e Infrastructure-as-a-Service ou IaaS) como uma boa alternativa para conseguirem mais agilidade e flexibilidade para seus projetos de TI. Provavelmente, alguns destes executivos estão mais concentrados em obter resultados de curto prazo e nem sempre consideram adequadamente os problemas típicos de TI, como a integração entre os sistemas em nuvem e os legados, ou mesmo a possibilidade de um “platform lock-in”  devido a atual ausência de padrões de interoperabilidade entre as nuvens.

 Uma dúvida sempre presente é a possibilidade da computação em nuvem permitir o processamento de aplicações de negócios, como ERP e outros sistemas. Claro que aplicações que não demandam integração, em princípio, não apresentarão maiores problemas para rodarem em nuvens. Serão as primeiras a rodarem em nuvem. Uma olhada rápida no diretório do Force.com (AppExchange) já nos mostra diversas aplicações interessantes e para mim é apenas a ponta do iceberg do que veremos nos próximos anos. Neste diretório vocês verão, inclusive, uma solução da Totvs, para gestão de frotas. Interessante vermos que o Force.com já aponta novas funcionalidades provocada pela flexibilidade gerada pela computação em nuvem, como a sinergia entre aplicações de negócios e as redes sociais. É o exemplo o “Chatter”, plataforma que pemite aos usuários do Force.com a compartilharem aplicações de negócios, como um CRM,  com redes sociais, criando SRM (Social Relationship Management)

 Mas as aplicações que demandam integração com outros sistemas, principalmente sistemas legados que operam fora do modelo de cloud computing, devem ainda serem vistos com cuidado redobrado. De qualquer maneira já temos muitos casos de sucesso em CRM (exemplo do Salesforce) e algumas primeiras iniciativas de sistemas ERP (Compiere, um sistema open source, NetSuite e a brasileira Zipline). Na minha opinião a adoção de ERP no modelo de computação em nuvem será adotado, em princípio, por empresas de pequeno porte, devido a sua alta sensibilidade à custos. Cloud Computing tem a possibilidade de mudar de forma radical a maneira como as pequenas empresas adquirem e usam tecnologia. Em vez de equipes pequenas e subdimensionadas, com poucos servidores, nem sempre configurados e gerenciados da forma mais adequada, poderão ter como unico staff seu próprio gestor de TI e com toda a infra de hardware e software residindo em nuvens públicas.

 Já as grandes corporações não deverão adotar de forma entusiástica o modelo de computação em nuvem para seus sistemas ERP, pelo menos nos próximos 3 anos. Depois, só bola de cristal…mas, não será fantasioso vermos os principais fornecedores de ERP oferecendo versões em nuvem ao lado do modelo tradicional, on-premise. A estratégia deles será, naturalmente, fazer uma migração lenta e gradual. Uma disrupção afeta seus modelos de negócio atuais e como os seus clientes, grandes corporações, também não são adeptas de rupturas, o acordo tácito entre as duas partes vai direcionar o ritmo de adoção da computação em nuvem para estas suites.

 Algumas conclusões…Primeiro computação em nuvem não deve ser vista apenas pela ótica de redução de custos, mas os benefícios potenciais das áreas de TI permitirem mais agilidade e flexibilidade aos usuários devem ser considerados com atenção.

Outra conclusão: as áreas de TI não devem ignorar ou subestimar a  pressão que os usuários, logo que perceberem o valor da computação em nuvem farão.

Quanto aos ERP. A situação de hoje não pode ser cristalizada, como em uma foto. A evolução do mercado e a mitigação de eventuais problemas que impedem uma empresa de migrar para um ERP corporativo em nuvem vai acontecendo a cada dia. Sugestão: olhar o cenário dos sistemas ERP em nuvem não como uma foto mas como um webcast.

 E finalmente: computação em nuvem não deve ser um projeto específico de TI nem exclusivo dos usuários, de forma independente. É uma mudança no modelo computacional da empresa e portanto, um projeto corporativo. E, importantíssimo, não pode haver desconexão entre TI e seus usuários.

Entrevista na TI Digital

Recentemente concedi longa entrevista sobre Cloud Computing para a revista TI Digital de fevereiro, que pode ser acessada em http://tinyurl.com/y96oqep.

Cloud Computing vai repetir o fenomeno cliente-servidor?

Em um post anterior lembrei que a curva de adoção do Cloud Computing me lembrava a do cliente-servidor, que aconteceu no início dos anos 90. Hoje vou voltar ao assunto, detalhando um pouco mais a idéia e quem sabe, conseguiremos tirar algumas lições do passado. É sábio não cometer os mesmos erros…

 Quando o modelo cliente-servidor surgiu, vimos no início, uma reação negativa muito grande por parte dos setores de TI. Por outro lado, surgiu um movimento muito intenso das áreas usuárias em buscarem soluções neste modelo, bypassando a própria TI. O modelo c/s prometia romper com o monopólio da área de TI, permitindo que os usuários, livres da burocracia e demoras nas respostas dos data centers centralizados, buscassem por conta própria suas soluções.

 O que aprendemos após mais de uma década usando o modelo c/s? Hoje é fácil dizer que os dois lados assumiram posições erradas. A área de TI por inicialmente negar ou ignorar o modelo c/s em seu inicio. E as áreas usuárias por o adotarem de maneira afoita, sem uma visão mais abrangente de seus impactos ao longo do tempo. O problema é que na época era dificil dizer quem estava com a razão…

 O resultado é que as expectativas de redução de custos não foram alcançadas, por uma razão muito simples. No início, concentrou-se a discussão exclusivamente no custo de aquisição e não no custo de propriedade. Depois é que descobrimos que manter sistemas distribuídos era muito caro. Além disso, o ativo era mal utilizado, causada pela ociosidade muito grande dos servidores. Surgiram movimentos direcionados ao uso mais racional dos recursos computacionais, como disseminação da virtualização e projetos de consolidação de servidores e data centers. Inúmeros outro efeitos colaterais surgiram com o uso do modelo c/s, como maiores vulnerabilidades e proliferação de sistemas incompatíveis entre si, criando ilhas de informação e automação, gerando problemas seríssimos de integração e custos elevados de suporte e upgrades. Por outro lado o modelo c/s trouxe beneficios incomensuráveis, como maior popularização no uso de TI e uma maior aproximação da própria TI com o negócio. 

 E chega a Cloud Computing com suas promessas de romper com os modelos computacionais atuais, permitindo que os usuários possam bypassar suas áreas de TI, adquirindo soluções por si mesmo, soluções que irão residir nas nuvens dos seu provedores. Acende-se um sinal de alerta: Cloud Computing tem o potencial de criar impactos muito maiores que os criados pelo c/s. Isto significa que se repetirmos os mesmos erros quando da adoção de c/s, os problemas gerados serão muito mais significativos.

 O que os setores de TI devem fazer? Quando ignoraram o c/s, permitindo que as áreas usuárias criassem seus próprios sistemas departamentais, geraram ilhas isoladas de automação, com os inevitáveis problemas de integração. Não podemos repetir os mesmos erros. Ignorar o modelo Cloud Computing é fomentar um imenso problema futuro, pois Cloud Computing vai entrar nas empresas, queira ou não queira a área de TI.

 Algumas recomendações simples:

 a) Desenhar uma estratégia de Cloud Computing que oriente os usuários a selecionarem as ofertas de nuvens e SaaS, observando questões de segurança e integração com os sistemas legados.

b) Apoiar os usuários na negociação de niveis de serviço e na seleção de provedores de nuvens. Nos próximos anos, Cloud Computing vai ser o termo hype do momento e qualquer provedor que oferte um simples “collocation” vai rotular seus serviços de Cloud Computing. Cuidado com as armadilhas!

c) Implementar nuvens híbridas, adotando nuvens públicas e privadas de acordo com as características dos workloads. Lembro que não será fácil, pelo menos por enquanto, integrar as aplicações que rodam nas nuvens públicas com os sistemas que irão operar em nas nuvens privadas.

d) Implementar tecnologias e modelos de governaça adequados para a gestão das nuvens, sejam elas públicas, privadas e híbridas. Um exemplo: ao adotar uma nuvem pública, a equipe técnica não precisará mais se preocupar com detalhes de hardware e sistemas operacionais. Portanto seus skills deverão ser focados na gestão dos processos e não nas tecnologias.

 Para estes desafios, a área de TI deve estar preparada, capacitando seus técnicos e explorando o modelo Cloud Computing o mais cedo possivel.

Google ou Amazon?

Em um dos inúmeros eventos de Cloud Computing em que apresentei uma palestra, surgiu uma pergunta interessante por parte de um CIO de uma pequena empresa: “Na minha opinião, qual seria a melhor opção em Cloud Computing, Amazon ou Google?”.

A resposta é simples: “depende do que se pretende fazer com computação em nuvem, porque Amazon e Google tem propostas de cloud computing muito diferentes”.

 O Google oferece o Google Applications, oferta de SaaS e o Google Application Engine (GAE, www.appengine.google.com ), que é um serviço de PaaS (Platform-as-a-Service). A Amazon oferece um serviço de IaaS (infrastructure-as-a-Service), chamado de AWS (Amazon Web Services, http://aws.amazon.com/) que é uma oferta de recursos de infraestrutura. Na Amazon para se conseguir elasticidade automática e um serviço de PaaS é necessário utilizar componentes adicionais oriundos outros fornecedores. Estes componentes são fornecidos como AMI (Amazon Machine Image), como o IBM WebSphere sMash, para desenvolvimento de aplicações situacionais (http://tinyurl.com/y9m2tha). A Amazon criou um ecossistema de parceiros que disponibilizam diversos recursos complementares à sua oferta. Existem cerca de 450.000 desenvolvedores gravitando em torno deste ecossistema. Assim, por exemplo, quando se desjea facilidades de elasticidade automática pode-se recorrer à RightScale (http://www.rightscale.com/ ) ou Elastra (http://www.elastra.com/). A IBM disponibiliza diversos softwares como AMI na Amazon, cuja lista completa e instruções para download podem ser obtidas no developerWorks Cloud Computing Resource Center em http://tinyurl.com/ycounhf .

Um dos recentes anúncios da Amazon foi a facilidade de se criar Virtual Private Clouds, usando a sua nuvem pública. Este recurso, chamado VPC, é uma demanda de empresas que questionam questões de segurança em nuvens públicas, e que pode ser visto em http://aws.amazon.com/vpc/.

 Já a proposta de valor do GAE é permitir que desenvolvedores criem aplicações Web muito rapidamente (em suas estações de trabalho) e as coloquem para operar na nuvem do Google. O custo para rodar a aplicação é “free”, sim, grátis, até cinco milhões de page views por mês. A partir deste volume, é cobrado um valor por recursos computacionais utilizados.

 O GAE permite que os desenvolvedores construam e testem suas aplicações em um ambiente simulado (como Linux e Windows), que suportem versões das linguagens Python e Java. Para colocar o aplicativo em produção usa-se um script de upload que transfere o código fonte para os servidores da nuvem do Google, de onde a aplicação rodará. O GAE utiliza a mesma infraestrutura de hardware e software do engine de buscas do Google. Os desenvolvedores não tem acesso direto a estes recursos, pois existe uma camada de interface entre a aplicação e a nuvem. Os recursos disponiveis à aplicação são o Big Table (mecanismo de persistência não relacional), Google File System (sistema de arquivos distribuidos) e uma variante do Linux adaptada pelo Google. O site IBM developerWorks disponibiliza diversos artigos sobre  como usar o GAE. Vejam em http://tinyurl.com/yde7qk9 .

 Estima-se que existam mais de 300.000 desenvolvedores gravitando em torno do GAE, mas as aplicações que estão sendo atualmente escritas são de pequeno porte, departamentais.  Embora a nuvem do Google permita que uma aplicação possa escalar de forma automática para milhões de  page views e milhares de usuários, os temores quanto às condições de segurança, disponibilidade e privacidade de nuvens abertas, como a do Google, são ainda fatores restritivos.  Assim, na minha opinião, e o que respondi a ele com relação ao GAE é considerar esta alternativa apenas para novas aplicações de pequeno porte, escritas em Java ou Python, desenvolvidas por equipes pequenas, estilo “agile development”. Deverão ser aplicações stand-alone (embutidas em si mesmo, sem integração com aplicações legadas). Nem pensar em considerar o GAE para migrar aplicações corporativas legadas, que constituam a base do suporte ao negócio.

 Por sua vez recomendo a nuvem da Amazon para aplicações “one-way”, aquelas que voce vai usar uma ou pouquissimas vezes e para as quais não compensa contratar mais recursos computacionais. Também pode ser usada como infraestrutura para pequenas empresas que não tem budgets para manter uma estrutura fisica de TI interna ou mesmo para aplicações situacionais de grandes empresas que não tenham necessidade de maiores integrações com sistemas legados. O AWS permite utilização de aplicações convencionais, pois na prática simplesmente simula servidores fisicos através de virtualização. Entretanto, ainda não está adequada para suportar aplicações de missão critica da maioria das grandes empresas.

 No developerWorks vocês podem ver diversos artigos sobre o uso da AWS da Amazon. Recomendo olhar a série de papers “Cloud Computing with Amazon Web Services”, no site IBM developerWorks, em  http://tinyurl.com/ya7lop2 .

 Em resumo,  vimos que Amazon e GAE tem aplicabilidades diferentes e não são necessariamente excludentes. Podemos até utilizar simultaneamente as duas alternativas.