O PaaS é um tipo de serviço em nuvem em que o provedor fornece não só o hardware on demand e os serviços de sistema operacional, mas também plataformas de aplicativos e pilhas de soluções. Os serviços de PaaS automatizam a maioria dos aspectos de gerenciamento de TI associados à implementação de aplicativos, incluindo alocação de recursos, preparação e teste, equilíbrio de carga, acesso a banco de dados e acesso a bibliotecas de plataforma. Um dos principais recursos do PaaS é a arquitetura de multilocação: diversos aplicativos não relacionados podem executar na mesma infraestrutura de hardware e software, tendo como resultado economias de custo e o uso mais eficiente dos recursos de computação. Os desenvolvedores podem se focar no aplicativo em si, e não nos problemas de implementação e TI.

Os desenvolvedores de Java estão bem posicionados para aprender o modelo de desenvolvimento PaaS e aproveitá-lo. Afinal de contas, o conceito de PaaS está profundamente enraizado nos primeiros dias do Java no lado do servidor. Naquela época, as organizações de TI tinham a visão de usar aplicativos de servidor como "contêineres" e, em seguida, incluir archives de aplicativo para executar em um ambiente de recursos compartilhados (consulte o precursor do PaaS ). Essa visão é muito semelhante à dos serviços de PaaS que vemos atualmente.

No entanto, a visão inicial do PaaS em relação aos aplicativos corporativos Java não teve êxito. Os servidores de aplicativos Java nunca se tornaram suficientemente estáveis para implementar e "desimplementar" à vontade vários aplicativos não relacionados. A estrutura de archive acabou aumentando a sobrecarga do ciclo de desenvolvimento de aplicativos Java: ao passo que os desenvolvedores de PHP e Ruby on Rails podiam alterar uma linha de código e recarregar o navegador para ver a diferença, os desenvolvedores de Java tinham que recompilar, reempacotar e reimplementar os seus aplicativos e, frequentemente, até reiniciar o servidor de aplicativos.

Ao que parece, a visão do PaaS só se concretiza com o surgimento de uma nova geração de tecnologias de virtualização muito mais avançadas que a JVM. Com o pioneirismo do Google App Engine, a nova geração de serviços de PaaS Java cumpre a antiga promessa do Java EE. Além disso, fornece infraestruturas de TI que são pagas conforme a necessidade e aumentam junto com a demanda, sem a necessidade de um investimento inicial em recursos caros de hardware e administração de sistemas.

Neste artigo, examinarei três das maiores ofertas de PaaS público em Java para comparar suas abordagens e seus pontos fortes e fracos. As três fornecem o mesmo conjunto básico de recursos, que inclui:

• Upload e implementação de WARs de aplicativos
• Versões dos aplicativos implementados
• Ambientes de teste e preparação
• Acesso on-line aos arquivos de log
• Relatórios de uso e monitoramento automatizado

Entretanto, além desses recursos comuns, existem algumas diferenças importantes. Com base em minha própria experiência de trabalho com essas tecnologias emergentes, oferecerei um framework para compará-las e tratarei de possíveis soluções alternativas para ajudá-lo a evitar problemas ao usá-las.

Google App Engine

O Google App Engine (GAE) é a primeira plataforma de PaaS Java adotada amplamente. (A versão Java às vezes é denominada GAE/J, para diferenciar da oferta de PaaS do GAE que é baseada em Python). Além disso, provavelmente é a oferta de PaaS mais "pura" do mercado — no sentido de que faz uma abstração quase total entre a infraestrutura subjacente e os desenvolvedores.

Java, mas não exatamente Java

O GAE suporta a plataforma Java como ambiente de desenvolvimento e implementação desde 2009. Entretanto, o suporte do GAE para Java é limitado e incompatível com os padrões. Por causa das várias restrições que ele impõe aos seus aplicativos — muitas delas por boas razões, para manter a escalabilidade — o GAE não suporta certas APIs da plataforma Java, principalmente, E/S de gravação de arquivo (pois o GAE não fornece um sistema de arquivos acessível aos aplicativos) e várias APIs de E/S de rede (pois o GAE impõe limitações graves às operações de rede originadas a partir desses aplicativos). Consulte Recursos para ver uma lista completa de APIs de plataforma Java aprovadas, que são suportadas pelo GAE.

Ao suportar sua própria API limitada de E/S de rede, o GAE restringe a capacidade que o arquivo tem de conectar-se a outros serviços. O GAE permite nominalmente que os aplicativos façam conexões de saída a outros servidores. Entretanto, em um esforço para manter sob controle o número de encadeamentos do sistema, o GAE força qualquer conexão iniciada por aplicativos a fechar depois de 5 a 10 segundos. Isso faz do GAE uma plataforma não confiável para aplicativos do tipo mashup. Essa é uma limitação importante do GAE para o número cada vez maior de aplicativos que usam APIs de aplicativos da Web de terceiros.

Alem disso, essas limitações de APIs impõem desafios quando há necessidade de usar frameworks de aplicativos já existentes ou mover aplicativos já existentes para o GAE. Depois de anos de evolução, o desenvolvimento corporativo em Java é muito dependente de frameworks. Embora alguns frameworks bastante conhecidos, como o Spring e o Struts, funcionem no GAE de fábrica, muitos outros não funcionam ou requerem patches no código de origem. Hackear manualmente o código de origem do framework para fazer com que ele execute no GAE nunca é uma boa ideia, porque você está basicamente criando uma bifurcação que quebra a compatibilidade de envio e pode apresentar erros difíceis de depurar no framework. Um bom exemplo é o framework do Web JavaServer Faces (JSF): ele requer o hackeamento no nível do código de origem para executar no ambiente do GAE e, mesmo assim, muitas bibliotecas de UI baseadas no JSF são incompatíveis com o GAE. (Consulte Recursos para ver uma lista de frameworks Java suportados pelo GAE).

Além disso, é provável que grandes aplicativos corporativos que já estejam desenvolvidos usem APIs que o GAE proíbe. A migração desses aplicativos para o GAE pode ser cara, porque é necessário não só identificar os problemas e criar soluções alternativas, mas também refazer a garantia de qualidade em todo o aplicativo.

Ao não suportar parte da API da plataforma Java, o GAE não cumpre a proposta do Java de "escrever uma vez, executar em qualquer lugar". Para muitas pessoas, isso não é motivo para não usar o GAE, mas é algo que possíveis usuários devem saber.

Escalabilidade e desempenho

O GAE promete escalabilidade e cumpre, mas não proporciona necessariamente desempenho bruto. O desempenho bruto para aplicativos da Web é medido pelo tempo de resposta a uma solicitação da Web. A escalabilidade designa a capacidade que a plataforma tem de manter um tempo de resposta consistente, independente da quantidade de usuários que estejam acessando o sistema. Por exemplo, um sistema escalável com um tempo de resposta de 3 segundos para 100 usuários simultâneos deve ter um tempo de resposta de 3 segundos para 1 milhão de usuários simultâneos.

O GAE fornece escalabilidade excelente, medida por um tempo de resposta consistente. Entretanto, o seu desempenho bruto é frequentemente lento. Em minha própria experiência anedótica, o GAE frequentemente leva de 1 a 3 segundos para responder a solicitações relacionadas a banco de dados.

Essa característica tem implicações óbvias para desenvolvedores de aplicativos. No caso de aplicativos da Web que ficam ociosos na maior parte do tempo (ou seja, a maioria dos aplicativos da Web pequenos), a implementação na infraestrutura do GAE não proporcionaria benefícios de desempenho nem mesmo em um servidor privado virtual com poucos recursos. O verdadeiro benefício de desempenho ocorre quando há necessidade de escalar o aplicativo em massa, muito além da capacidade do hardware do servidor com poucos recursos.

Outro problema de desempenho dos Web sites de baixo tráfego é o fato de que o GAE troca JVMs inativas sem memória para se otimizar para os aplicativos da Web com tráfego alto no sistema. Se sua JVM é trocada sem memória, o GAE precisa empregar mais tempo para iniciar todo o seu aplicativo na próxima vez que uma solicitação entrar. No caso dos aplicativos da Web com tráfego baixo, isso pode causar lentidão (tempo de espera de mais de cinco segundos para uma primeira solicitação). O GAE oferece uma opção para que os desenvolvedores paguem e mantenham a JVM inativa na memória para obter um desempenho mais consistente. Uma dica: configure uma tarefa de cron dentro do GAE para carregar o seu próprio Web site a cada 2 a 3 minutos para manter a JVM ativa.

Benefícios e limitações do BigTable

Uma das principais inovações do GAE é o uso de um armazenamento de dados verdadeiramente escalável: o Google BigTable. A maioria dos aplicativos da Web usa bancos de dados relacionais como backends de dados. Entretanto, é notório que os bancos de dados relacionais são difíceis de escalar. Para resolver esse problema, os pesquisadores da Google desenvolveram uma solução alternativa de armazenamento de dados chamada BigTable, uma das soluções de armazenamento de dados no universo dos bancos de dados NoSQL.

Como em um banco de dados relacional, os dados no BigTable podem ser organizados em tabelas com linhas e colunas, e cada linha tem um ID exclusivo indexado. Ao contrário dos bancos de dados relacionais, as tabelas do BigTable não possuem um esquema fixo e são tipicamente desnormalizadas. Cada linha de uma tabela pode ter colunas diferentes. A boa prática é ter várias colunas em uma linha, em vez de vincular linhas diferentes ao longo de tabelas diferentes por meio de colunas de chave. Isso tem grandes implicações no design dos modelos de dados. Em vez de projetar um modelo relacional normalizado, recomenda-se que os desenvolvedores de aplicativos coloquem informações redundantes em cada linha para facilitar a recuperação. Pense no log de acesso de um servidor da Web no qual o endereço IP e o agente do navegador sejam repetidos em cada linha, algo que ocupa espaço, mas simplifica o processamento de grandes volumes.

O benefício do BigTable é a escalabilidade. Os engenheiros da Google afirmam que o tempo de resposta das consultas de dados no BigTable só é determinado pelo tamanho do conjunto de dados do resultado. Você obtém o mesmo desempenho, não importando se a consulta é feita em uma tabela de 1.000 linhas ou de 10 milhões de linhas, desde que o resultado esteja limitado a 1.000 linhas. Por sua vez, o GAE limita o conjunto de dados retornado de cada consulta a 1.000 linhas.

Adaptar-se ao paradigma NoSQL é uma qualificação importante, e um número cada vez maior de organizações de TI está enfrentando o desafio do Big Data, embora isso possa ser desafiador para os desenvolvedores com experiência em SQL. Constatei que o GAE é um dos melhores e mais fáceis meios para que os desenvolvedores de Java comecem a aprender o NoSQL.

Entretanto, embora o BigTable seja fundamental para a escalabilidade em massa do GAE, sua implementação atual deixa muito a desejar em relação aos desenvolvedores em Java. Estas são as limitações específicas do BigTable (e algumas soluções alternativas possíveis):

• Suporte ruim para consultas de dados: são usadas consultas escritas em Google Query Language (GQL) para recuperar dados do BigTable. O GAE requer que todas as colunas de dados envolvidas em uma consulta sejam indexadas, e o índice não pode conter colunas de texto ou BLOB. Não há problema em relação a isso, mas o GAE só permite 100 índices por tabela. Provavelmente, isso é suficiente para um banco de dados SQL padrão, mas os bancos de dados desnormalizados do tipo NoSQL, como o BigTable, podem ter milhares de colunas, portanto, o número de 100 índices pode ser limitante para muitos aplicativos. Para piorar as coisas, o GAE não fornece nenhuma forma fácil de excluir índices que não estão mais em uso.

  A decisão sobre qual índice deve ser criado é uma grande dificuldade para os desenvolvedores do GAE. Se uma consulta usar uma combinação de colunas que não estão indexadas, o GAE emitirá somente uma exceção no tempo de execução quando a consulta for executada. Embora o SDK forneça ferramentas para gerar automaticamente arquivos de configuração de índice à medida que você testa o aplicativo no seu computador local, é possível errar índices se você não testar manualmente, à exaustão, todos os caminhos de execução. A fusão dos índices gerados automaticamente em um aplicativo que já está implementado também é um processo que pode estar propenso a erros, sem indicação de erro até que os usuários do aplicativo da Web acessem os índices configurados equivocadamente.

  Finalmente, é um tanto surpreendente — considerando que o BigTable é um produto da Google — o fato de que ele não suporte busca de texto livre no banco de dados. É possível incorporar uma implementação de mecanismo de busca, como o Apache Lucene, no seu aplicativo para indexar e realizar buscas em colunas de texto (consulte Recursos). Entretanto, isso é um grande inconveniente para Web sites menores, para os quais as instruções SQL LIKE padrão são suficientes para uma busca simples em texto.

• Dificuldade para importar e exportar dados: outro grande problema do BigTable é a incapacidade de importar e exportar dados. Como não há uma API padrão para acessar diretamente o BigTable, é necessário escrever a lógica de importação e exportação de dados em servlets dentro do seu próprio aplicativo e usar sua própria interface da Web para importar ou exportar dados.

  Como o GAE termina qualquer encadeamento de solicitação da Web depois de 30 segundos, é impossível fazer o upload de um grande conjunto de dados no BigTable por meio de uma conexão persistente. Uma solução alternativa comum é dividir a importação de dados em várias partes, de modo que cada parte leve menos de 30 segundos para fazer o upload e processar. Em seguida, é possível usar um driver de HTTP automatizado, como o JMeter ou o Grinder, para executar essas tarefas uma a uma, até que todos os dados sejam importados. Nem é preciso dizer que esse processo é tedioso.

  A exportação de dados a partir do BigTable é ainda mais problemática. Como a API limita cada consulta de dados a 1.000 resultados, os dados de exportação devem ser gerenciados em partes ainda menores do que as permitidas pela restrição de limite de tempo de 30 segundos para o processamento.

Reconhecendo as limitações do BigTable para a maioria dos desenvolvedores, o GAE fornece acesso a serviços hospedados de MySQL por meio de suas ofertas pagas empresariais.

Integração a outros serviços

O GAE fornece uma integração excelente a outros serviços da Google. Particularmente, o aplicativo pode integrar-se ao Google Accounts, para que os usuários possam fazer login no seu aplicativo usando um nome de usuário e senha da Google. Isso pode poupar bastante tempo, considerando que o desenvolvimento de um sistema de gerenciamento de usuários é um trabalho duplicado que cada Web site precisa fazer. Entretanto, as desvantagens são que nem todos os usuários possuem contas da Google, e que vincular o seu Web site ao Google Accounts dificultaria o processo de mover para outro provedor de PaaS posteriormente.

Os aplicativos do GAE também podem usar uma API simples para enviar e-mails por meio de servidores do GMail. Comparados com servidores SMTP não protegidos, é bem menos provável que os servidores do GMail sejam bloqueados pelo ISP do destinatário.

Se você hospeda o seu domínio no Google Apps, também pode configurar o aplicativo para ser acessado por meio de qualquer subdomínio que esteja sob o seu controle, vinculando sua conta do Google Apps à sua conta do GAE. Por exemplo, se mydomain.com é hospedado pelo Google Apps, é possível fazer com que o seu aplicativo seja acessível a partir de www.mydomain.com, e não de mydomain.appspot.com.

Veredito

Em geral, o GAE fornece um PaaS bem projetado e escalável. Sua cota generosa gratuita para Web sites pequenos também é interessante. Entretanto, a falta de suporte para a plataforma Java completa é um possível motivo para que ele não seja usado; além disso, alguns dos componentes do GAE ainda parecem experimentais, e não prontos para a produção.

Voltar para parte superior

Amazon Elastic Beanstalk

O Amazon Elastic Beanstalk, uma oferta relativamente nova da Amazon Web Services, fornece um ambiente de tempo de execução gerenciado Apache Tomcat baseado na infraestrutura Amazon Elastic Computing Cloud (EC2). O EC2 é uma oferta de Infrastructure-as-a-Service (IaaS), portanto, fornece muito mais flexibilidade do que o GAE. Por outro lado, ele requer muito mais esforço do desenvolvedor para gerenciar e escalar os aplicativos.

Java Tomcat puro

O ambiente do Beanstalk suporta um servidor Tomcat completo executando em um servidor virtual do EC2. É um ambiente Java puro com acesso ao sistema de arquivos subjacente. Por causa da popularidade do Tomcat, quase todos os frameworks Java corporativos suportam a implementação em Tomcat. Esses frameworks podem ser iniciados ou inicializados a partir de um arquivo WAR do Tomcat, oferecendo a você uma ampla variedade de opções de frameworks e bibliotecas.

O tempo de execução do Tomcat simples não tem limitação de encadeamento nem de E/S de arquivo ou rede. Um encadeamento de E/S de rede pode permanecer aberto pelo tempo que for necessário. A única limitação é a capacidade da máquina virtual subjacente.

Escala, a um preço

O Beanstalk escala o seu aplicativo iniciando automaticamente novas instâncias do EC2 e implementando o arquivo WAR na nova instância. Todas as instâncias do Beanstalk EC2 executam atrás de um equilibrador de carga. É possível usar um console de gerenciamento baseado na Web para monitorar os recursos disponíveis em cada instância do EC2 e configurar regras para iniciar automaticamente novas instâncias do servidor atrás do equilibrador de carga, quando a carga do servidor já existente excede os limites pré-estabelecidos.

Um problema comum em um cluster com equilíbrio de carga é como tratar sessões de HTTP. Cada nó de servidor Tomcat cria e gerencia objetos de sessão para os seus clientes. Se as solicitações da Web têm a carga equilibrada ao longo de vários nós de servidor, é necessário se certificar de que o nó de servidor que entrega a solicitação tenha o objeto de sessão correto. Uma forma simples de arquivar isso é ativar sessões persistentes no equilibrador de carga, exigindo que o equilibrador de carga se lembre dos cookies de sessão mantidos por cada servidor atrás dele e encaminhe solicitações ao servidor correto, com base nos cookies recebidos. A sessão persistente pode ser ativada no console de administração do equilibrador de carga. Configurar memórias compartilhadas ao longo dos nós de servidor ou simplesmente salvar os objetos de sessão em um banco de dados central são soluções mais eficientes e à prova de falhas. Essas opções permitem que o equilibrador de carga encaminhe solicitações para um nó de servidor aleatório ou para o que estiver menos ocupado, pois cada nó de servidor tem as mesmas informações de estado da sessão. Entretanto, todas essas opções requerem esforço do desenvolvedor de aplicativos. Ao contrário do GAE, que salva automaticamente os dados da sessão no BigTable, o Beanstalk requer que você faça todo o trabalho.

Talvez uma das maiores desvantagens do Beanstalk seja o preço, principalmente para sites da Web pequenos que podem obter hospedagem grátis em outro lugar. Embora o Amazon EC2 tenha um programa de um ano grátis para novas inscrições, o preço padrão do Beanstalk é aproximadamente US$ 40 por mês, inclusive para configurações de um único nó. É um preço barato para uma infraestrutura pronta para cluster, que pode escalar horizontalmente de forma automática em questão de minutos quando for necessário, mas é caro em comparação com programas como o GAE, se o seu aplicativo fica ocioso na maior parte do tempo, com um ocasional aumento repentino de tráfego.

Opções flexíveis de banco de dados

Um dos pontos fortes da plataforma Elastic Beanstalk é a flexibilidade na escolha de tecnologias de banco de dados. Ela oferece várias opções:

• Bancos de dados relacionais: por meio do Relational Database Service (RDS) da própria Amazon, é possível implementar vários bancos de dados relacionais. Esses servidores de banco de dados são gerenciados e monitorados pela Amazon, e é fácil importar e exportar dados. Dentro do seu aplicativo, basta apontar as origens de dados para o servidor do RDS. No entanto, saiba que cada instância do RDS é outra instância de servidor dedicada que executa o seu banco de dados — e uma instância de banco de dados é 30% mais cara que uma instância semelhante do EC2. O custo pode aumentar, e muitos aplicativos não precisam de um servidor de banco de dados dedicado.
• NoSQL: um dos problemas do servidor do RDS é o fato de ser um banco de dados relacional difícil de escalar. Se você prefere uma abordagem NoSQL semelhante à do Google BigTable, essa abordagem também está disponível com o Amazon SimpleDB. A API de Java do SimpleDB permite que o aplicativo acesse os dados com facilidade.
• Seu próprio servidor de banco de dados: como o EC2 fornece acesso a servidores virtuais brutos, é possível configurar os seus próprios bancos de dados ou origens de dados NoSQL (como o Apache Cassandra) em uma instância separada do EC2, e somente apontar o aplicativo Beanstalk para o seu próprio servidor de banco de dados.

É provável que a flexibilidade de opções de banco de dados, principalmente a capacidade de usar os bancos de dados relacionais gerenciados da Amazon, seja interessante para os desenvolvedores corporativos.

Integração a outros serviços

Além do Amazon RDS e do SimpleDB, os servidores do Beanstalk têm acesso a outros serviços da Amazon, como o Simple Queue Service, S3 Storage, Simple Email Service (SES) e APIs de pagamento. O SES é particularmente interessante e oferece um bom ponto de comparação com a API do GMail no GAE.

O SES tem uma API simples e permite usar o servidor SMTP da Amazon para enviar e-mails. O benefício de usar servidores SMTP da Amazon, em vez de configurar um servidor SMTP sem proteção em sua própria instância do EC2, é que os servidores da Amazon têm menos probabilidade de serem bloqueados pelos filtros de spam dos principais ISP. Para esse fim, o SES fornece um conjunto rico de ferramentas para controlar o aumento do volume de e-mails e receber feedback dos filtros de spam do ISP. Todos esses recursos são colocados à disposição do seu aplicativo do Beanstalk, para que você possa monitorar suas campanhas e otimizar o conteúdo dos e-mails para uma entrega mais eficiente.

Veredito

No geral, o Amazon Elastic Beanstalk simplifica consideravelmente a implementação e escala de aplicativos do Tomcat. No entanto, ainda assim, fornece a flexibilidade da infraestrutura subjacente do EC2, o que o torna ideal para aplicativos corporativos. Entretanto, o custo é alto para Web sites com tráfego baixo e desenvolvedores amadores.

Voltar para parte superior

CloudBees RUN@Cloud

A CloudBees é uma nova participante do cenário do PaaS em Java. Pode ser uma empresa recém-criada, mas as pessoas por trás dela são veteranos do Java corporativo. (Foi iniciada pelo ex-CTO da JBoss, Sacha Labourey, e vem empregando figuras importantes do Java em software livre — Adrian Brock, especialista em JBoss, e Kohsuke Kawaguchi, especialista em Hudson). Sua tecnologia de PaaS foi adquirida da Stax Networks, que vem fornecendo serviços de aplicativos Java hospedados a clientes corporativos por mais de dez anos. O serviço CloudBees RUN@Cloud se baseia na robusta plataforma Stax e está disponível para desenvolvedores individuais por meio de um portal da Web com autoatendimento.

Em comparação com os grandes atores, o RUN@Cloud procura encontrar o equilíbrio correto entre a escalabilidade gerenciada (como no GAE) e a flexibilidade (como nos serviços de PaaS da Amazon), acrescentando o suporte para o ciclo de vida de desenvolvimento de ponta a ponta por meio da plataforma.

Um Java Runtime robusto

Atualmente, o serviço RUN@Cloud se baseia na infraestrutura EC2 e pode ser considerado uma versão mais automatizada do Beanstalk + RDS. Como o Beanstalk, o RUN@Cloud também oferece uma instância dedicada de Tomcat que executa em um servidor virtual do EC2 para cada aplicativo da Web. Fornece um ambiente Java puro sem a limitação artificial do acesso ao sistema de arquivos, E/S de rede e encadeamento.

Um dos pontos fortes da RUN@Cloud como pequena empresa independente é o fato de não precisar estar vinculada à Amazon. A empresa pretende oferecer outros provedores de infraestrutura para complementar o EC2 em um futuro próximo.

Infraestrutura escalável grátis

Também de forma semelhante ao Beanstalk, o RUN@Cloud fornece uma infraestrutura escalável com equilibrador de carga e instâncias de servidor para serem iniciadas on demand, a fim de lidar com aumentos súbitos do tráfego. Entretanto, o RUN@Cloud fornece mais automação do que o Beanstalk. Por exemplo, em vez de usar sessões persistentes, o RUN@Cloud já configurou seus servidores Tomcat para salvar as sessões em bancos de dados sob o seu gerenciamento. Esse objeto de sessão de banco de dados gerenciado é transparente para os desenvolvedores — como no GAE.

Como o RUN@Cloud pode usar um equilibrador de carga compartilhado para gerenciar vários servidores Tomcat que executam em uma única instância do EC2, ele não precisa de uma instância do EC2 por instância do Tomcat. Consequentemente, pode administrar Web sites com tráfego baixo a um custo muito mais baixo que o do Beanstalk. Na verdade, o RUN@Cloud tem uma camada de uso grátis, ótima para aplicativos com tráfego baixo ou desenvolvedores amadores e estudantes.

Entretanto, da mesma forma que o GAE, o RUN@Cloud pode trocar sua JVM sem memória se seu aplicativo fica inativo por muito tempo, para conservar os recursos. Isso pode provocar uma resposta lenta à primeira solicitação, à medida que o aplicativo "aquece".

Bancos de dados relacionais MySQL hospedados

O serviço RUN@Cloud suporta de forma nativa um serviço gerenciado do MySQL junto com o serviço do Tomcat. É possível criar e gerenciar bancos de dados por meio de um console de administração baseado na Web. Além disso, é possível conectar-se ao servidor de banco de dados diretamente por meio de um cliente do MySQL para gerenciar os seus dados.

Ao contrário do Amazon RDS, o serviço RUN@Cloud implementa um servidor de banco de dados compartilhado ao longo de vários aplicativos. Cada aplicativo pode ter o seu próprio banco de dados, mas não necessariamente um servidor dedicado. A plataforma PaaS implementa automaticamente o banco de dados para maximizar a utilização de um pool de servidores bancos de dados. Em comparação com o RDS, o servidor de banco de dados compartilhado pode proporcionar um uso mais eficiente dos servidores virtuais e, consequentemente, baixar os custos.

Integração a outros serviços

O RUN@Cloud fornece acesso a APIs de plataforma e serviços suportados pelos provedores de infraestrutura subjacentes. Os aplicativos RUN@Cloud implementados no Amazon EC2, especificamente, têm acesso total a todas as APIs de serviços da Web da Amazon — como o S3, SQS e SES — de dentro do aplicativo.

Entretanto, o maior destaque do RUN@Cloud é sua forte integração ao DEV@Cloud, uma plataforma de integração contínua baseada em nuvem. O DEV@Cloud fornece sistemas de controle de versões e código de origem (Subversion e GIT), um repositório de desenvolvimento (Apache Maven) e um servidor de desenvolvimento (jenkins, anteriormente conhecido como Hudson). Permite executar o desenvolvimento automatizado e o teste dos seus aplicativos na nuvem, e não no seu próprio computador. Esse tipo de sistema de desenvolvimento centralizado é amplamente adotado por equipes de software agile, para garantir que o código de origem do repositório sempre seja testado e esteja em um estado adequado para o release.

Ao integrar o RUN@Cloud ao DEV@Cloud, a CloudBees fornece um bom conjunto de serviços de PaaS que podem gerenciar todo o ciclo de desenvolvimento, teste e implementação de aplicativos da Web corporativos em Java. Você só precisa editar o código de origem no seu próprio computador, e todas as outras operações podem ser delegadas a um sistema automatizado com uma sobrecarga mínima para a TI.

Veredito

O CloudBees RUN@Cloud é uma alternativa de baixo custo (e até mesmo grátis) ao Amazon Elastic Beanstalk e ao RDS. Sua integração a sistemas de desenvolvimento contínuo o torna interessante para equipes de desenvolvimento de software agile que desejam automatizar todas as funções de TI no processo de desenvolvimento.

Voltar para parte superior

Conclusões

Depois de anos de decepção, os serviços de PaaS em Java finalmente estão no auge. Cada um dos três serviços revisados e comparados neste artigo tem sua abordagem exclusiva e, consequentemente, pontos fortes e fracos específicos.

Se você está desenvolvendo um novo aplicativo e pode tolerar as restrições do GAE, o GAE é uma opção excelente e gratuita. O RUN@Cloud e o Elastic Beanstalk são tempos de execução intercambiáveis no nível do aplicativo. Os aplicativos Java EE padrão podem executar em qualquer uma das plataformas sem modificações. O RUN@Cloud é mais barato para começar a usar, é mais fácil de configurar e fornece um suporte excelente para processos de desenvolvimento integrados continuamente. Eu recomendo começar com o RUN@Cloud gratuitamente, sabendo que é possível mover facilmente para o Elastic Beanstalk se estiver insatisfeito com os serviços da CloudBees.

Recursos

Aprender

• "Gartner Says 2011 Will Be the Year of Platform as a Service": o entusiasmo com o PaaS continua aumentando, como mostra esse release da Gartner.
  
  
• "Consider PaaS in Your Cloud Strategy": Yefim Natis, analista da Gartner, defende o PaaS nesta apresentação.
  
  
• Google App Engine for Java: o GAE para Java é uma das primeiras ofertas de PaaS em Java.
  
  
• Amazon Web Services: a Amazon Web Services oferece um conjunto de serviços interligados, como o Elastic Beanstalk, Elastic Compute Cloud, Relational Database Service, SimpleDB e Simple Email Service.
  
  
• CloudBees: os serviços da CloudBees DEV@Cloud e RUN@Cloud têm uma camada grátis para Web sites pequenos.
  
  
• Desenvolvimento Java 2.0: a série de artigos de Andrew Glover sobre o developerWorks mostra como começar a usar o Google App Engine, BigTable e Amazon Elastic Beanstalk.
  
  
• "Google App Engine for Java": confira o artigo de Richard Hightower em três partes sobre como desenvolver aplicativos Java para o GAE.
  
  
• A JRE Class White List: a lista oficial da Google das APIs de plataforma Java suportadas no GAE.
  
  
• WillItPlayInJava: veja o status do suporte do GAE para frameworks bastante difundidos.
  
  
• Navegue na livraria de tecnologia para ver livros sobre este e outros tópicos técnicos.
  
  
• Tecnologia Java no developerWorks: Encontre centenas de artigos sobre cada aspecto da programação Java.
  
  

Obter produtos e tecnologias

• Apache Lucene: é possível desenvolver seu próprio mecanismo de busca em texto usando o Lucene com base no BigTable, para possibilitar consultas de busca nos aplicativos do GAE.
  
  

Discutir

• Participe da comunidade do developerWorks.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Google App Engine
• Amazon Elastic Beanstalk
• CloudBees RUN@Cloud
• Conclusões
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais