quarta-feira, 28 de julho de 2010

Teorema de Brewer (CAP)

Eric-Brewer-small.jpg O teorema CAP descoberto por Eric Brewer, foi apresentado pela primeira vês a 19 de Julho de 2000, quarta-feira, no simpósio da ACM intitulado "Principles of Distributed Computing" .

Este teorema resultou de um extenso trabalho de observação do comportamento dos sistemas da Inktomi e veio a revolucionar a arquitectura de sistemas de grande escala.

Nomeadamente a arquitectura dos sistemas da Amazon, eBay e Twitter entre muitas outras.

Mas afinal o que é o teorema de Brewer?

Brewer identificou 3 requisitos sistémicos fundamentais que se influenciam mutuamente no desenho e instalação de sistemas distribuídos.

Estes são: Consistência, Disponibilidade e Tolerância a Quebras - "Consistency, Availability, Partition Tolerance" ou CAP.

Consistência

Um sistema é consistente se não gerar resultados contraditórios entre si tendo como base a lógica de negócio implementada.

Por exemplo, partindo do princípio que aplicação foi testada e a lógica implementada está correcta um sistema consistente garante que:

  • o mesmo livro nunca será endereçado para dois clientes distintos em simultâneo;
  • um contrato de seguros não será realizado com um cliente com elevado grau de sinistralidade;
  • um cliente nunca pagará mais ou menos do que o valor em factura;
  • nunca serão dadas ordens de pagamento em duplicado;
  • um cliente não pode pagar com VISA um valor assima do seu plafond;
  • entre muitos outros cenários e regras que poderíamos enumerar.

Disponibilidade

Um sistema está disponível sempre que dá resposta ás solicitações dos seus utilizadores, e indisponível caso contrário.

Por exemplo, quando se submete um contracto de seguros quer-se que o sistema responda e que não dê uma mensagem do tipo "time-out" ou "sistema indisponível".

Um sistema pode ser mais ou menos disponível num período de tempo. No entanto num determinado momento T está ou não está disponível.

Tolerância a Quebras

Uma quebra no sistema é a falha de um componente ou ligação entre componentes da solução.

Por exemplo se a nossa aplicação está distribuída por múltiplos "tiers" ou nós numa rede informática, uma quebra pode ser o servidor desligar-se, o router bloquear ou um cabo de rede partir-se e deixar de funcionar.

Como é óbvio nesta configuração a probabilidade haver quebras nas ligações entre os componentes da solução é elevada quando comparada com uma solução de máquina única.

Um sistema é tolerante a quebras se nada menos do que a falha total da rede formada pelos seus componentes o leve a deixar de funcionar correctamente.

A Revelação de Brewer

A revelação de Brewer é que não é possível que um sistema informático preencha estes 3 requisitos em simultâneo. Mante-los e escalando o sistema ao mesmo tempo por forma a dar conta do aumento de actividade, torna-se cada vês mais dispendioso atingindo um ponto de impossibilidade técnica com impacto directo na disponibilidade.

Quantos de nós em grandes empresas já ouvimos dizer, o sistema está lento, está indisponível ou "está em baixo" durante minutos e em alguns casos horas?

Acabo assim com estas duas questões. 10 anos depois ...

  • É este teorema significativo para os departamentos de IT das grandes empresas em PT, nomeadamente na forma como o negócio é gerido electrónicamente?
  • Qual é o seu significado técnico para os departamentos de IT de hoje em PT?

terça-feira, 27 de julho de 2010

Assim começa este blog

Olá, chamo-me Nuno Lopes e sejam bem vindos a este Blog.

A minha carreira conta com mais de 20 anos de experiência no desenvolvimento de software empresarial. No entanto em boa verdade quanto mais mais aprendo mais tenho consciência que sou perito de coisa nenhuma.

Serve assim isto como mote para criar este espaço de reflexão e partilha daquilo que aprendi e do que me falta ainda aprender sobre o que de melhor se faz pelo mundo fora na área do desenvolvimento de software empresarial.

Conto assim com os vossos comentários.

Bem ajam,

Nuno Lopes