Pular para o conteúdo principal

Aplicação web com Spring no Cloud Foundry

Um tempo atrás experimentei o mecanismo de cloud da SpringSource chamado de Cloud Foundry (CF). Para isso foi necessário criar uma conta na Amazon Web Services (AWS - infra estrutura de cloud da Amazon) e deixar o número do meu cartão de crédito.

Pude notar que o Cloud Foundry é uma ferramenta que permite a criação e configuração de uma máquina virtual (VM) na AWS com apenas alguns cliques na interface administrativa. A VM criada pelo CF é composta por um Linux da distribuição CentOS, um Apache Web Server, um SpringSource tc Server (Tomcat adaptado) e uma instância de MySQL. Já o AWS é quem hospeda a VM totalmente configurada pelo CF. Também é possível criar diferentes máquinas virtuais diretamente na interface administrativa do AWS.

Tudo começa com a criação de uma conta no AWS e a indicação de um cartão de crédito para as cobranças. Após aguardar até 24h para confirmação do número do cartão, o AWS disponibiliza o acesso à interface administrativa. Através desta interface torna-se possível criar uma VM com qualquer um dos sistemas operacionais disponíveis (CentOS, Windows, Fedora, Ubuntu, etc). Contudo, a máquina criada estará vazia mas acessível via SSH. A partir daí o desenvolvedor deve fazer upload dos softwares necessários e configurar por conta própria estas instalações dentro da VM. Mas, o que mais interessa para testar o CF da SpringSource é a criação um par de chaves digitais para autorizar o CF a acessar a conta no AWS e fazer todas as configurações necessárias, além de criar a VM com todos os softwares indicados anteriormente.

Após ter a conta no AWS e um par de chaves digitais, o próximo passo é criar uma conta no CF e fazer o upload das chaves. A partir desse momento, torna-se possível fazer o upload de um WAR contendo a aplicação web desejada. Esta aplicação pode usar ou não Spring Framework, além de qualquer outra tecnologia Java acessível a partir de um conteiner web.

Através da interface administrativa do CF é possível configurar algumas características do MySQL (se será uma instância única ou um cluster de banco de dados a ser distribuído geograficamente em VMs no AWS). Além do upload do WAR da aplicação a ser instalada automaticamente na VM criada pelo CF, a interface permite indicar o usuário, senha e esquema a serem criados no MySQL e o nome da instância no tc Server para a aplicação.

Ao ativar a VM configurada através do CF, a VM começa a rodar no AWS com um IP e nome na web atribuídos dinamicamente pelo AWS (ou um IP fixo se adquirido no AWS).

Após ter a conta disponível no AWS e no CF, em alguns minutos uma VM estará rodando e acessível através da web com todos os softwares indicados já configurados e em execução. Os maiores tempos são gastos aguardando validação do cartão de crédito pelo AWS e o upload do WAR para o CF.

Para realizar estes testes e conhecer a infra do AWS e CF, escolhi a VM mais barata que está baseada numa máquina com pouca capacidade de processamento e uso de linux (U$ 0.085 / hora para uma VM com 10GB HD, ˜2GB ram, ˜1GB swap e CPU Intel Xeon 2.66GHz). Esta configuração pode ser alterada a qualquer momento, resultando em acréscimos no valor hora.

O CF no momento suporta apenas a infra do AWS. Mas, com a aquisição da SpringSource pela VMware, em breve a infra da VMware também estará disponível. Por enquanto, o CF é beta e, por isso, ainda é gratuito. Portanto, a SpringSource não está cobrando, por enquanto, pelo uso do CF. Mas, não podemos nos iludir, ainda temos que pagar pelo tempo de uso do AWS.

A idéia do CF é legal, principalmente para quem não deseja ter trabalho ou não tem skill para uma configuração detalhada de um linux com as ferramentas indicadas. Contudo, quem domina a administração de um linux e a configuração em cluster de um MySQL, talvez não queira pagar pelo custo do CF no futuro ou deseja ter controle total sobre as otimizações.

Vejo uma vantagem no AWS e CF ao usar uma VM. Neste caso podemos instalar qualquer software e usar qualquer tecnologia plenamente. Contudo, a distribuição é limitada à clusterização de máquinas e serviços (como banco de dados ou servidor de aplicações). Já o mecanismo de cloud da Google impõe restrições na aplicação Java em favor de uma distribuição transparente da aplicação. O Google controla onde a aplicação executa, o JPA não é completamente implementado e as operações de JNDI e acesso a disco não são permitidos. Ambos os modelos são interessantes. Podemos escolher o melhor de acordo os requisitos da aplicação.



O exemplo ilustrado acima foi comentado num post no blog do Spring Brasil User Group com o título: Aplicação web completa com Spring Framework 2.5 disponível.

By Spock
http://blog.spock.com.br/
http://twitter.spock.com.br/
http://www.springbrasil.com.br/

Comentários

Postagens mais visitadas deste blog

10 reasons why we love JSF

1. One-slide technology: it's so simple that I can explain basic JSF with one slide. 2. Easy to extend: components, listeners, render kit, Events, Controller, etc. 3. Real-world adoption: JBoss, Exadel, Oracle, IBM, ... 4. Architecture model: you can choose between more than 100 different architecture. 5. Open-mind community: using JSF you are going to meet very interesting people. 6. We are using JSF the last 5 years and we found very good market for JSF in Brazil 7. Progress: look to JSf 1.1 to JSF 1.2, JSF 1.2 to JSF 2.0. People are working really hard! 8. Many professionals now available 9. It's a standard. It's JCP. Before complain, report and help! 10. Ed Burns, spec leader, is an old Globalcode community friend! EXTRA: My wife is specialist in JSF. She's my F1 for JSF :) Nice job JSF community! -Vinicius Senger

EJB 3: Uma evolução sob os conceitos do Hibernate e Spring

Definitivamente o modelo de componentização definido no Java EE 5 e 6 evoluiu e melhorou muito. Mas, sem dúvida muita dessa evolução se deve às pressões do Hibernate e Spring Framework. Estes dois últimos frameworks nasceram baseados no conceito de POJO, que nada mais é do que a concepção de um modelo de componentização baseado em classes Java sem as regras impostas pelo EJB (curioso, sem o EJB não existiria o Hibernate ou o Spring). A morte dos Entity Beans O Hibernate nasceu da idéia de promover um modelo de persistência mais simples que o proposto pelos EJBs do tipo Entity Beans definido na especificação EJB 2.x. Este foi o primeiro tipo de EJB a sofrer com a evasão de desenvolvedores com o surgimento deste framework e a conscientização sobre os problemas nos Entity Beans. A partir de um modelo baseado em JavaBeans e o uso do JDBC, o Hibernate usa a Reflection API para gerar os SQLs necessários para persistir o estado de beans em diversos banco de dados relacionais, além de defini...

O que é Lógica de programação?

Este é o segundo de uma série de posts voltados aos leitores do blog que estão dando início à carreira de desenvolvimento de software. O assunto de hoje é a lógica de programação. Para ler antes: Entendendo como funciona a programação de computadores: linguagens de programação, lógica, banco de dados A lógica de programação é um pré-requisito para quem quer se tornar um desenvolvedor de software, independente da linguagem de programação que se pretende utilizar. Mas o que é de fato a Lógica de Programação e como saber se eu tenho esse pré-requisito? A lógica de programação nada mais é do que a organização coerente das instruções do programa para que seu objetivo seja alcançado. Para criar essa organização, instruções simples do programa, como mudar o valor de uma variável ou desenhar uma imagem na tela do computador, são interconectadas a estruturas lógicas que guiam o fluxo da execução do programa. Isso é muito próximo ao que usamos em nosso cotidiano para realizar atividad...

JavaOne Brasil, dicas para submissão de palestras

Não quero parecer pretensiosa dando dicas para submissão de palestras para o JavaOne Brasil, mas sim repassar os tantos conselhos e sugestões recebidas pelos vetaranos do JavaOne: Bruno Souza e Leonardo Galvão que revisaram dezenas de submissões para o JavaOne e ajudaram a aprovar tantas palestras, e também misturar um pouco da minha experiência na seleção de palestras nos eventos realizados pela Globalcode e SouJava . 10 anos de JavaOne: http://www.globalcode.com.br/noticias/Globalcode10AnosNoJavaOne Os palestrantes ganham a entrada! A submissão pode ser feita em português! O passo mais importante para ser aprovado como palestrante no JavaOne é sem dúvida nenhuma submeter pelo menos uma palestra. Então, independente de qualquer coisa, participe, arrisque, divulgue.  Mas, se quiser aumentar as suas chances...   1) Leve a sério: peça para amigos fazerem uma leitura crítica do texto, e claro uma boa revisão ortográfica. 2) Submissão de várias palestras ou variações do ...

Java no mundo das Telecomunicações

Este é meu primeiro post aqui no blog e gostaria de dizer que estou muito feliz em também poder contribuir com esta grande (e crescente) família Globalcode. Vou começar escrevendo aqui sobre um tópico pouco explorado no universo Java: o seu uso no mundo das telecomunicações. Vários de vocês podem ter trabalhado em projetos para empresas de telecom utilizando a tecnologia Java. Eu mesmo já participei de alguns, implantando sistemas de tarifação, faturamento, CRM e cobrança. Mas o objetivo deste post é um pouco diferente: estou falando do uso de Java na própria rede de telecom. Como vocês podem imaginar, esta rede que permite que ligações telefônicas sejam feitas de seu celular ou aparelho fixo é um tanto quanto complexa, lidando com aspectos como roteamento, bilhetagem, roaming , etc. E o Java está presente neste cenário também. Para provar que não estou mentindo, abram o site do JCP e cliquem no link "JSRs by Technology". Observem que uma das categorias lista é a JAIN ( Jav...

NIO.2 do Java 7: uma nova API do Java para file system

Uma das novidades mais importantes e aguardadas do Java 7 foi a NIO.2, a nova API para a manipulação I/O com Java. A NIO.2, também conhecida como JSR 203 , disponibiliza um conjunto de novos componentes, projetados para melhorar caracterísiticas de I/O com Java como por exemplo: uma nova API para o acesso e manipulação de conteúdo do file system (sistema de arquivos); outra API para operações assíncronas com I/O; e a atualização da API para comunicação via sockets ( channel sockets ).   O Java, antes da versão 7, tratava a manipulação do sistema de arquivos de forma primitiva. O programador tinha de trabalhar com a classe File para representar arquivos e/ou diretórios, com um número escasso de funcionalidades. Uma operação simples como copiar um arquivo demandava um código relativamente grande. Outras funcionalidades triviais, como por exemplo o uso de links simbólicos, não eram suportadas. Esses são alguns dos motivos para justificar o uso de bibliotecas terceiras...