BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Serviços de cloud computing PaaS: um guia para desenvolvedores Java

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

Favoritos

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.

 

Amazon Beanstalk

CloudBees

Cloud Foundry

Google App Engine

Heroku for Java

OpenShift

Tomcat Sim Sim Sim Não Não Sim
Java SE Sim Sim Sim Não Sim Sim
Java EE Não Sim Não Não Não Sim
Suporte a bibliotecas Java padrão Sim Sim Sim Não Sim Sim
Acesso ao sistema de arquivos Sim Sim Sim Não Sim Sim
Acesso a threads Sim Sim Sim Não Sim Sim
Conexões a redes externas Sim Sim Sim Limitado Sim Sim
MySQL RDS Sim Sim Plano pago Sim Sim
Bancos de dados relacionais comerciais RDS Externo Externo Não Externo Externo
Suporte a Big Data SimpleDB Externo Externo BigTable Externo Externo
Deploy sem frameworks especiais Sim Sim Não Não Sim Sim
Amigável para migração de aplicações existentes Sim Sim Não Não No Sim
Portabilidade de aplicativos Alta Alta Moderada Baixa Baixa Alta
Pronto para produção? Sim Sim Beta Sim Beta Beta

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.

 

Amazon Beanstalk CloudBees Cloud Foundry Google App Engine Heroku for Java OpenShift
Ferramentas de IDE Sim Sim Sim Sim Não Sim
Ferramentas de linhas de comando Sim Sim Sim Sim Sim Sim
Console baseado na web Sim Sim Não Sim Não Sim
Testes na máquina do desenvolvedor Fácil Fácil Difícil Difícil Fácil Fácil
Build sem dependências fora do padrão Java Sim Sim Não Não Não Sim
Integração com sist. de controle de versões Não Sim Sim Não Não Parcialmente
Builds integrados Não Sim Não Não Não Sim
Testes integrados Não Sim Não Não Não Não
Acesso aos logs via web Não Sim Sim Sim Sim Sim
Aplicação de terceiros/ Serviços de testes Não Sim Não Não Não Não
Acesso a API Sim Sim Não Não Sim Não
Documentação Boa Boa Fraca Boa Boa Boa

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.

 

Amazon Beanstalk CloudBees Cloud Foundry Google App Engine Heroku for Java OpenShift
Balanceador de carga integrado Sim Sim Sim Sim Sim Sim
Domínio personalizado para balanceamento de carga Sim Sim Não Google Apps Sim Sim
Autodimensionamento do servidor de aplicações Sim Sim Planejado Sim Não Sim
Autodimensionamento do banco de dados Não Não Não Sim Não Não
Critérios de desempenho definidos pelo usuário Sim Sim Planejado Não Não Sim
Painel de monitoramento na web Sim Sim Planned Sim Sim Sim
Sessão HTTP clusterizada Manual Manual Manual Auto Auto Manual

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.

 

Amazon Beanstalk CloudBees Cloud Foundry Google App Engine Heroku for Java OpenShift
Serviço básico gratuito Sim Sim (Não se aplica) Sim Sim Sim
Custo para aplicações web com baixo tráfego Alto Zero Zero Zero Zero Zero
Suporte a múltiplos ambientes de nuvem Não Não Planejado Não Não Planejado
Nuvem privada Não Beta (OpenStack ou vSphere) Sim Não Não Planejado
Suporte Fórum Email e Telefone Fórum / Chamados via web Fórum Email e Telefone Fórum
Qualidade do suporte Fraca Boa Boa Fraca Razoável Boa

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.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

  • Ótimo artigo.

    by Thiago Fonseca,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Muito bom o artigo. Já fiz testes no Openshift e gostei bastante. Experimentarei o CloudBees, que até então eu não conhecia.

    Só uma dúvida. O termo Infraestrutura como Serviço não se refere ao serviço de cloud de sigla IAAS?

    Abraços.

  • Re: Ótimo artigo.

    by Norberto Enomoto,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Thiago,

    Esse modelo acima se refere Platform as a Service (PaaS).
    Já o modelo Infrastructure as a Service (IaaS) temos como exemplo o EC2 da Amazon Web Services.

    Para maiores informações:

    en.wikipedia.org/wiki/Platform_as_a_service

    en.wikipedia.org/wiki/Infrastructure_as_a_servi...

  • Custos

    by Ricardo Spinoza,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Gostei do artigo, parabéns. O maior problema que vejo na nuvem é calcular os custos, apesar de alguns fornecedores oferecerem calculadoras de custo é difícil mensurar a demanda de um sistema (talvez sistemas legados sejam mais comportados neste ponto). Outro fator que não há uma maneira heterogênea de cobrança dos serviços entre os fornecedores, isto dificulta fazer a comparação - talvez seja alguma estratégia dos provedores. Os custos na nuvem literalmente são uma nuvem!!!

  • Re: Ótimo artigo.

    by Thiago Fonseca,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Thiago,

    Esse modelo acima se refere Platform as a Service (PaaS).
    Já o modelo Infrastructure as a Service (IaaS) temos como exemplo o EC2 da Amazon Web Services.

    Para maiores informações:

    en.wikipedia.org/wiki/Platform_as_a_service

    en.wikipedia.org/wiki/Infrastructure_as_a_servi...


    @Norberto, eu sei que o modelo descrito acima é o PaaS.
    Quando fiz este comentário, existia um termo incorreto no texto que foi corrigido.

  • Atualizações

    by Marcus Rosa Pereira,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    Olá

    Tenho procurado serviços como estes. Gostaria que começasse gratuito, pra testes; e depois fossem adicionando valores/capacidade a medida da minha necessidade. Comecei testando GoogleAppEngine. Não me senti confortável com a obrigação em usar API específica (faz minha aplicação nada portável, entre outros motivos).


    Depois fui pro CloudFoundry, que logo passou a não ter mais o plano gratuito; aí passei pro CloudBees. Recebi recentemente um e-mail informando que o serviço vai ser desativado até o fim desse ano; ficando somente com Jenkins Como Serviço.


    Enfim, o fato é que (in)felizmente esses serviços mudam; seria interessante ter uma fonte atualizada com esse comparativo.



    Obrigado.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT