Martin Thompson anunciou a segunda versão do Manifesto Reativo no Goto Aarhus 2014. Esta nova edição apresenta diferenças sutis tanto no nome como nas abordagens prescritas pelo documento original. O InfoQ.com entrevistou Thompson pouco depois do anúncio e discutiu as implicações destas mudanças e o futuro da comunidade reativa. A conferência React 2014 em São Francisco vai mergulhar fundo no manifesto reativo e suas implicações, bem como mostrar experiências de desenvolvedores que estão colocando em prática suas idéias.
InfoQ.com: O Manifesto Reativo foi bem recebido e tem ganhado crescente aceitação na comunidade de desenvolvimento. Por que foi necessário reescrevê-lo?
Thompson: Após a publicação do manifesto original recebemos uma grande quantidade de feedbacks. Geralmente, estes feedbacks foram muito positivos uma vez que muitas pessoas começam a se dar conta do ambiente de mudança constante no desenvolvimento de aplicações. No entanto, também recebemos feedback positivos informando que a versão anterior era muito verbosa e, em alguns pontos, focada de forma desproporcional em especificidades. Fomos encorajados a reescrevê-la de forma mais concisa e focada nas propriedades que sistemas reativos devem apresentar. A máxima: "Se eu tivesse mais tempo, teria escrito uma carta menor... " definitivamente se aplica neste caso. Além do mais, o feedback de uma audiência mais ampla ajuda a refinar o foco.
InfoQ.com: Por que agora?
Thompson: Pessoas como Kresten Krab Thorup ajudaram a deixar claro no manifesto o "por quê agora". Ele conseguiu sintetizar o que outros tem experimentado e enfatizou que vivemos em um mundo no qual a internet é o canal principal de muitas organizações com o mercado, se não o único. Ele combinou este fato com as mudanças em plataformas que ocorreram devido ao ambiente multi-core e de nuvem que impera no mundo.
InfoQ.com: A estrutura do manifesto mudou? Ele foi escrito de forma prescritiva ao invés de descritiva?
Thompson: Queríamos que o manifesto focasse exclusivamente no por quê precisamos de uma nova abordagem mainstream para arquitetura de sistemas e para as principais propriedades que estes sistemas devem oferecer.
Como parte da revisão, queríamos ser descritivos a respeito das propriedades e características de um sistema reativo. As propriedades chave são: ser responsivo, resiliente e elástico, o que fundamentalmente implica em um sistema orientado a mensagens. Não queremos que o manifesto seja prescritivo a respeito de como alcançar isso. Estas prescrições podem ser ilustradas no apêndice ou através de uma discussão mais ampla.
InfoQ.com: Orientação a Mensagens versus Orientação a Eventos tem implicações sutis e expande a definição do que pode ser considerado um sistema reativo. Qual foi a motivação para mudança no nome deste conceito?
Thompson: Sim, as implicações são sutis, mas também, muito importantes. A importância está em como os componentes se comunicam. Eventos são um conceito de domínio importante. Eles podem ser passados diretamente por chamadas de função ou podem ser codificados e passados através de uma mensagem. Eventos são apenas um dos muitos conceitos que podemos escolher para implementar comunicação através de mensagens. Para alcançar as outras propriedades, gostaríamos de enfatizar que é importante ter uma fronteira assíncrona binária. Uma fronteira que ofereça desacoplamento da linguagem, localização, modelo de concorrência e entrelaçamento temporal. Isso também é um nível fundamental de isolamento.
Dada esta fronteira como meio de isolamento é possível conter uma falha. Exceções não devem cruzar uma fronteira assíncrona binária. Erros devem ser passados como mensagens entre componentes e tratados como conceitos de primeira classe. Se não obtivermos uma resposta de um componente, devemos suspeitar que ele falhou.
A memória não deve ser compartilhada entre componentes de forma que haja mudanças de estado. Estados mutáveis compartilhados são uma das principais formas de contenção que dificultam a escalabilidade no mundo multi-core. Precisamos evoluir para abordagens que utilizem a comunicação para compartilhar memória - o velho mantra CSP. Através do isolamento de componentes podemos evitar contenções, amortizar operações de alto custo com processamento em lote e adotar uma abordagem sem compartilhamento que escala no universo multi-core e de nuvem.
No esforço para atingir tempo de processamento de 100% é necessário suportar hot upgrades (atualizações sem que seja necessário parar o sistema). Um componente essencial do hot upgrade é a comunicação utilizando mensagens codificadas e versionadas entre componentes redundantes.
InfoQ.com: Similarmente, os conceitos elástico e escalável não são sinônimos e as diferenças entre os dois podem resultar em muitas formas diferentes de como implementar este conceito. Como um serviço pode apresentar Elasticidade de uma maneira que o termo Escalável não pode descrever?
Thompson: A maioria das pessoas considera que escalável significa aumentar escala. Pode ser tão importante aumentar quanto diminuir de forma que um negócio possa economizar. Tenho clientes do varejo e de aluguel de espaços para férias e feriados que apresentam variações de 3 ordens de magnitude na necessidade de recursos entre períodos tranquilos e períodos de pico. Dimensionar recursos com base no uso de pico seria desperdício ao ponto de tornar o negócio economicamente inviável.
Quando se projeta um sistema com suporte a aumento e diminuição de escala, o aumento de escala acaba funcionando melhor. Isso acontece porque se aprende que a simplicidade é muito importante. Diminuir escala é um exercício de assegurar que um sistema pode suportar falhas quando componentes são removidos, assim, o sistema remanescente deve compartilhar carga. Remover um componente devido a uma falha ou reduzir escala é efetivamente a mesma coisa.
No mundo em que se poder facilmente provisionar recursos da nuvem para aumentar ou diminuir escala, elástico parece ser uma descrição melhor.
InfoQ.com: Por que os nomes dos outros dois conceitos não mudaram?
Thompson: Responsivo e Resiliente parecem ser termos que soam bem e são propriedades desejáveis. Resiliência foi bem mencionada anteriormente. Na semana passada eu vi uma demonstração da linguagem de programação Extempore controlando uma parede 3D com interação através do toque humano. A visualização era impressionante e a resposta ao toque em tempo real. Se sistemas assim podem ser construídos por que a maioria dos websites levam segundos para responder a mudanças simples em páginas? As desculpas de desenvolvedores para não se importarem com desempenho estão começando a deixar de fazer sentido. Podemos e deveríamos fazer melhor para nossos clientes. Meu trabalho está dividido entre organizações que quebram fronteiras de desempenho e aquelas que, ao se tornarem mais eficientes, conseguem cortar custos operacionais. Vejo uma tendência no sentido da eficiência operacional, especialmente com advento da Internet das Coisas.
InfoQ.com: Algum dos conceitos é mais importante que os outros?
Thompson: As propriedades reativas podem ser consideradas como requisitos de qualidade de serviço. Cada sistema tem requisitos específicos. Esses requisitos devem ser capturados e implementados no projeto como qualquer outro. A principal diferença destes requisitos é que eles são muito mais difíceis de se implementar quando o projeto já está em andamento.
InfoQ.com: Existe uma ordem a ser seguida ao implementar serviços reativos?
Thompson: Nos trabalhos que desenvolvo para meus clientes existem duas abordagens: o desenvolvimento de um novo sistema ou migrações que acontecem aos poucos. O redesenvolvimento de um sistema inteiro é muito mais fácil do que se pensa quando se tem uma boa equipe. De qualquer forma, nem todo mundo tem tempo ou vontade para isso.
Uma boa abordagem é identificar fronteiras de contextos em sistemas e, então, os isolar com fronteiras binárias assíncronas. Esta técnica permite que estes componentes evoluam. Estes componentes podem precisar de uma camada para permitir a integração com o restante do sistema existente sem que sejam corrompidos. Uma vez que se dê os primeiros passos, eventualmente isso se torna fractal até que o tamanho ideal de componentes é atingido.
Ao ler sobre sistemas reativos muitas pessoas acham que estes implicam na necessidade de um sistema de fila de mensagens. Esse não é o caso. Qualquer mecanismo de comunicação que proporcione uma fronteira assíncrona binária é suficiente. Pode ser um produto de mensagens, mas também podem ser websockets ou um protocolo assíncrono construído sobre REST.
Muito pode ser feito para que possamos contruir esse tipo de sistema, e muitas pessoas fazem isso em finanças, por exemplo, ou se pode utilizar plataformas como Erlang, Akka, Go lang, dentre vários outros produtos para processamento de eventos. Sistemas reativos não são novos, sistemas como o Tandem já apresentavam estas propriedades décadas atrás. Eu acho que essa é uma área de muito crescimento no futuro uma vez que se perceba que abordagens como JEE e Rails são inadequadas para qualidade de serviço necessária hoje.
InfoQ.com: Este modelo pode ser estendido para sistemas que não são serviços? Ou a intenção é ter um sistema de serviços reativos?
Thompson: O modelo trata da construção de sistemas compostos de componentes ou serviços que são fundamentalmente orientados a mensagens e oferecem alta qualidade de serviço ao serem responsivos, resilientes e elásticos.
A medida que migramos para um estilo de arquitetura baseada em microserviços, essas propriedades se tornam cruciais. Se temos contenção em recursos compartilhados as coisas se tornam acopladas e frágeis. Num primeiro momento, progredimos com facilidade, mas então vem o horror de descobrir as limitações de escalabilidade e como a fragilidade impede o desempenho e a flexibilidade de desenvolvimento. Mas aí, já é tarde demais. Precisamos de propriedades reativas para então aplicar protocolos para interação de mensagens. Sem considerar os protocolos de interação, um ambiente de microserviços se torna um pesadelo para se coordenar.
A maioria destas coisas não são novas. Muitos domínios tem descoberto e redescoberto estes padrões a muito tempo. Telecom, Transações Financeiras, Apostas, Jogos Online e Redes Sociais de larga escala, todos estão convergindo para padrões de projeto similares que funcionam para estes requisitos.
Nossa indústria tem hipsters demais e poucos geeks. Precisamos olhar para trás e construir sobre os bons fundamentos estabelecidos pelos pioneiros de sistemas distribuídos e concorrência. Com esse fim, estamos organizando uma conferência que foca em bons trabalhos nessa área. Neste ano, promovemos o React Conf em Londres em que, dentre outros, Joe Armstrong compartilhou sua experiência de desenvolvimento com Erlang. Vamos continuar em São Francisco em novembro com Leslie Lamport, Pat Helland e outros grandes palestrantes. Estes são "os gigantes" da nossa indústria e precisamos construir sobre a experiência deles. Como estaria a física se ignorássemos Newton e Einstein? Ou a Química sem Curie ou Mendeleyev?
InfoQ.com: Como os Hipsters podem fazer para aprenderem como ser Geeks?
Thompson: Essa é uma ótima pergunta que me fazem frequentemente. O Manifesto Reativo, no seu cerne, trata de trazer atenção para o ótimo trabalho que nossa indústria já realizou nessa área. Precisamos dele agora mais do que nunca. Alguns ainda trabalham em conferências React como uma forma disseminar o assunto. Outros como Roland Kuhn e Jamie Allen estão escrevendo um livro que tratam alguns aspectos relativos a isso. É válido estudar abordagens como Erlang e Tandem; ou abordagens mais novas como Akka, Go lang, Rust e Elixir. Fundamentalmente, na base de todas estas abordagens estão o estilo de troca de mensagens que proporciona uma fronteira binária necessária para o isolamento que permite responsividade, resiliência e propriedades elásticas. Existem muitos artigos bons com orientações sobre este assunto. Infelizmente alguns deles são de difícil leitura. Precisamos torná-los mais acessíveis.
InfoQ.com: Obrigado, Martin.
Thompson: Obrigado pelas perguntas, Harry.
No blog do Thompson, Mechanical Sympathy, discute-se desempenho de software e conceitos de design para sistemas reativos dentre outros assuntos relacionados.