Serviços de cloud computing PaaS: um guia para desenvolvedores Java

O PaaS, ou Platform as a Service (Plataforma como Serviço), é um tipo de serviço de cloud computing em que o provedor não somente oferece o hardware e o sistema operacional, mas também plataformas de aplicações e soluções pré-configuradas. Para os desenvolvedores, o PaaS reduz drasticamente problemas e despesas adicionais com a configuração do ambiente e a implantação de aplicações. Também torna as aplicações mais fáceis de escalar, por prover recursos sob demanda.

A plataforma Java é perfeitamente ajustável para o PaaS. Isso porque a JVM, o servidor de aplicações e os arquivos de deployment (ex.: WARs e EARs) fornecem um isolamento natural para aplicações Java, permitindo que múltiplos desenvolvedores instalem aplicações na mesma infraestrutura. Contudo, por alguns anos muitos serviços de PaaS ofereciam apenas plataformas como Ruby e Python, e o Google App Engine era o único provedor de PaaS para desenvolvedores Java. Felizmente isso está começando a mudar.

Muitos provedores comerciais entraram, nos últimos doze meses, no mundo de PaaS Java. Isto faz sentido; os 10 milhões de desenvolvedores Java certamente representam uma das maiores comunidades de desenvolvedores no mundo.

Neste artigo, iremos comparar os PaaS Java do ponto de vista dos desenvolvedores. A metodologia de comparação será verificar características de cada alternativa em quatro áreas:

• Suporte a plataformas tecnológicas;
• Suporte à produtividade do desenvolvedor e processos de de desenvolvimento;
• Desempenho e escalabilidade;
• Preços e outros aspectos relacionados a negócios.

Serão comparadas as seguintes soluções de PaaS Java (citadas em ordem alfabética):

• O Amazon Elastic Beanstalk é o PaaS Java da Amazon. Provê instâncias de Tomcat gerenciadas rodando sobre o EC2, incluindo balanceadores de carga e recursos para escalabilidade sob demanda. O Beanstalk integra-se com o resto do Amazon Web Services (AWS), provendo acesso aos bancos de dados relacionais gerenciados (RDS), repositórios de Big Data (SimpleDB), filas de mensagens, email e outros serviços.
• A CloudBees é uma startup baseada em capital de risco, fundada por veteranos da JBoss e da Sun, que recentemente captou 14 milhões de dólares em duas rodadas de financiamento. Embora relativamente novo, o PaaS do CloudBees está crescendo rapidamente neste espaço. Traz várias características únicas na categoria, em particular a integração contínua - um ciclo de gerenciamento completo de desenvolvimento e implantação na nuvem. Além disso, como o Heroku, a empresa oferece um "mercado" para divulgação de serviços e plugins de terceiros.
• O Cloud Foundry é uma iniciativa open source da VMware, cujos softwares suportam datacenters virtualizados (a base da maioria das ofertas de PaaS). A VMware também hospeda o Spring Framework, uma plataforma popular no universo Java EE. Uma característica única do Cloud Foundry é não oferecer um PaaS hospedado. Caso queira, você pode baixar o código e hospedar um PaaS nos seus servidores. Neste sentido, o Cloud Foundry é ao mesmo tempo uma plataforma de hospedagem e um serviço PaaS.
• O Google App Engine para Java é talvez o mais antigo (e mais maduro) PaaS no mercado. Tem um objetivo ambicioso de escalabilidade linear, e a equipe do projeto não tem tido receio de fazer mudanças até em APIs básicas do Java.
• O Heroku para Java é a uma recente oferta de PaaS executado sobre o Heroku, que traz uma herança significativa da comunidade Ruby, com muitos recursos voltados a esse grupo.
• O Red Hat OpenShift é uma oferta experimental da Red Hat. O JBoss Application Server da Red Hat está entre os mais populares servidores de aplicações Java, e o OpenShift provê suporte abrangente ao JBoss AS.

Suporte a plataformas e tecnológicas

Um dos mais importantes atributos de um provedor PaaS Java é a plataforma tecnológica que suporta. Afinal, a plataforma tecnológica é o que distingue o PaaS Java de outras ofertas PaaS. Como durante a longa evolução da plataforma Java, surgiram e se estabeleceram muitas plataformas tecnológicas concorrentes, para o fornecedor de PaaS Java é importante o suporte ao maior número de tecnologias possíveis.

O OpenShift e o CloudBees suportam uma ampla variedade de tecnologias, de um simples container de servlets (normalmente o Tomcat) até um completo servidor Java EE 6 (JBoss AS 7).

O pioneiro do PaaS Java, o Google App Engine, está agora ficando para trás dos novos competidores em termos de padrões suportados. O App Engine não suporta toda a plataforma Java SE, e oferece um suporte restrito para muitos dos frameworks populares. Além disso, requer que o usuário use uma API própria de rede e persistência, indo na direção oposta dos padrões abertos e resultando em aplicações difíceis de portar. De modo similar, o Heroku para Java requer que a aplicação inclua sua própria instância do Jetty, o que quebra o tradicional modelo de implantação do Java EE.

O Cloud Foundry suporta o Tomcat, mas o desenvolvimento de aplicações e o deployment são altamente otimizados para o Spring Framework, criando dependências. A plataforma suporta serviços de mensageria usando RabbitMQ e se baseia no padrão AMQP, mas seu suporte a outros frameworks Java é limitado.

A tabela a seguir resume o suporte a várias plataformas tecnológicas nas opções de PaaS Java analisadas.

Suporte à produtividade do desenvolvedor e a processos de desenvolvimento

Um das principais vantagens do modelo PaaS é simplificar a vida dos desenvolvedores, removendo o trabalho de gerenciamento de recursos. Assim, o suporte ao desenvolvedor e a integração de ferramentas são fatores importantes para se levar em consideração ao avaliar um PaaS.

Neste quesito, o CloudBees se destaca. Além de ser um ambiente de execução PaaS, é um ambiente integrado de builds e testes. Desenvolvedores podem usar o serviço Jenkins para o CloudBees automaticamente e continuamente baixar, compilar, testar e submeter códigos no repositório. Este processo de integração tem sido adotado por grandes equipes como um elemento fundamental do processo de desenvolvimento. Contudo, o gerenciamento do servidor de builds é geralmente um processo que toma tempo e cria dificuldades para o time de garantia de qualidade. O CloudBees simplifica esse processo, tornando-o muito mais transparente aos desenvolvedores. Recentemente, o OpenShift da Red Hat evoluiu e alcançou o CloudBees nessa área, trazendo suporte à integração com Maven e Jenkins.

O Amazon Beanstalk, o OpenShift, e o App Engine trazem ferramentas de desenvolvimento, SDKs e plugins de IDEs, que são consistentes com outras ferramentas baseadas em Java no mercado.

O Cloud Foundry e o Heroku para Java, fornecem ferramentas mais voltadas a desenvolvedores Ruby que desenvolvedores Java. Ao usar essas ferramentas, suspeito que muitos desenvolvedores Java vão demorar algum tempo para se acostumar com suas convenções e terminologias. Além disso, atualmente o Cloud Foundry conta com pouca documentação, boa parte sendo em forma de tutoriais em vídeo.

Tutoriais em vídeo são ótimos para desenvolvedores iniciantes, mas não têm a profundidade necessária para suportar a implantação de aplicações mais complexas; ou para apoiar desenvolvedores que querem ir além dos cenários básicos e usar scripts. Os guias para iniciantes datam de 2007, embora mudanças importantes na plataforma tenham ocorrido desde então. Existe documentação mais recente (aqui por exemplo), mas não é tão fácil de encontrá-la.

Outro ponto importante: o Cloud Foundry permite que desenvolvedores configurem seus próprios ambientes em nuvem, mas instalar o Micro Cloud é mais trabalhoso que apenas instalar um SDK.Isso torna o Cloud Foundry relativamente difícil para muitos desenvolvedores.

Desempenho e escalabilidade

Uma característica importante do PaaS é a habilidade da plataforma se autodimensionar, ou seja, aumentar e diminuir a capacidade utilizada ou o número de servidores, com base na demanda de tráfego, em tempo real. Isso requer o balanceamento de carga de requisições entre vários de servidores, a monitoração da carga em cada servidor e a inicialização de novos servidores se necessário.

Todos os provedores de PaaS, até certo ponto, autodimensionam os seus recursos. Mas isso é mais difícil do que parece. Para começar, uma aplicação Java EE deve ser configurada para acessar um banco de dados centralizado externo, diferentemente de um servidor de banco de dados hospedado na mesma máquina. O paradigma de programação e as ferramentas de todos os provedores de PaaS forçam o desenvolvedor a fazer isso.

Um problema ainda maior são as sessões HTTP. Nos servidores de aplicações Java, os estados das sessões são gerenciados na memória, por padrão. Para construir aplicações que possam ser balanceadas entre diferentes servidores, os desenvolvedores devem realizar um dos seguintes procedimentos:

• Configurar o balanceador de carga para suportar "sticky sessions" (sessões persistentes). O balanceador verifica todos os IDs das sessões nas requisições e sempre redireciona à mesma instância onde a sessão foi iniciada. Esta é uma abordagem simples, mas traz problemas: o balanceador tem mais trabalho; a distribuição de carga pode ficar desbalanceada por certo tempo; e é difícil reduzir a alocação de recursos quando há uma redução de carga, pois as sessões estarão em diversos servidores. Por conta desses problemas, poucos provedores PaaS usam essa estratégia.
• Configurar um cache compartilhado para sessões HTTP em memória. Dessa forma, todos os servidores têm acesso às sessões em memória. Mas replicar sessões na memória em um cluster é computacionalmente intensivo e consome muita banda de rede. Também requer trabalho do lado do desenvolvedor, para definir estratégias para manter o cache compartilhado e para a replicação.
• Configurar as aplicacações para persistir todas as sessões HTTP dentro em um banco de dados externo.

De todas as soluções avaliadas, o Google App Engine é a que melhor lida com essa questão. O App Engine é arquitetado para abstrair o conceito de servidores individuais; automaticamente cria repositórios de dados em servidores separados e salva as sessões HTTP dentro desses repositórios, por padrão. O processo é completamente transparente para os desenvolvedores. O problema é que o desempenho é fraco. É comum uma requisição web levar de 1 a 3 segundos para completar o percurso de ida e volta do bancos de dados.

O Heroku para Java também oferece compartilhamento automático de sessões entre servidores: cada uma das suas instâncias é encapsulada em uma instância customizada do Jetty. Porém, o Heroku não provê autodimensionamento. Deve-se acompanhar um painel de controle e adicionar recursos às aplicações quando necessário.

As demais alternativas direcionam bem o desenvolvedor a criar tabelas de banco de dados em um servidor de banco de dados separado e centralizado, como parte do processo de implantação. Para sessões HTTP, o Cloud Foundry usa sessões persistentes no seu balanceador de carga, mas traz problemas sérios de escalabilidade. As demais soluções de PaaS deixam o gerenciamento de sessões na mão dos desenvolvedores, embora isto não seja deixado claro em suas documentações.

Preços e outros aspectos ligados a negócios

O custo das ofertas de PaaS, claro, é um importante item a ser considerado pelos desenvolvedores. A maioria oferece níveis de serviços gratuitos, e para pequenas aplicações Java esses níveis são excelentes escolhas. Entretanto, como se viu com o polêmico aumento de preços do Google App Engine, o custo para aplicações de alto volume pode ser bem alto com provedores de PaaS.

Outro fator importante a se considerar é a disponibilidade de opções de suporte. Tanto o Google App Engine como o Amazon Web Services têm um histórico fraco em suporte técnico. Os desenvolvedores são deixados à sua própria sorte para acharem respostas nos fóruns.

Os provedores menores, especialistas em Java, tendem a oferecer melhor suporte técnico, mesmo em fóruns públicos. Na minha opinião, o CloudBees provê a melhor combinação entre suporte pago baseado em chamados e conhecimento específico em Java da equipe de suporte.

E depois?

Neste artigo, avaliamos seis fornecedores de PaaS para Java bem conhecidos. Existem, é claro, muitos outros provedores:

• Jelastic, que suporta uma grande gama de combinações de servidores de aplicações e bancos de dados, incluindo variações em banco de dados MySQL e NoSQL;
• WSO2 StratosLive, uma solução de PaaS construída sobre o servidor de aplicações WSO2, compatível com a especificação Java EE;
• CumuLogic: fornece uma aplicação PaaS Java que funciona em vários ambientes de nuvem públicos e privados, incluindo CloudStack, OpenStack e Eucalyptus.

Iremos continuar acompanhando esses provedores, que podem facilmente passar a desafiar os grandes.

As opções de PaaS para Java evoluíram muito nos últimos doze meses, e a oferta de produtos continua crescendo. Essa é uma ótima notícia para desenvolvedores Java procurando baixos custos, escalabilidade e soluções de hospedagem gratuitas.

Para desenvolvedores Java EE, acredito que o CloudBees e o Open Shift são os melhores neste momento. E com o OpenShift ainda em beta, o CloudBees seria o vencedor da comparação. Se você está disposto a se aventurar fora da zona de conforto do Java EE, o Heroku para Java e o Cloud Foundry são opções dignas de fazer frente ao venerável Google App Engine.

Sobre o autor

Michael Yuan é empreendedor, autor e entusiasta da tecnologia Java. Publicou cinco livros e mais de 40 artigos sobre engenharia de software, além de ter contribuído código para projetos open source importantes (incluindo os do JBoss e Mozilla). Sua mais recente startup, Ringful Health, tem seus servidores Java implantados no Google App Engine, Amazon EC2 e CloudBees.