Está rolando uma discussão no .Net Architects que eu acho que vale a pena comentar aqui. A questão é em torno de alguns problemas que a computação na nuvem pode trazer, e como resolver estes problemas. O principal é consistência versus disponibilidade, algo comum quando se trata de sistemas tão distribuidos.
Li esses dias um post do blog do Otávio Pecego Coelho, arquiteto da Microsoft, onde ele comenta sobre consistência e disponibilidade com Azure. E nesse post ele aponta para outro post, que é na verdade, um bom artigo. Achei muito interessante. E não só para quem for trabalhar com computação na nuvem, mas também com sistemas distribuídos, escalabilidade e disponibilidade. Basicamente o autor compara as transações ACID comuns em banco de dados com um outro modelo que ele chama de BASE (para contrastar com ácido: base). Quem está acostumado a trabalhar com ACID nem concebe que pode haver outra forma de fazer as coisas, mas há. E esquecemos com frequência que transações ACID matam a disponibilidade, e por isso a idéia de usar BASE.
Em dado momento ele apresenta um estudo que me fez fazer uns exercícios mentais para confirmar, e parece que está certo. Segundo o estudo, apresentado como o teorema CAP, você precisa escolher em um web service somente dois itens dos seguintes (em inglês para manter a sigla):
- Consistency
- Availability
- Partition Tolerance
(O estudo está aqui. Lá em baixo da página há um link “view or download”. É um pdf. Não li mas parece valer a pena também.)
Ou seja, se você quiser tolerância ao particionamento, que é o que acontece em uma arquitetura baseada em serviços (cada serviço seria uma partição), vai ter que escolher entre disponibilidade e consistência, já que só pode escolher dois itens. E é um fato. Operações ACID vão bloquear tudo até o último componente realizar um commit, matando a disponibilidade. Já operações BASE vão focar em disponibilidade, mas ao custo de uma inconsistência temporária. É sobre este problema: como tornar essa inconsistência em algo apenas temporário, que o artigo se propõe a discutir. Vale a pena ler.
Ah, e não adianta misturar ácido e base. Todo mundo que lembra das aulas de química sabe que o resultado é sal e água.
Giovanni Bassi
Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.