Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

Postado por Michael Yuan , traduzido por Jeff Prestes em 20 Jan 2012
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:
Serão comparadas as seguintes soluções de PaaS Java (citadas em ordem alfabética):
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 |
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 |
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:
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 |
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 |
Neste artigo, avaliamos seis fornecedores de PaaS para Java bem conhecidos. Existem, é claro, muitos outros provedores:
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.
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.
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.
Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.
Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.
O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.
Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.
Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.
Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.
1 comentário
Acompanhar Discussão Responder