Simplificando a Arquitetura Orientada a Serviços
Pois é, de acordo com o blog do Twitter publicado hoje (22/Fev/2010), chegamos a 50 milhões de tweets por dia, ou 600 tweets por segundo (TPS!).
Como eles mantém este serviço relativamente estável? Qual arquitetura que eles utilizam? Veja estes detalhes no post “Arquitetura do Twitter e Google Talk: Lições Aprendidas“.
Muito tem-se lido e ouvido sobre computação nas “nuvens” ou “cloud computing” porém, fora os “datacenters nas nuvens”, ainda sabemos pouco sobre exemplos reais, soluções práticas que utilizem este paradigma de computação.
Um exemplo é o anti-vírus nas “nuvens”. Veja meu post “Anti-vírus nas nuvens” e um outro exemplo que detalhei em “Energia sob Demanda? Use SOA e BPM”.
Uma máxima da engenharia de processos afirma que: “Você só controla aquilo que mede”.
Com base nisto, os pesquisadores da IBM, em conjunto com a empresa Consert (de onde vem a imagem utilizada neste post), desenvolveram uma solução para medição e acompanhamento (pela Internet) da energia elétrica de empresas e residências.
O simples ato de acompanhar estes dados já sinaliza, positivamente, mudanças em nosso estilo de vida. Detalhes como desligar equipamentos que ficam eternamente em stand-by, o tempo no chuveiro elétrico, temperatura da geladeira nas madrugadas etc.
A economia esperada é de 40% o que, na minha opinião, é muito. Mas creio ser possível reduzirmos isto e ainda mais (quem não se recorda da época do risco do “apagão”, em que foi necessária uma redução maior do que isto?). De acordo com esta matéria da FastCompany.com, o projeto-piloto iniciou em Julho/2009 no estado da Carolina do Norte. Utiliza uma rede 3G da operadora Verizon para que os medidores inteligentes (“smart meters”) transmitam as informações para um banco de dados na Internet (olha a “nuvem” aí).
Os usuários que fazem parte do projeto podem verificar seu consumo diário na rede, e o sistema projeta o custo final no mês, baseado no perfil de consumo histórico. Adicionalmente, o Consert system pode controlar até 256 dispositivos domésticos, desligando-os quando você está fora de casa. O vídeo abaixo demonstra o objetivo do projeto, do ponto de vista da empresa de energia:Controlando dispositivos domésticos
Uma discussão recorrente no mundo da arquitetura orientada a serviços (SOA) é como o Business Intelligence (BI) se integra neste cenário e, no caso da empresa onde trabalho (operadora telecom), como disponibilizar dados em tempo real para o BI.
Antes de mais nada sabemos que o Business Intelligence não tem a premissa de tratar dados em tempo real. Utilizamos para consolidar dados de várias fontes, gerar gráficos e relatórios para os vários níveis da empresa (operacional, tático e estratégico), como um dashboard para os tomadores de decisão etc, mas quase nunca como uma ferramenta de análise de dados em real time.
BI
Falando em BI, em uma pesquisa realizada alguns anos atrás, mostrou os principais motivadores que levavam as empresas a adotar esta solução:
(fonte: http://www.information-management.com/issues/20040201/8034-1.html)
Análise de Dados em Tempo Real
Soluções do tipo BAM (Business Activity Monitoring), e mesmo os já conhecidos BI, podem demandar a apresentação de dados e gráficos de dados com uma latência menor. Alguns exemplos simples: vendas realizadas na última hora, ligações telefônicas completadas com sucesso nos últimos 45 minutos, lotes produzidos nas últimas 2 horas, transações com cartão de crédito no últimos 5 minutos etc.
Se o volume for considerável, milhões de transação no caso de uma operadora de telecom ou de cartão de crédito, é um desafio disponibilizar estas informações através do BI ou BAM. Não apenas estes dois mercados, mas todas as operações onde temos eventos em real-time que precisam ser capturados, correlacionados e apresentados para monitoramento em tempo real.
Estes cenários são típicos de Complex Event Processing (CEP) e Event-driven Architecture (EDA). Detalhes adicionais neste link.
Oracle e Integração de Dados em Tempo Real
Ontem (23/Jul/2009) a Oracle anunciou a compra da GoldenGate, uma empresa de San Francisco, Califórnia, que possui uma solução de integração de dados em tempo real. Veja a imagem abaixo que consta na apresentação oficial da Oracle:
Verifique que a solução da GoldenGate alega que extrai e disponibiliza os dados em “tempo real” para vários “consumidores”, entre eles: Message Bus típicos de arquitetura SOA/EDA e o que eles denominam “Operational BI“.
Veja uma arquitetura simplificada de onde como a solução da GoldenGate disponibiliza dados em tempo real para ferramentas de análise e BI:
A apresentação detalha ainda alguns cases de sucesso da implantação solução da empresa de San Francisco. Mesmo sendo um material com viés promocional de como os produtos da Oracle serão integrados com o da GoldenGate, a leitura vale a pena.
Neste artigo Mark Little, CTO da Red Hat discute um pouco sobre governança SOA e algumas métricas importantes neste mundo de arquitetura orientada a serviços.
Apesar de um pouco superficial (não apresenta qualquer fórmula ou exemplos práticos), o texto nos mostra quais indicadores importantes devemos colocar nosso foco. Abaixo a lista de Mark Little:
- Return on Investment (ROI) per service
Medir o ROI é complicado em qualquer cenário/arquitetura de software. Em SOA, mais complicado ainda. “Holísticamente”, como diz este artigo do Leo Shuster, estrategista SOA do National City Bank (EUA), o ROI do seu programa (conjunto de projetos) SOA pode ser calculado através da seguinte equação:
SOA ROI ($) = Cost Savings/Efficiencies Achieved – All SOA-Related Investments
or
SOA ROI (%) = SOA ROI ($) All SOA-Related Investment
Um dos “complicômetros” desta métrica é que alguns serviços são dependentes de outros para executar a regra de negócio à qual ele se propõe (objetivo). Assim, o ROI deste serviço deve ser medido ao longo de toda cadeia de dependência dos outros serviços/componentes. O autor lembra também que medir o ROI não significa necessáriamente que um serviço específico vai gerar receita.
- Revenue per service
Receita por serviço. Métrica diretamente relacionada com o ROI. A proposta é priorizar os serviços pelos retornos “teóricos” de investimento, classificando-os pela receita que eles produzirão.
- Service grow rate/reuse
Uma das grandes vantagens de SOA é o reuso de serviços. Pelo menos é isto que eu falo quando tento vender a idéia por trás da arquitetura. Na verdade, uma boa arquitetura, no mínimo, avalia esta possibilidade e projeto o serviço para que o mesmo seja reutilizado, gerando enormes economia de tempo/recurso e manutenção daquele código.
Este indicador é importante para definir o ROI e acompanhar o quanto um serviço vai ser/está sendo reutilizado força seu time a revisitar as implementações e avaliar a performance.
O que geralmente ocorre é que, mesmo que você tenha desenhado um serviço com a preocupação no reuso, dificilmente você sabe por quantos sistemas e sub-rotinas o mesmo está sendo invocado. No momento de stress com performance você tem esta informação na mão? I guess no.
- Business agility
Quanto tempo leva entre o planejamento do serviço e seu deployment? SOA traz agilidade, correto? Não foi isto que voê vendeu para seu cliente? Então, esta é uma métrica excelente para você exibir para seu patrocinador, mostrando que, de fato, o quanto esta nova forma de conceber soluções de software traz ganho para a empresa.
- Reliability
Métricas de confiabilidade (SLA) já utilizadas em outros ambientes (SOA ou não):
- mean time to failure (MTTF) e
- mean time to recovery (MTTR)
- Service inter-dependencies
Nada no mundo está isolado. Quanto um serviço depende de outro? A idéia é classificar e documentar o “nível” de interdependência dos serviços. Este serviço tem uma dependência “fraca” ou “forte” destes outros? Estes serviços com alta dependência podem ser classificados como uma única “unidade lógica”?
Como em muitos projetos que utilizam esta arquitetura, a idéia é começar a medir e extrair algumas métricas do seu ambiente. As coisas tendem a ficar um pouco mais complexas. Exemplo: Cloud Computing. Imaginar que parte destes serviços e infra-estrutura pode estar em qualquer lugar da “nuvem” é uma idéia que deve dar pesadelo em todo gestor de TI, mas já é uma realidade que não tem volta.
Melhor começarmos a medir este indicadores agora.
Mais sobre métricas de SOA nesta nota.
Lá a arquitetura SOA é utilizada para gerenciar e monitorar eventuais emergencias no LHC (deve ter sido utilizado depois das falhas).
Foi utilizado o SonicMQ (da Progress Software) como backbone de comunicação do sistema de monitoramento técnico conhecido como Technical Infrastrucure Monitoring (TIM).
Vejam alguns números:
