Instrumentação e SOA

Estive estudando o tema instrumentação para falar em uma sessão do TechEd 2007.

Lendo, passei obrigatoriamente por WMI, namespaces como System.Management, etc., mas senti falta de algo mais direcionado para quem decide o onde colocar a instrumentação e quando ou como atuar sobre o software no momento da operação.

Duas dicas aqui.

A primeira é que existe no codeplex um projeto sobre o tema chamado Design for Operations. Embora em beta, ele já mostra um conteúdo teórico e prático para quem quer modelar a instrumentação que irá apoiar a operação de um aplicação composta.

A segunda é que existe um livro clássico e imperdível: Transaction Processing: Concepts and Techniques. Nele o assunto tolerância a falhas é desenvolvido, mostrando aspectos tanto de hardware e software quanto globais (holísticos).

(Uma curiosidade que reaprendi neste livro foi a macro classificação dos tipos de erros em software: os Heisenbugs que “é um erro de software transiente que aparece ocasionalmente e está relacionado com sobrecarga e timing”; e os Bohrbugs que, “como o átomo do Bohr, são coisas boas e sólidas com comportamento determinístico”.

Heisenbugs são mais freqüentes e podem ser tratados com a tática do failfast – a falha acontece, mas pode ser acertada rapidamente via, por exemplo, um reset e nova tentativa. Daí a importância dos conceitos ACID, reciclagem de processos ou programas que irão verificar e reparar estruturas de dados que foram quebrados.)

Para que tudo isto?

Bem, creio que a composição de serviços na arquitetura SOA vai aumentar em muito a necessidade de lidarmos com a instrumentação. Imagine o impacto que uma falha em um serviço pode causar em outros. Como lidar com as dependências? Que estratégias nós poderemos criar para minimizar o impacto de uma falha?

Idealmente, serviços devem indicar sua condição de saúde para que seus dependentes (e os dependentes destes) possam tomar suas providências.

SOA é um sistema distribuído e sistemas distribuídos são complexos... E, mesmo assim, continuam a ser uma alternativa mais barata do que um mainframe.

Software faz a diferença!