Andei programando esta semana para o Azure. Me senti como num parque de diversões: ora surpreso com a simplicidade, ora me vendo voltar à infância da computação. Este último sentimento se deve muito ao uso de estruturas básicas como blob, table e queue, sem um sistema de transação ao seu redor para garantir as propriedades ACID.

Por que o Azure não nos dá um sistema ACID?

Bem, o Azure é um sistema operacional que visa a escalabilidade através do particionamento e redundância da informação. Quando escrevemos em um blob, por exemplo, o conteúdo desta escrita é geograficamente distribuído para outros discos, e isto ocorre com alguma latência. Como sabemos, lock com latência não é uma boa química, pois juntos produzem desempenho sofrível. A resposta então é não permitir o lock e aceitar estados transitoriamente inconsistentes! (?)

Como lidar com isto, logo nós tão viciados nos sistemas transacionais como os nossos bons (e hoje já velhos) Bancos de Dados?

Uma boa dica é a leitura deste artigo BASE: An ACID Altertive. BASE é o acrônimo de Basically Available, Soft state, Eventualy consistent. O acrônimo é um pouco forçado para se opor ao significado químico de ACID, mas este é um modelo de programação que aceita os limites impostos pela conjectura de que serviços web têm de escolher 2 entre as 2 seguintes capacidades: Consistência, Disponibilidade e Tolerância ao particionamento. No Azure, como em outros sistemas web, a tendência é liberar a Consitência em prol das outras duas.

O artigo é simples e mostra o que muda no nosso estilo de programação. Lá você poderá voltar a dar valor ao seu sistema de filas e, quem sabe, como eu, usar esta técnica para repensar seu modelo de programação para SOA.

Boa Leitura.

 

PS.: Não sei quantos de vocês trabalham em projetos com equipes geograficamente distribuídas. Mesmo assim não resisto à dica de indicar o recém saído documento Distributed Agile Development at Microsoft Patterns & Practices. (Boa Leitura)2