A Amazon acaba de lançar a Elastic Beanstalk, uma plataforma PaaS para rodar aplicações Java diretamente na infraestrutura deles. É usada toda a plataforma IaaS da Amazon por baixo, como EC2, S3, Load Balance etc, mas sem a gente se preocupar em configurar nada. Basta montar seu WAR no Eclipse, clicar um botão e tá no ar usando toda a estrutura Amazon e escalando automaticamente com zero de preocupação.
Para quem precisar, porém, é permitido mexer em vários aspectos do deploy, mexendo até em parâmetros da JVM. A stack padrão usa as instâncias do EC2 rodando uma JVM com Tomcat, e você escolhe o banco de dados (S3, MySQL, SQL Server, Oracle), além de todos os outros produtos da Amazon.
Comparando com o Google AppEngine que tenho experiência, me pareceu bem mais robusto com relação a opções. Na Amazon você ainda tem controle sobre o ambiente e a stack é bastante padrão, tornando a aplicação facilmente portável (um problema sério ainda no GAE). Em compensação, o Beanstalk me pareceu bem mais caro que o AppEngine.
Wait a minute: agora vou poder desenvolver minha app normalmente aqui, usando o banco de dados que quiser, as bibliotecas que quiser, sem precisar portar tudo isso para um ambiente fechado (como o GAE)?
Aí é sucesso!
Acho que agora sim geral vai ter coragem de colocar suas aplicações enterprise no cloud!!
aplicações ‘hospedadas’ lá fora, neste caso, ‘na nuvem’, não demoram mais para carregar, mesmo que alguns ‘pentelhésimos’ de segundo?[/quote]
No GAE, só a primeira vez que entrar. Veja um exemplo: http://www.horaagora.com/
Não é culpa da implementação do usuário nem nada, mas sim do GAE mesmo. Uma vez vi uma parada falando porque demorava, acho que tinha a ver com Servlet, mas não me lembro muito bem. Alguém tem mais informações?
Ter uma app em outro servidor que faz requests pra essa hospedada no GAE de tempos em tempos é solução?
aplicações ‘hospedadas’ lá fora, neste caso, ‘na nuvem’, não demoram mais para carregar, mesmo que alguns ‘pentelhésimos’ de segundo?[/quote]
No GAE, só a primeira vez que entrar. Veja um exemplo: http://www.horaagora.com/
Não é culpa da implementação do usuário nem nada, mas sim do GAE mesmo. Uma vez vi uma parada falando porque demorava, acho que tinha a ver com Servlet, mas não me lembro muito bem. Alguém tem mais informações?
Ter uma app em outro servidor que faz requests pra essa hospedada no GAE de tempos em tempos é solução?[/quote]
É um lance de performance. O GAE “inativa” a aplicação depois de certo tempo de ociosidade.
Num ambiente como o deles, é inviável o uso “irracional” de recursos. Deixar a app na memória? Só se ela estiver em uso…!
Aí quando vc acessa novamente, leva um tempo sim, pois o GAE tem que subir a aplicação again, recuperar o estado e tal…
Esse lance de fazer request de tempos em tempos, se não me engano tem uma parada no próprio GAE pra fazer isso. Mas não tenho certeza, posso estar falando merda.
Eu não testei o Beanstalk ainda mas me parece que eles teriam um problema de Cold Start parecido com o GAE. Você habilita uma instância (ou mais) do EC2 e depois ele vai ativando novas instâncias conforme precisa; e subir essa instância nova deve ser lento também. No GAE hoje você consegue, por exemplo, pagar para deixar 3 instâncias reservadas (AlwaysOn do GAE 1.4), mas se precisar da quarta, vai subir on demand.
Se bem que o grande problema do GAE é muitas vezes subir o contexto no meio de um request de usuário (problema aliás amenizado com os WarmUpRequests do GAE 1.4). O EC2 não faria isso, subiria as instâncias por trás baseado em alguma métrica de processamento ou coisa do tipo. Mas se a carga for muito grande e não tiver dado tempo de subir a outra instância, é possível que o usuário tome uns 503 no EC2; no GAE, ficaria lento mas não indisponível.
Como Tim Bray tuitou agora pouco, por enquanto é um TaaS(Tomcat as a Service)
Do teste que fiz, a única vantagem é poder ter mais controle da infraestrutura.
Pontos negativos:
-Quando você cria uma instância, ele cria o restante da infra para você, mas quando deleta não, tem de matar os outros serviços(S3, EC2, LoadBalance) na unha.
-E principalmente, não tem serviços/APIs prontas como no GAE
Ontem a noite dei uma olhada na documentação, e fiz alguns testes com o Beanstalk. Algumas considerações baseadas na discussão:
Se vc tiver falando do primeiro acesso, existe sim uma questão no GAE como dito pelo pessoal.
Mas pelo modo que eu li aí, vc tá relacionando mais com a questão de estar “lá fora” do BR, é isso? Se for, de fato alguns pentelhésimos a mais isso leva. Uma app em um host por aqui, tipo Locaweb vai responder mais rápido sim, mas acho que a questão em evidência aqui é muito mais confiabilidade e facilidade que velocidade
[quote=“bronx”]É um lance de performance. O GAE “inativa” a aplicação depois de certo tempo de ociosidade.
Num ambiente como o deles, é inviável o uso “irracional” de recursos. Deixar a app na memória? Só se ela estiver em uso…!
Aí quando vc acessa novamente, leva um tempo sim, pois o GAE tem que subir a aplicação again, recuperar o estado e tal… [/quote]
É isso aí… essa inativação acontece sim, pra poupar recursos… É nítido o primeiro acesso mais lento. Na última versão do GAE já saiu inclusive documentada essa questão do Warmup Request: http://code.google.com/appengine/docs/java/config/appconfig.html#Warming_Requests parece bem simples fazer isso pra manter a app “quentinha”
Mas eu acho que como disse o Sérgio, o EC2 não faria isso… até pq o EC2 quer te vender a instância, ele não remove tua app da memória, o máximo que ele faz, é diminuir o numero de instancias pra você pagar menos, com base no AutoScaling.
[quote=“Bruno Laturner”]Mais info, e rodando outras linguagens da plataforma java em cima do Beanstalk:
É uma app simples em Grails, com um Domain e scaffold padrão, já tá lá no ar…
Peguei uma instância Micro, com 600mb (tomcat rodando com 448), e quando mandei o e-mail na lista do Grails, bombou o acesso, o autoscaling funcionou bem, subiu mais uma instância bem rápido, e na madrugada ele derrubou. sozinha…
O tempo pra subir varia, mas nos meus testes não passaram de 3 minutos, mas você tem como controlar “quando” subir. Se vc descer a métrica do Cloudwatch um pouco, você consegue prever isso e se prevenir!
Não sei muito bem como funciona esse “AlwaysOn” do GAE, mas na infra do AWS AutoScaling e óbvio, agora do Beanstalk, você diz quantas instâncias no mínimo vc quer que fiquem no ar, e quantas no máximo também. Você pode dizer que quer começar com 2 instâncias, pra ter um failover, e ir até 6, dependendo do pico de acesso
Tenho que confirmar certinho, mas se eu não me engano, vc ainda consegue configurar de quanto em quanto elas sobem… Por ex: Começa com duas, vai até 10 no máximo, e vai subindo de duas em duas…
[quote=“Rafael Nunes”]Pontos negativos:
-E principalmente, não tem serviços/APIs prontas como no GAE [/quote]
Tem sim toda a api pronta já pra acesso! Hoje (quer dizer, desde ontem no lançamento), é possível interagir com o beanstalk de 4 maneiras:
API Java
Serviços normais AWS - webservices
command line da aws - feito em ruby
console web
eclipse
Enfim, meus testes foram bem satisfatórios sim, e pra mim que já iria rodar a arquitetura do projeto lá mesmo, com EC2, EBS, ELB, RDS e S3+Cloudfront, acho que não tenho como fugir de uma plataforma como essa aí, no meu caso, vai dar pra ganhar bastante tempo em configuração e deploy.
[quote=Lucas Teixeira]Não sei muito bem como funciona esse “AlwaysOn” do GAE, mas na infra do AWS AutoScaling e óbvio, agora do Beanstalk, você diz quantas instâncias no mínimo vc quer que fiquem no ar, e quantas no máximo também. Você pode dizer que quer começar com 2 instâncias, pra ter um failover, e ir até 6, dependendo do pico de acesso
[/quote]
No GAE o AlwaysOn mantém 3 instâncias da sua aplicação sempre de pé mesmo sem receber requisições, o que evitaria os ‘cold starts’
[quote=Lucas Teixeira]
Tem sim toda a api pronta já pra acesso! Hoje (quer dizer, desde ontem no lançamento), é possível interagir com o beanstalk de 4 maneiras:[/quote]
Me referia a API de serviços(e que pra mim ai está o grande ganho de produtividade no GAE), como: Blobstore, ImageAPI, XMPP, Channel, OpenID, Autenticação com usuários Google/Apps, etc, etc http://code.google.com/appengine/docs/java/apis.html
Algumas APIs sim, que você pode criar um SPI pra elas.
Mas a grande maioria, são implementações de JSRs que você pode substituir.
De toda forma concordo, se ficar amarrado ao GAE é um problema, então nem considere usá-lo.
Legal, é quase a mesma idéia então de se manter X instâncias no mínimo com o AutoScaling.
Só diferencia que no AWS não vai ter esse Cold Start “nunca”, pq ele sempre tem uma instância pelo menos no ar, sem baixar a app, mesmo que não tenha requisições.
E quando devido ao AutoScaling ele vai subir outra instância, ele só disponibiliza ela por trás do ELB (balanceador) depois que está pronta para assumir requests.
[quote=Rafael Nunes]Me referia a API de serviços(e que pra mim ai está o grande ganho de produtividade no GAE), como: Blobstore, ImageAPI, XMPP, Channel, OpenID, Autenticação com usuários Google/Apps, etc, etc http://code.google.com/appengine/docs/java/apis.html[/quote]
Concordo com a qualidade das APIs do GAE serem bacanas. Mas ao mesmo tempo são, claro, o grande ponto negativo do vendor lock-in.
Essa é a grande diferença pro GAE, o startup é feito por trás como em qualquer lugar do mundo.
Sobre o AlwaysOn: sou cliente (é pago) do serviço desde o primeiro dia anunciado no GAE 1.4 beta. Pelo anúncio, a impressão que ficaria era de que não haveria mais Cold Start dentro de requests de usuário. No site da Caelum, um site bem pequeno, 3 instâncias sempre ligadas seriam mais que suficiente em 99% do tempo.
Mas não é o que vejo nos logs: o AlwaysOn garante 3 instâncias ligadas o tempo inteiro, mas não garante que não serão desligadas. O GAE sobe e desliga instâncias o tempo inteiro, provavelmente realocando máquina e balanceando carga. No site da Caelum, um site pequeno, conto cerca de 30 novas instâncias ligadas por dia, isso mesmo tendo o AlwaysOn ligado. E várias dessas instâncias sobem em requests de usuário (não só nos WarmUpRequests automáticos).
Cheguei a questionar esse comportamento na lista oficial do GAE mas me parece que é algo que temos que conviver e pronto. O Cold Start continua sendo uma pedra no sapato, e o ideal é diminuir ao máximo o tempo de startup da aplicação (aka. não usar Spring [troll] )
Alguém ja fez algo?
Estou pensando em desenvolver uma app na Amazon com o VRaptor.
PS: Comecei no GAE, mas essa falta de portabilidade encomodou um pouco.
