Plataforma Nuvem

Aplicativos baseados na Internet

Archive for maio 2011

Google aumenta a aposta no App Engine

leave a comment »

Semana de Google I/O é semana de anunciar novidades no App Engine. Este ano não deixou a desejar. A maior novidade é que o App Engine vai sair da fase beta e se tornar um produto pleno da Google.

Números impressionantes

A equipe do App engine anunciou dados como:

  • 100.000 desenvolvedores ativos usando o produto.
  • 200.000 aplicativos ativos.
  • 1,5 bilhão de páginas exibidas por dia.

Formatura

No segundo semestre de 2011, o App Engine deixará de ser um produto “Preview” para se tornar um produto oficial. Ele vai incorporar as funcionalidades da oferta “App Engine for Business”, que não decolou como eles esperavam, em parte porque o modelo de preços era voltado para usuários internos das empresas, em parte porque o status de beta não dava segurança para investimentos maiores. Entre as funcionalidades que serão incorporadas estão SLA de 99,95%, criptografia SSL, banco de dados SQL, suporte técnico, e garantia de compatibilidade de APIs por 3 anos.

Nova estrutura de preços

A plataforma será cobrada por métricas de uso, e não por aplicativo e por usuário, como na tentativa inicial. Haverá três faixas de preço:

  • Gratuita: sem custo mensal, sem SLA.
  • Paga: 9 dólares por mês por aplicativo. Inclui SLA.
  • Premium: 500 dólares por mês por conta (ou seja, por empresa) mais consumo.

Mais sério

As modalidades gratuita e paga terão cotas muito mais restritivas do que atualmente. Será suficiente para testes de desenvolvimento mas pouco para uso em produção. Na modalidade paga, será possível passar da cota e pagar pelo excesso, mas vai custar mais caro do que custa agora. Ao mesmo tempo estão sendo implantadas fortes restrições para envio de emails pelas contas gratuitas.

Além disso, cai o antigo modelo de métrica por tempo de CPU. A cobrança passará a ser no modelo taxímetro: por hora de instância ativa. O modelo incentiva, através de descontos, reservar instâncias por semana. O uso de serviços passará a ser por chamada, e não por tempo de CPU consumido, o que torna o modelo de preços mais previsível.

As novas modalidades de serviço e políticas de preço dão o tom: ou você usa a sério, ou não usa. Todas essas mudanças são voltadas para atender o novo público-alvo do App Engine: as grandes corporações. Os usuários menores, que ajudaram a testar o serviço, agora vão ter que gastar mais ou migrar suas aplicações.

Novidades

Enquanto a transição para a nova estrutura de serviços e preços está sendo preparada para o segundo semestre, foi liberada hoje a versão 1.5 da plataforma, com muitas novidades:

  • Backends, que são instâncias de longa duração. Neste modelo não há limites para o tempo de processamento de cada requisição. Isto vai permitir criar serviços que façam uso intensivo de processamento.
  • Pull Queues, uma modalidade de uso de fila de mensagens em que o consumidor busca as mensagens da fila, em vez de aguardar que a fila encaminhe as mensagens. A vantagem será uma maior agilidade no processamento das mensagens.
  • REST API para obter mensagens das filas, permitindo que serviços externos sejam integrados a aplicativos do App Engine através do sistema de filas de mensagens.
  • High Replication Datastore como padrão: o mecanismo de armazenamento de dados de alta disponibilidade, que tem um histórico de 99,999% no ar, passa a ser a opção preferencial. Além disso o preço foi reduzido de $0,45 por GB-mês para $0,24 por GB-mês.

Nova linguagem

Além das linguagens Python e Java, o App Engine passa a suportar em caráter experimental a linguagem Go, desenvolvida pela Google. Go é uma linguagem ágil, segura, rápida e que encoraja processamento concorrente. Agora esta nova linguagem poderá ser facilmente utilizada no App Engine, com acesso a uma série de serviços fornecidos pela plataforma. Uma das possíveis aplicações é utilizar a alta velocidade da linguagem para implementar aplicativos que utilizem intensamente a CPU.

  1. func handler(w http.ResponseWriter, r *http.Request) {
  2.     fmt.Fprint(w, "Hello, world!")
  3. }

Conclusão

Após anos de evoluções e ajustes, e após ouvir o feedback de grandes clientes corporativos, a equipe do App Engine está sentindo-se suficientemente confiante para colocar o App Engine em pé de igualdade com as ofertas da Microsoft (Windows Azure) e Amazon (AWS). Enquanto isso outros concorrentes como Oracle, IBM e VMware fortalecem cada vez mais suas ofertas.

Anúncios

Written by Fernando Correia

10/maio/2011 at 20:55

Publicado em Geral

Tagged with ,

RIA com Azure

leave a comment »

Aplicativos na nuvem, com a praticidade da web e a usabilidade do desktop. Esta é a proposta do conceito RIARich Internet application. Este modelo consiste em um aplicativo com interface rica executando no cliente comunicando-se com um web service executando em servidores na nuvem. O estado da sessão fica armazenado no cliente e os dados persistentes ficam armazenados em um banco de dados na nuvem (relacional ou não).

Em 2008 eu publiquei uma série de artigos descrevendo um projeto com esta arquitetura, utilizando Flex para o cliente com interface rica, Google App Engine como plataforma de nuvem, linguagem Python para o web service, o Datastore do App Engine para armazenar os dados, e o formato AMF para serialização de dados entre cliente e servidor.

Há muitas alternativas de ferramentas e tecnologias para implementar RIA. Uma combinação interessante seria JavaScript para o cliente com interface rica, Windows Azure como plataforma de nuvem, framework .NET para o web service, o Table Service do Azure para armazenamento, e o formato JSON para transferência de dados.

Arquitetura RIA com Windows Azure

Um web service no estilo REST pode ser implementado de diversas maneiras no Azure. Talvez a mais simples seja não implementá-lo: simplesmente publicar diretamente o Table Service para o cliente RIA. O Table  Service possui uma interface REST e permite acesso seguro utilizando autenticação. Os recursos disponíveis podem ser suficientes para várias aplicações, mas há limitações. Em primeiro lugar, o formato JSON não é suportado, o que vai exigir processamento adicional no cliente JavaScript para converter dados. Adicionalmente, para aplicações que necessitam de regras de negócio, validação, autorização granular, bilhetagem e, de modo geral, uma lógica de negócio e acesso a dados mais complexa no servidor, o acesso direto do aplicativo cliente não é o modelo mais eficaz.

Outra alternativa interessante seria o WCF Data Services, que já foi conhecido como “ADO.NET Data Services”, que já foi conhecido como “Astoria”. Esse é um framework muito interessante, que expõe dados na forma de entidades através de web services modelo REST, e que suporta o formato JSON. Muito promissor, e muito prático de usar em conjunto com o ADO.NET Entity Framework. Porém o Entity Framework não possui um provider para o Table Service do Azure. Também não existe um provider para o WCF Data Services compatível com o Table Service. Isto significa que seria necessário escrever um Data Service Provider.

CustomDataServiceProvider

O artigo sobre o assunto singelamente informa que “uma espiada na figura deveria convencê-lo que implementar um data service provider completo é um investimento significativo”. Se a advertência não for suficiente para abandonar a idéia, o fato é que implementar um WCF Data Service provider que use o Windows Azure Table Service é ainda mais complexo, porque o Table Service implementa apenas um subconjunto das funcionalidades necessárias. Investigações adicionais trarão informações como esta:

You’re asking for something we internally call “Astoria over Astoria” (Astoria was the code name for WCF Data Services). This doesn’t work out of the box, not even close. There are some really hard problems to solve and as of now it doesn’t seem to be 100% possible (the WCF Data Services client has different set of abilities than the server and some queries the server uses are not expressible in the OData protocol). [1]

This approach we call Astoria over Astoria, and it’s really hard to make it work correctly. You can see a sample code of how one could go about it in the OData Provider Toolkit. It’s under Experimental/AstoriaOverAstoria. But please do not use this in a production environment, it’s really meant as a sample only. [2]

Se o WCF Data Services não ajuda neste cenário, o WCF puro pode ser a solução. Certamente é possível criar um serviço WCF no modelo REST, e o WCF suporta o formato JSON. Por outro lado, WCF é uma solução grande, multi-tudo: multi-modelo de programação, multi-protocolo, multi-transporte, multi-formato…

WCF_Architecture

Sem dúvida é a forma mais recomendada para criar uma camada de serviços para aplicativos corporativos que precisam ser acessados das mais diversas maneiras, desde SOAP/XML sobre HTTP até TCP com serialização binária, passando por OData. Por outro lado é um framework complexo, com muitos conceitos, e algumas particularidades quando usado com formato JSON que dificultam a vida.

Se os requisitos forem mais simples, a solução também pode ser mais simples. Para um aplicativo RIA como o proposto aqui, o que é necessário é protocolo HTTP, formato JSON e um mecanismo de roteamento de URLs para implementar o modelo REST.

O ASP.NET MVC atende estes requisitos e oferece funcionalidades úteis como autenticação e modelo de programação MVC, sem cobrar um preço muito alto em termos de conceitos, complexidade, configuração e rigidez. É simples, flexível e compatível com mecanismos de testes unitários e inversão de controle.

O projeto RestfulMvcExample é uma prova de conceito minimalista que exemplifica a criação de um serviço no modelo REST usando formato JSON no ASP.NET MVC 3. Não é implementado um cliente RIA, mas há um teste integrado que simula chamadas ao serviço e exibe as respostas recebidas.

O núcleo do projeto é a classe ContactsController.cs, que é um controller, ou seja, é a classe que processa as requisições recebidas. Esta classe implementa 5 métodos no modelo REST:

  1. // Obtém todos contratos
  2. public ActionResult Index()
  3. {
  4.         var data = _repository.GetAll();
  5.         return Json(data, JsonRequestBehavior.AllowGet);
  6. }
  7.  
  8. // Obtém um contrato
  9. public ActionResult Get(int id)
  10. {
  11.         var data = _repository.Get(id);
  12.         return Json(data, JsonRequestBehavior.AllowGet);
  13. }
  14.  
  15. // Inclui um contrato
  16. public ActionResult Post(Contact contact)
  17. {
  18.         _repository.Add(contact);
  19.         return Json(contact);
  20. }
  21.  
  22. // Atualiza um contrato
  23. public ActionResult Put(int id, Contact contact)
  24. {
  25.         _repository.Update(id, contact);
  26.         return Json(contact);
  27. }
  28.  
  29. // Exclui um contrato
  30. public ActionResult Delete(int id)
  31. {
  32.         _repository.Delete(id);
  33.         var data = new { message = “Contact deleted.” };
  34.         return Json(data);
  35. }

O roteamento, ou seja, a chamada do método correto na classe correta com base na URL solicitada pelo aplicativo cliente, é feito pelo ASP.NET MVC com base nesta definição genérica no arquivo Global.asax.cs:

  1. routes.MapRoute(
  2.         “get-index”,
  3.         “{controller}”,
  4.         new { controller = “Home”, action = “Index” },
  5.         new { httpMethod = new HttpMethodConstraint(“GET”) }
  6. );
  7. routes.MapRoute(
  8.         “get-object”,
  9.         “{controller}/{id}”,
  10.         new { action = “Get” },
  11.         new { httpMethod = new HttpMethodConstraint(“GET”) }
  12. );
  13. routes.MapRoute(
  14.         “post-object”,
  15.         “{controller}”,
  16.         new { action = “Post” },
  17.         new { httpMethod = new HttpMethodConstraint(“POST”) }
  18. );
  19. routes.MapRoute(
  20.         “put-object”,
  21.         “{controller}/{id}”,
  22.         new { action = “Put” },
  23.         new { httpMethod = new HttpMethodConstraint(“PUT”) }
  24. );
  25. routes.MapRoute(
  26.         “delete-object”,
  27.         “{controller}/{id}”,
  28.         new { action = “Delete” },
  29.         new { httpMethod = new HttpMethodConstraint(“DELETE”) }
  30. );

A partir destas definições, mais a classe Model e seu respectivo repositório para gerenciar o acesso a dados, o serviço consegue responder a solicitações REST gerando dados no formato JSON como neste exemplo:

GET http://localhost:62983/contacts

  1. [{“Id”:1,“Name”:“Contact one”,“Email”:“one@example.com”,“Phone”:“555-1111”,“Href
  2. :“/contacts/1”},{“Id”:2,“Name”:“Contact two”,“Email”:“two@example.com”,“Phone”:
  3. “555-2222”,“Href”:“/contacts/2”},{“Id”:3,“Name”:“Contact three”,“Email”:“three@e
  4. xample.com”,“Phone”:“555-3333”,“Href”:“/contacts/3”}]

Esta prova de conceito demonstra que o ASP.NET MVC pode ser utilizado para criar web services REST/JSON com uma arquitetura simples e flexível. Funcionalidades como autorização e regras de negócio podem ser implementadas com código nas classes Controller e Model. Um maior controle da formatação das respostas pode ser obtido com a utilização de classes ViewModel nos controllers.

Os fontes estão disponíveis para download no site do projeto RestfulMvcExample.

Written by Fernando Correia

7/maio/2011 at 14:31

Publicado em Geral

Tagged with , , , , ,

Microsoft lança serviço de cache para o Azure

with one comment

O serviço de cache do Windows Azure (AppFabric Caching Service) foi liberado para produção no dia 28 de abril. Ele é um serviço de cache em memória distribuído que pode ser utilizado para acelerar a performance dos aplicativos no Windows Azure.

diag-caching

Os ganhos não são automáticos; os aplicativos precisam ser preparados para salvar e recuperar dados no cache. Os ganhos acontecem quando uma grande porcentagem das consultas são atendidas recuperando os dados da memória, sem precisar buscá-los em disco, nos serviços de armazenamento do Azure. Mesmo as funcionalidades automatizadas, como cache de sessão e de resultado das páginas, vão ser de benefício variável, conforme as características do aplicativo.

É um recurso inspirado no Memchached, um mecanismo de cache distribuído desenvolvido em 2003 e utilizado nos principais sites da Internet que lidam com grandes volumes, como YouTube, Facebook e Twitter. O Memcached já está disponível nos principais concorrentes do Azure, como o Amazon EC2 e o Google App Engine.

A Microsoft indica como vantagens da utilização do AppFabric Caching Service em vez do Memcached é que o desenvolvimento é facilitado pela maior integração com o .NET e que por ser oferecido como um serviço, dispensa esforço de instalação e administração.

O Facebook usa servidores com 16GB de memória para cache; a Amazon oferece instâncias de 17, 34 e 68 GB de memória. A Microsoft está oferecendo instâncias de cache entre 128 MB (!) e 4 GB. Na comparação de preço, a instância High-Memory Extra Large Instance da Amazon, com 17 GB de memória e 2 processadores, custa em torno de US$ 360 por mês. Por US$ 325 por mês a Microsoft está oferecendo uma instância de cache (incluindo o serviço de gerenciamento) com 4 GB de memória.

A notícia é boa; aplicativos web precisam de cache para ter bom desempenho, e profissionais do mundo Microsoft geralmente não tem familiaridade com serviços como Memcached. Como o AppFabric Caching Service é gerenciado pela Microsoft, é uma verdadeira solução plug-and-play, é só usar.

Como atrativo adicional, a Microsoft está oferecendo o serviço sem custos até o final de julho. Vale a pena conferir.

Written by Fernando Correia

2/maio/2011 at 20:58

Publicado em Geral

Tagged with ,