Com a crescente demanda de aplicações extremamente rápidas e disponíveis programação reativa está se tornando um tópico cada vez mais popular e relevante dentre os círculos de desenvolvimento de software.
Atul Shukla e Revanth Talari da USEReady fizeram uma apresentação fantástica sobre esse assunto no AWS Reinvent 2014, mostrando como podemos converter uma aplicação com uma arquitetura não-reativa para uma arquitetura reativa. Nesse artigo vou apresentar alguns dos conceitos chave da apresentação.
Uma aplicação não reativa, geralmente é Sincrona, Acoplada, Bloqueante e Puxada, veja na imagem:
Uma aplicação reativa, em contrapartida, como você leu no artigo anterior é:
1. Responsiva
Empurrada em vez de puxada, a aplicação faz pushes para o client em tempo real.
Para alcançar esse objetivo os palestrantes utilizaram instâncias EC2 na AWS como servidores WebSocket e o serviço de notificações da AWS, o SNS, para fazer pushing e atualizar os demais clients.
Para os Websockets, utilizaram SockJS tanto no client HTML5 (browser), como no server com NodeJS.
2. Resiliente
A aplicação deve continuar funcionando mesmo que alguns componentes falhem, veja na animação abaixo para compreender melhor:
Para tornar a aplicação resiliente, criaram instâncias que executam a aplicação simultaneamente em diversos Datacenters (Availability Zones), com Route 53 para fazer tratar o DNS.
3. Elástica
A aplicação deverá escalar de acordo com a demanda, quando aumentar a demanda, utiliza mais instâncias de servidores, e quando a demanda diminui reduz a quantidade de instâncias, veja a animação para compreender melhor:
Para tornar a aplicação elástica, os palestrantes utilizaram o ELB (Elastic Load Balancer) para fazer o balanceamento de carga entre as instâncias EC2, Autoscaling para aumentar e diminuir a quantidade de instâncias EC2. Utilizaram também o Elastic Beanstalk para fazer deploy das aplicações nas instâncias, e DynamoDB como um banco de dados extremamente rápido e de baixa latência.
4. Guiada por Mensagens
Os componentes são desacoplados e colaboram através da troca de mensagens.
Para isso os palestrantes utilizam os serviços SQS (Simple Queue Service) para enviar mensagens e SWF (Simple Workflow Service) para criar tarefas para processar e retransmitir as mensagens.
Arquitetura Reativa
Convertendo nosso modelo inicial para o modelo reativo, teremos algo assim:
Resumindo, no modelo de arquitetura final, nós recebemos mensagens dos clients HTML que são enviados para uma fila SQS, que é enviada para um worker do SWF que grava a mensagem no DynamoDB e envia também para uma nova fila do SQS, então, outro worker do SWF puxa as mensagens e notifica os demais clients HTML sobre a nova mensagem através de um push pelo SNS. Genial!
A Palestra
Veja o vídeo e acompanhe os slides da palestra, se quiser aprender com os próprios palestrantes:
[slideshare id=41673462&doc=arc206-141117155257-conversion-gate02]
Conclusão
Arquiteturas reativas permitem aplicações mais disponíveis, mais rápidas e mais confiáveis! Com a ajuda de ferramentas como WebSockets, DynamoDB, EC2, Autoscaling e Serviços de Mensagens (SQS, SNS, SWF) podemos construir aplicações reativas com esforço relativamente baixo.
Não esqueça de deixar seu comentário com suas impressões!
Essa é a arquitetura dos sonhos pra quem realmente ama o que faz 🙂
André, onde vc acha que entraria o AWS Container Services (Docker) e o AWS Lambda nessa arquitetura? Achei muito bem bolada a ideia desses dois serviços.. O que eles se propõe a facilitar nossas vidas..
Olá Rômulo,
Ambos os novos serviços são muito interessantes e vão nos ajudar a simplificar muitas arquiteturas e soluções!
O AWS Lambda vai nos ajudar a pensar em funções como um serviço (function as a service), você pode fazer deploy de uma função (como redimensionar uma imagem no S3, por exemplo) e não se preocupar em nada com máquinas EC2 ou como escalar essa função para atender maior demanda.
Já o Container Service, vai nos trazer muitos benefícios de poder aproveitar melhor ainda os recursos das instâncias que temos, e especialmente a lidar melhor com o ambiente das nossas aplicações. Compartilhar um mesmo ambiente para diferentes aplicações que tem dependências diferentes pode se tornar uma enorme dor de cabeça, e o Docker é muito eficiente em resolver isso. Além disso, acho que tem bastante aderência as populares arquiteturas baseadas em microservices.
Nesse cenários que os palestrantes apresentaram, possivelmente poderíamos ter usado, por exemplo, uma função Lambda para fazer o processamento das mensagens baseado em gatilhos da primeira fila SQS alimentada pelo client, e quem sabe, poderíamos utilizar o Container Service para fazer deploy do SocketJS Server.
Continue acompanhando o blog, pretendo falar mais sobre esses dois serviços no futuro com casos práticos.
Abraços.
Realmente fantástico! Obrigado por compartilhar seu conhecimento.
Fantástico!
Show
Gostei bastante desse tipo de arquitetura.
Show de blog a apresentação e o seu post.
Show! Parabéns!!