Unindo mundos – Arquitetura orientada a serviços em Ruby e

JavaMaurício Linhares

WHO?

Software Developer da OfficeDrop.com

@mauriciojr

https://github.com/mauricio

SOA não é ruim, as implementações da idéia que são um

desastre

SOA é construir aplicações

independentes, que fazem uma coisa bem e delegam o que não

sabem pra outrosLembra de alguma coisa?

Write programs that do one thing and do

it well. Write programs to work together. Write

programs to handle text streams because

it is an universal interface.

Doug Mcllroy – The UNIX philosophy

Blame the messenger, not the

message

Aplicação Rails antiga (2.x), grande, com

uma equipe crescente

trabalhando nela

Rodar todos os testes dava uma preguiça…

Usávamos o banco de dados como fila

Longos períodos de QA

Tudo acontece num só lugar, numa

aplicação única, onde todos trabalham o dia

inteiroPor Que?

Como resolver isso?

Ah, o divórcio!

As duas zonas

Gestão de Documentos

Processamento de Documentos

Gerenciar documentos fica na

webapp, processamento de documentos migra

para uma nova aplicação

Se é uma nova aplicação, podemos escolher uma outra tecnologia? Como integrar as duas

apps?

resque como fila de trabalhos

nosso fork do jesque em - https://github.com/mauricio/jesque

API REST com JSON para comunicação

S3 para armazenamento de

resultados

Cliente envia arquivo para app servers

Mensagem de processamento é enviada para a fila

Worker aceita o trabalho

Worker sinaliza que o arquivo foi processado

Funcionou?

As duas aplicações passaram a evoluir

em separado

O backend tinha ciclos de deployment mais curtos, que não afetavam a aplicação

webLembre-se, fila do resque e interface REST

Menos código na aplicação web

significava menos testes sendo rodados

Quem estava lá não se preocupava mais com backend

Não haviam mais dependências diretas

na hora de um release, se os

contratos fossem honrados, as aplicações

funcionavam

Mensagens auto-contidas – o backend

recebe tudo o que precisa na mensagem

WHERE DID WE

Ter aplicações separadas trouxe

problemas de comunicação entre

equipesVocê não pode esquecer que estão todos no mesmo barco

Nem todo mundo rodava o ambiente

completo e a documentação nem

sempre era atualAs aplicações ainda devem ser usadas em conjunto

A implementação do Jesque é enrolada e não podemos usar plugins facilmente

API pública e API privada não devem

ser misturadas

Ter várias aplicações com vários

ambientes diferentes complica

deployments e montagem de

equipes

O que aprendemos?

Construa aplicações pequenas e focadas em algum trabalho

Só compartilhe dados pela API, não use

bancos de dados pra isso.

Defina o que cada aplicação deve fazer

claramente

Crie uma interface mínima somente com

o que está sendo utilizado agora

Não misture a representação de saída com os seus

modelos!Procure soluções como o Roar -

https://github.com/apotonick/roar

Separe fontes/bancos de dados.

A escalabilidade agradece.

Planeje e construa para falhas

Construa para falhar

Rails Engines? Será?

Onde nós estamos hoje?

Front-end HTML migrando pra outra

aplicação

Cluster com auto-scaling e

independente de ambiente para o

backend a caminho

ELES DISSERAM QUE SOA ERA RUIM

NÃO DIZEM MAIS

FIMObrigado a todos