Desde o início de nosso trabalho com o cloud em 2009 temos investido tempo e pesquisa na utilização do cloud como plataforma para diminuir custos (e trabalho!) e potencializar produtos, através de diversos vendors.

Com a Amazon não é diferente: nosso sistema de ensino online está deployado lá. Com o lançamento de grande parte da sua plataforma no Brasil, a Amazon se torna uma opção ainda mais interessante de onde ter sua aplicação. Vamos ver passo a passo como fazer um deploy e aproveitar das novas vantagens da Amazon por aqui.

Primeiro nos logamos no painel AWS Manager, e escolhemos a região da América do Sul:

Depois escolhemos a imagem que usaremos para a máquina, no nosso caso uma instalação linux limpa, mantida pela própria Amazon. Existem centenas de instalações possíveis (de linux e windows) que podem ser buscadas no market da amazon.

Escolhemos então a potência da máquina e em qual availability zone ela ficará. Comecemos com “sa-east-1a“, que indica América do Sul:

Vale lembrar que uma aplicação realmente com alta disponibilidade precisaria ser deploiada em duas ou mais avaliability zones, mesmo sendo pequena a chance de uma zona cair.

Nas duas próximas telas escolhemos detalhes do Kernel e do RAM, além de possíveis tags que queremos dar para a máquina (em geral para trabalhar através dos web services). No nosso caso deixaremos os defaults.

Quando uma nova máquina é criada, precisamos nos logar nela e, para isso, precisamos de uma chave privada de acesso. A amazon pergunta qual o nome que devemos dar a chave, criando e permitindo que baixemos o arquivo. Note que a chave contida nesse arquivo é importantíssima e qualquer um de sua posse poderá ter acesso a máquina.

Por fim, escolhemos quais portas desejamos deixar abertas. No caso de uma aplicação Java com Jetty ou Tomcat, adicionamos a porta padrão 8080:

Isso mesmo, nada de complicados usuários e senhas. Nada de gerenciá-los através de ferramentas de webadmin desatualizadas. Nada de complicadas regras e configuração de firewalls. A Amazon então permite confirmar todas as opções, e o resultado é a máquina rodando:

A máquina possui um IP interno (para ser acessado de dentro da Amazon) e um DNS público, através do qual acessaremos a mesma de fora da Amazon. O DNS público pode ser visto ao clicar no nome da máquina:

Vamos acessar a máquina via ssh:

chmod 700 caelum-exemplo.pem
ssh -i caelum-exemplo.pem ec2-user@ec2-177-71-153-49.sa-east-1.compute.amazonaws.com

Resultando em:

The authenticity of host 'ec2-177-71-153-49.sa-east-1.compute.amazonaws.com (177.71.153.49)' can't be established.
RSA key fingerprint is 34:a6:de:34:88:fd:a1:73:ae:c5:03:f1:ed:8e:2f:96.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-177-71-153-49.sa-east-1.compute.amazonaws.com,177.71.153.49' (RSA) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

See /usr/share/doc/system-release/ for latest release notes.
There are 16 security update(s) out of 24 total update(s) available

Agora fazemos download do jetty, descompactamos e rodamos o servidor (se preferir, utilize o Tomcat):

wget http://download.eclipse.org/jetty/8.1.0.RC1/dist/jetty-distribution-8.1.0.RC1.tar.gz
tar zxf jetty-distribution-8.1.0.RC1.tar.gz
jetty-distribution-8.1.0.RC1/bin/jetty.sh start

O servidor irá inicializar e você logo receberá a mensagem de que ele está ouvindo a porta 8080.

2011-12-15 17:54:27.682:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:8080 STARTING

Pronto, acesse seu jetty:

E se desejarmos atualizar a imagem da máquina, com atualizações de seguranca? Se sua máquina não armazena o banco, mas sim somente arquivos voláteis (de fácil reinstalação), basta terminá-la e criar uma nova. Sistema operacional atualizado! Para manter dados voláteis, você pode usar o RDS da Amazon para seu banco Mysql ou Oracle (ou outras máquinas para bancos não relacionais) e manter um script de configuração (usar técnicas de configuration management).

Mais: com apenas alguns cliques é muito fácil de adicionar um load balancer através de sticky sessions, configurar ips fixos, etc.

O que você está esperando para fazer seu primeiro deploy por lá?

Depois de uma longa espera, temos o tão aguardado lançamento. O livro está sendo distribuído para as livrarias, e já é bem fácil encontrá-lo nas lojas online, como na Saraiva.

Foi bastante tempo e trabalho para criar uma introdução abrangente, e ao mesmo tempo com uma necessária profundidade, de alguns dos principais tópicos da plataforma Java. Em vez de apresentar respostas e fórmulas prontas, procuramos colocar questões para que os trade-offs tornem-se bem visíveis. Passamos por detalhes da JVM e design de classes até uso de frameworks, serviços, testes e automação.

Você pode encontrar detalhes do livro, conteúdo, além de algumas seções para ler no site oficial.

Haverá uma confraternização em São Paulo, dia 26 de janeiro, às 19h00, na Saraiva do Shopping Paulista, comemorando o lançamento do livro. Você está convidado!

Esperamos que aproveite nosso trabalho, e agradecemos a todos alunos, desenvolvedores e instrutores que possibilitaram essa realização.

Existem muitas motivações para os bancos NoSQL, como por exemplo usar um modelo mais adequado para os seu dados ou facilitar alterações de schema; ou ainda além, melhorar o desempenho e simplificar a replicação para ter a tão sonhada escalabilidade linear.

O teorema CAP

Claro que todos os benefícios não vem sem custo, comparado com os bancos de dados tradicionais vamos perder alguma funcionalidade/garantia para ganhar outra. O tradeoff arquitetural é descrito no bem conhecido CAP theorem.

Partition-Tolerance

Poder particionar nossos dados em diferentes nós de um cluster é um dos recursos que aparecem com frequência nos bancos NoSQL. e são conhecidos como Partition-Tolerant. No entanto, segundo o teorema CAP, em troca eles irão sacrificar a consistência forte ou a alta disponibilidade. Isso é diferente dos bancos tradicionais, que não possuem essa característica no design do sistema ou delegam isso para o filesystem.

NoSQL 1: Sistemas CP

Para sistemas que precisam da consistência forte e tolerância a particionamento (CP) é necessário abrir a mão da disponibilidade (um pouco). Pode acontecer, caso haja particionamento e o sistema não entre em consenso, que uma escrita seja rejeitada. Claro que os sistemas tentam evitar isso ao máximo, tanto que não costuma existir, por exemplo, uma transação distribuída e sim um protocolo de consensos para garantir a consistência forte. Exemplos desses sistemas CP são BigTable, HBase ou MongoDB entre vários outros.

NoSQL 2: Sistemas AP

Por outro lado existem sistemas que jamais podem ficar offline (24/7), portanto não desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo com um tolerância a particionamento (PA) é preciso prejudicar a consistência (eventual-consistency). A ideia aqui é que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento depois (read-consistency). Então pode ter uma janela de inconsistência. Exemplos aqui são Amazon Dynamo, Cassandra ou Riak.

Sistemas CA

Os sistemas com consistência forte e alta disponibilidade (CA) (alta disponibilidade de um nó apenas) não sabem lidar com a possível falha de uma partição. Caso ocorra, sistema inteiro pode ficar indisponível até o membro do cluster voltar. Exemplos disso são algumas configurações clássicas de bancos relacionais.

Qual é a diferença entra CA e CP?

Vimos brevemente o teorema CAP e a escolha que os sistemas NoSQL fazem (CP ou AP) comparado com os bancos tradicionais (CA). É importante mencionar que para o desenvolvedor não haverá tantas diferenças entre CA ou CP. SEMPRE teremos consistência forte, no entanto, um sistema fica indisponível (CA) quando há particionamento – pois tem apenas alta disponibilidade por nó – e o outro sistema (CP) tente chegar a um consenso se aceita uma escrita ou não, que no pior dos casos também pode significar a indisponibilidade para uma parte dos dados. Seguindo desse raciocínio podemos perceber que a consistência e disponibilidade são extremos quando há particionamento. Isso foi uma dúvida que me incomodou bastante antes da minha palestra no Caelumday 2009. Podemos concluir que quando há particionamento (P) terá alta disponibilidade (A) ou consistência (C) forte: P?(A|C)

Mas o que acontece se NĀO há particionamento?

É uma pergunta que o CAP não responde. A primeira resposta poderia ser: claro que vai ser consistente já que ninguém gosta de lidar com dados desatualizados. Mas olhando para os sistemas NoSQL nem sempre isso é verdade. Existem sistemas que SEMPRE são eventually-consistent. Mas porque?

Consistência ou Latência

Há mais um motivo porque poderia fazer sentido sacrificar a consistência: O tempo da resposta ou a latência. Da mesma maneira que um sistema offline pode custar caro, um sistema lento também pode. Por isso pode fazer sentido abrir a mão da consistência para diminuir a latência.

De CAP para PAC/CL

O artigo do blog do Prof. Daniel Abadi explica o tradeoff com partições e sem. Ele sugere substituir a sigla CAP com PAC/CL (ou P?(A|C):(C|L)), traduzindo levemente modificado do artigo dele:

“… se há particionamento (P), o sistema pode valorizar a disponibilidade (A) ou a consistência (C), senão, quando o sistema roda sem partições, o sistema pode favorecer o tempo da resposta/latência (L) ou a consistência (C).”

Exemplos de PAC/CL

Seguindo dessa linha PC/C significa que o sistema valoriza a consistência sempre, com ou sem partições. Banco de dados tradicionais são sempre fortemente consistentes, ou seja PC/C. Amazon Dynamo ou Cassandra são sempre fracamente consistente, favorecendo a alta disponibilidade e o tempo da resposta (latência), ou seja PA/L. Mas existem misturas como o GenieDB (PA/C), que só trabalha consistente em caso de nenhuma partições. Quando há partições valoriza a alta disponibilidade. Exemplo contrário disso é o Yahoo Sherpa, que usa PC/L, ou seja com partições favorece consistência, sem partições diminuir a latência.

Durante o curso FJ-91, diversas questões e decisões arquiteturais são abordadas e discutidas, sendo que uma delas envolve o teorema CAP e os bancos de dados NoSQL.

Quando pensamos na arquitetura de sistemas com grande volume de dados a primeira palavra que vem a mente é escalar. Além de desejar que cada uma das pesquisas em nosso sistema execute o mais rápido possível, precisamos criar meios para que, quando necessário, seja fácil adicionar mais recursos (como memória ou novos servidores) e o sistema consiga tirar proveito deles. Para isso muitas vezes precisamos ir além das diversas otimizações de performance e escalabilidade, como por exemplo a criação de um índice para buscas, o uso de caches e de chamadas assíncronas.

Outras duas abordagens importantes são a replicação e o particionamento horizontal (sharding). A simples ideia por trás da replicação é armazenar cópias dos dados em mais de um lugar. Em bancos de dados ela é tradicionalmente implementada através da criação de uma estrutura master-slave. O banco master é aquele onde são efetuados as alterações, que são então replicadas para o slave.

Clientes realizando a leitura de dados em diferentes fontes e o master replicando as escritas para o slave

Com isso as queries podem ser executadas agora não só em um, mas em dois nós. Quando as máquinas se sobrecarregarem de queries, criamos um novo nó slave que permite aliviar o trabalho das primeiras.

Com vários slaves, é possível aliviar a carga das máquinas. Nesse caso, o master não está recebendo leitura.

Em uma arquitetura comum onde o banco funciona no esquema master-slaves baseado em replicação, todos os dados estão contidos em todos os nós: a consistência é mantida.

Se um nó de leitura parar de funcionar, não tem problema para as queries pois, todos os outros nós são capazes de responder as mesmas. Mas se o master falhar, as atualizações não funcionam.

Quando um dos nós para de responder, os outros nós podem substituí-lo normalmente

Permitir escalar a leitura não aumenta necessariamente a performance percebida pela API: a query pode continuar lenta, mas mais queries podem rodar concorrentemente. Por outro lado, precisamos tomar cuidado na escrita: se a mensagem de atualização do master para os slaves for síncrona para garantir a consistência, o tempo de resposta para uma atualização fica maior.

Nesses casos podemos utilizar uma abordagem onde a replicação de uma atualização ocorre de maneira assíncrona e a consistência passa a ser em momentos indeterminados, mesmo que em banco de dados relacionais.

A replicação de dados nos permite garantir consistência através da redundância deles.

Em outra variação de replicação, qualquer nó pode responder por uma atualização e propagar tal mensagem para os outros: esse cenário é chamado de multi master. Outras variações como baseadas em Gossip podem ajudar a reparar dados que estão inconsistentes em determinado momento.

Em uma abordagem multi master, todos os nós trocam informações entre si

Mas a query ainda pode estar lenta, por exemplo, no caso de um full table scan – um sinal forte de que algo está errado no design do armazenamento de seus dados. Nesses casos tentamos dividir a localização física dos dados, despedaçando os mesmos e colocando pedaços deles em nós distintos. Essa prática é conhecida como Sharding (decomposição).

Dados de uma mesma tabela distribuídos entre vários nós através de sharding

A escolha de como dividir esses dados é dada através de um algoritmo de Sharding, que podemos escolher. O diagrama a seguir mostra duas opções para a distribuição dos dados em diversas máquinas:

Dados distribuídos de maneiras diferentes de acordo com o algoritmo de sharding

Dessa maneira podemos facilmente distribuir a execução de uma query em diversós nós, tornando um full table scan diversos scans a rodarem em paralelo. O sharding pode resolver o problema das queries lentas, no entanto, pode criar outros problemas. Imagine que um dos servidores utilizados nesse Sharding fique momentaneamente fora do ar. Consequência: tais dados ficarão indisponíveis.

Outro problema ocorre quando uma query busca dados em um nó e esse resultado envolve executar queries em outros nós distintos de acordo com cada resultado original, causando lentidão. Por isso, decidir o algoritmo de Sharding depende das queries a serem executadas a fim de fazer essa distribuição da melhor forma possível. Por exemplo, como o Twitter apresentou e o e-bay discutiu sobre tais escolhas em seus ambientes durantes palestras no QCon 2010 em São Paulo.

Para resolver tais problemas, uma solução é misturar o sharding com replicação, ganhando maior disponibilidade, deixando ao algoritmo a decisão de quais nós conterão determinados dados. Esse é um cenário de alta complexidade e por isso mesmo todo cuidado deve ser tomado para só ser adotado quando realmente necessário. Tais situações podem ser suportadas por ferramentas noSQL baseadas no paper do Dynamo, como Cassandra, Riak etc.
Cada ferramenta aborda o problema de uma maneira diferente:

“Bayou, Coda and Ficus allow disconnected operations and are resilient
to issues such as network partitions and outages.”
” Dynamo allows read and write operations to continue even during
network partitions and resolves updatedconflicts using different
conflict resolution mechanisms. ”

Arranhando como elas funcionam, quando um nó cai, os outros nos continuam trabalhando. Quando do momento de resolver o conflito, cada um utiliza uma estratégia diferente e permite diferentes abordagens para conciliar os dados conflitantes. Novamente, quanto mais escrita for feita para garantir a replicação, mais lento esse processo e as abordagens de atualização assíncrona podem fazer mais sentido novamente.

Dados distribuídos em vários nós

Um nó não precisa necessariamente ser uma cópia de outro nó, bastando que o elemento apareça em no mínimo N nós.

Conclusão

Escalar os dados de uma aplicação é uma tarefa complicada e a solução varia de acordo com o caso.

Fica fácil visualizar como a consistência se mantem em nosso sistema distribuído (eventualmente ou sempre) e como a maneira de executar as queries é alterada de acordo com a nossa necessidade de escalabilidade e performance.

Em alguns casos, simplesmente a replicação pode ser suficiente enquanto em outros pode ser necessário o Sharding ou uma combinação de ambos. Perceber a necessidade, entender como funciona processamento distribuído de dados e encontrar a combinação ideal é o grande desafio que o desenvolvedor ou arquiteto passa.

Agradecimentos ao Alexandre Porcelli pela revisão do artigo antes de sua publicação.

São diversos as aplicações web disponíveis, como quadros eletrônicos, sistemas de tracking, email e aplicações para empresas, ou até mesmo controle de clientes e vendas. Eles até ganharam um pomposo nome dentro do cloud computing: Software as a Service (SAAS).

O que essas aplicações possuem em comum? Todas elas atendem diversos clientes sem que um tenha conhecimento da existência dos outros.

Em um post recente no Tectura.com.br foram discutidas vantagens e desvantagens de diversas abordagens para produtos com a necessidade de suportar mais de um tenant.

A Microsoft categoriza três tipos de abordagens dependendo do nível de compartilhamento de recursos entre os clientes e apresente um relatório onde analisa os custos contra a segurança.

Em um extremo, nada é compartilhado entre cada cliente: para cada nova conta criada dentro de seu serviço, é criada uma nova máquina na cloud e uma instalação limpa é executada, com seu próprio banco.

Nessa abordagem o processo de autorização é automático, um cliente é criado através da instalação automática de uma nova máquina virtual e os recursos são compartilhados se o ambiente for uma cloud.

Na outra ponta, tudo é compartilhado: novos clientes são inseridos no mesmo conjunto de máquinas e a instalação é feita através de um simples insert no banco, adicionando um novo cliente. Qual abordagem escolher?

A autorização é feita programaticamente na aplicação, os recursos são compartilhados entre todas elas, escala-se tipicamente através do uso de load balancers e replicação master/slave e a cada novo cliente basta executar um insert no banco.

Em qualquer abordagem onde o banco seja compartilhado por diversas empresas, precisamos garantir a segurança dos dados de cada uma, para que nenhum acesso indevido ocorra, trazendo preocupações de autorização para dentro do código de nossa aplicação. Caso seja criado para cada cliente um banco em uma máquina no cloud, essa questão fica concentrada em um único ponto da arquitetura, a segurança está implícita.

Diversos servidores e um banco implica em clientes não afetarem uns aos outros, um controle programático de autorização e novos clientes são criados a partir da instalação de um novo contexto web.

Ao mesmo tempo, o processo de customização de seu serviço por cliente também é afetada de acordo com o nível de compartilhamento de dados entre eles. Na abordagem onde os clientes compartilham o mesmo servidor web, a customização é uma preocupação de nossa aplicação, enquanto ao utilizarmos aplicações web distintas para cada cliente, podemos facilmente separar customizações por instância, por deploy efetuado.

A escalabilidade é afetada pois compartilhar recursos em memória na camada web, entre eles dados cacheados do banco ou filas, permitem diminuir o tempo de processamento ou de latência, aumentando o número de requisições suportados.

O processo de escalar também está diretamente ligado: quando uma máquina não aguentar mais as requisições, será levantada uma outra máquina que funcionará em cluster para um, n ou todos os clientes?

Outro fator importante é como limitar o uso do serviço de acordo com as regras contratadas pelo cliente e controlar o dano que um pode causar a outros. Em um pico de uso por parte dos usuários de um cliente, ativamos o chargeback, dependendo do tipo de serviço que é prestado. Implementações comuns de chargeback em cloud (baseados em virtualização) permitem um pico de consumo temporário ou até mesmo mover a aplicação de uma máquina para outra sem que cliente algum perçeba o que está acontecendo.

Diversos servidores e um banco implica em clientes não afetarem uns aos outros, um controle programático de autorização e novos clientes são criados a partir da instalação de um novo contexto web.

Ao invés daqueles usuários atrapalharem a performance de outros clientes, é alocado memória e processador distintos dos atuais para ele.

A simplicidade do código é um dos fatores mais afetados pela escolha feita: um código que sabe da existência de múltiplos clientes está diretamente ligado a uma chave que identifica o cliente atual. E essa ligação se reflete por todos os lados do código, uma vez que o comportamento da aplicação em geral depende dele: uma chave estrangeira, um relacionamento, que vai permear toda a aplicação.

Caso a aplicação implemente o suporte a multi tenant através de instalções web distintas, com configurações para cada cliente apontando para um bancos distintos, o código fica mais simples e fácil de manter, uma vez que não é necessário se preocupar com a existência de outros clientes.

Por fim, uma preocupação que surge para a empresa provedora dos serviços é de como agrupar os dados existentes em todos os clientes e gerar relatórios de administração e estatísticas que permitam a melhora do serviço prestado. Quando possuimos um único banco, escalado através de master slave ou múltiplos nós, basta executarmos queries longas (sql ou não), mas se o sistema estiver distribuido entre diversos bancos sem ligação entre si, um processo de batch deve rodar para agrupar os dados e permitir o consumo posterior pelas ferramentas de BI.

É importante analisar todos esses pontos antes de tomar a decisão se o controle de espaço de aplicação por cliente será feito no nosso código, na camada web, no banco ou em algum outro ponto. Como discutimos bastante no curso de arquitetura, toda e qualquer decisão implica em um tradeoff: o importante é saber o que está sendo trocado e qual é o impacto disso.

Durante o atual processo de revisão do livro de Arquitetura e Design de Software, discussões apareceram sobre o termo arquiteto. Antes de definir o que faz um arquiteto, há o termo arquitetura.

Quem é o arquiteto? Aquele que senta sozinho e toma todas as grandes decisões?

O que é a arquitetura de uma aplicação?
Uma pergunta difícil de responder. Entre as definições mais antigas, Roy Fielding possui um bom texto no primeiro capítulo de sua dissertação de doutorado. O Instituto de Engenharia de Software da Universidade de Carnegie Mellon apresenta diferentes definições, algumas clássicas e bastante conhecidas, como “arquitetura é a estrutura do sistema, composta de componentes, as propriedades que são visíveis externamente desses componentes e o relacionamento entre eles“.

Nas palavras de Martin Fowler, “o termo arquitetura envolve a noção dos principais elementos do sistema, as peças que são difíceis de mudar. Uma fundação na qual o resto precisa ser construído“. Fowler reformula sua definição de arquitetura e a define como “as peças que as pessoas acham que é difícil de mudar“. No mesmo artigo Ralph Johnson, do GoF, diz que arquitetura “é o conjunto de decisões de design que gostaríamos de ter feito no começo do projeto” e termina com uma definição mais abrangente: “arquitetura é tudo aquilo que importa“. Com tantas definições, talvez seja mais fácil diferenciarmos design de arquitetura.

Qual é a diferença de design e arquitetura de software?
Aqui também temos uma resposta clássica na literatura: a arquitetura é responsável pelos requisitos não-funcionais, e o design pelos funcionais. Mas parece que essa distinção não é tão clara assim para muitos outros autores.

Neal Ford apresenta uma distinção simples, realçando que o design é feito em cima do que foi decidido pela arquitetura, e por isso o que faz parte da arquitetura é mais difícil de mudar. Devemos minimizar as peças que dificultam mudanças do nosso design, mas é impossível eliminar todas, além de que flexibilidade sempre vem a um custo de complexidade.

É difícil criar um distinção maior entre os dois. No livro Patterns of Enterprise Application Architecture, Fowler diz que “alguns dos padrões nesse livro podem ser chamados arquiteturais, já que representam decisões importantes sobre essas partes; outros são mais sobre design e te ajudam a implementar essa arquitetura. Eu não faço nenhuma tentativa forte de separar esses dois, já que é o que é arquitetural ou não é subjetivo“.

O arquiteto deve saber programar na plataforma em questão?
Sem dúvida. Cada vez mais vemos que o design e a implementação devem ser trabalhados juntos. A imagem de um arquiteto distante sem profundo conhecimento técnico que apenas toma as grandes decisões ficou pra trás: conhecimento técnico e a capacidade de liderança são as características fundamentais.

Mais do que querer ser o poderoso arquiteto que apenas despacha ordens e toma todas as grandes decisões, cada vez mais enxergamos que o caminho é ser o líder que incentiva essa tomada de decisão, além de ser um exímio programador. Parafraseando mais uma vez Martin Fowler, “…o arquiteto deve ser como um guia… que é um experiente e capacitado membro da equipe que ensina aos outros a melhor se virarem, ainda assim ele está sempre lá para as partes mais complicadas“.

Vale lembrar que precisamos de mais de 10 mil horas, ou 10 anos, para dominar uma linguagem.

Um dos grandes desafios enfrentados no dia a dia do desenvolvedor eficaz é o de cumprir requisitos não-funcionais de uma aplicação, principalmente os relacionados a performance e escalabilidade. Uma das alternativas mais conhecidas para escalar horizontalmente é a de dividir as tarefas que não necessitam de retorno imediato ao cliente em processos batch. Para tanto, podemos usar diversas ferramentas, desde soluções caseiras até diversos frameworks, tanto em ruby como em java.

Quando se trata de processos batch, é comum buscar um controle mais fino sobre o resultado da execução (sucesso, falha, pendente, etc). Normalmente, usaríamos bancos relacionais para isso, tanto pela sua popularidade como pela performance. Supondo que eu precise gerenciar 1000 pequenas tarefas simultâneas, pagaríamos um preço bem alto pela concorrência, visto que o banco começaria a demorar para obter o lock, fazer o insert, refazer o lock e atualizar o status da tarefa. Muitos consideram o uso de banco de dados relacionais um erro para casos como esse. Buscando eficiência, poderíamos usar uma solução NoSQL para persistência e controle das tarefas, onde evitaríamos os locks, graças ao modelo de concorrência simplificado.

Uma opção em ruby é o resque, um framework de processamento batch criado pelo github que utiliza o redis, um banco de dados não-relacional, tanto para persistir as tarefas, como para coordenar os diversos processos executores de tarefas, mais conhecidos como workers.

Agendar um processo é bem simples – basta que eu tenha uma classe ruby com um método perform, com o processamento a ser executado e um atributo de instância @queue define em qual fila a tarefa será colocada:

# uma classe qualquer, poderia ser um model
class Relatorio
    @queue = :relatorio_anual

    def self.perform(ano)
        gera_relatorio_anual(ano)
    end
end

e finalmente, faço o agendamento:

#método recebe a classe da tarefa, e os argumentos
Resque.enqueue(Relatorio, 2009)

Essa chamada faz uso bem eficiente de metaprogramação, de maneira que um worker posteriormente executará um código semelhante a esse:

classe, argumentos = Resque.reserve(:relatorio_anual)
classe.perform(*argumentos) if class.respond_to? :perform

posteriormente iniciamos um worker usando as tasks do rake que vem no próprio resque, indicando qual fila o worker que estamos criando vai atender

$ QUEUE=relatorio_anual rake resque:work

assim que o worker subir ele já irá executar Resque.reserve, que o colocará em espera por novos trabalhos. opcionalmente, poderíamos executar um worker para atender todas as filas:

$ QUEUE=* rake resque:work

O principal fator que contribui para que resque e redis funcionem como um relógio é o fato de ambos estarem focados em alta performance e, ao mesmo tempo, extrema simplicidade sem ser muito invasivo, já que permitem que você mantenha sua estrutura de persistência relacional inalterada.

Cada vez mais sistemas vem utilizando solucões NoSQL para algumas funcionalidades específicas, como foi o caso recente do Large Hadron Collider com o Mongo DB. Parece que a combinação de bancos relacionais e não-relacionais no mesmo sistema, cada um com seu propósito, tem sido a direção tomada pelo mercado.

Não é novidade empresas economizarem milhares de dólares ao adotarem o cloud, como foi o caso do New York Times. Agora, foi a vez do governo norte americano, que deve economizar mais de um milhão de dólares até 2011 através do Amazon EC2.

Governo americano começa a adotar o cloud.

O Amazon EC2 permite inúmeras configurações diferentes e você pode tomar diversas decisões: quantos servidores precisa, como fazer o balancing, quando colocar ou retirar um novo servidor, etc. Ele te serve com a infraestrutura que você definir, abstraindo o hardware, daí o termo Infrastructure as a Service (IaaS).

A outra opção é a Platform as a Service (PaaS), que restringe suas opções: essa modalidade costuma definir frameworks, uso de threads, conexões, sistema de arquivos e até mesmo qual banco de dados você vai utilizar.

O Google App Engine (GAE) é hoje o líder em plataforma como serviço. Você tem uma série de restrições para utilizá-lo, e o único banco de dados que pode utilizar é um não relacional, o BigTable do Google. Nesse mesmo grupo, encaixam-se o SalesForce (Force.com), o Heroku e o recentemente anunciado VMForce (junto com a SpringSource).

Por que então alguém utilizaria o PaaS em vez de IaaS, se teremos restrições?

Como Krishnan Subramanian descreve em três artigos, o PaaS abstrai todo o ambiente e middleware para você, até mesmo as decisões operacionais e de configuração. Ele vai além, e diz que o PaaS é quem vai ganhar grande parte do mercado, dado que cada vez mais as aplicações, mesmo as que não necessitam (ao menos por enquanto) de grande escalabilidade, vão migrando para o Cloud. Colocar sua aplicação no PaaS é muito mais simples que no IaaS, mas você tem de pagar o preço: suas restrições.

A Caelum usa o Cloud do Google App Engine há mais de 6 meses, e isso já nos salvou de picos de acesso ao sistema de reserva e acesso ao site, como quando a Info Online noticiou nossas apostilas ou quando enviamos nossa newsletter para os milhares de usuários cadastrados. E, mesmo para um site pequeno como o da Caelum, sem grandes requisitos de escalabilidade, a tranquilidade de saber que ele não ficará indisponível por causa de picos momentâneos é o grande atrativo. Além, claro, da enorme redução de trabalho com infraestrutura e custo.

E você, planeja migrar sua aplicação para o Cloud e diminuir a dor de cabeça com escalabilidade? Ela está apta para enfrentar bancos não relacionais ou restrição a threads e file system no PaaS, ou você vai direto para o IaaS, tendo total controle porém mais trabalho operacional?