Upload
mauricio-linhares
View
755
Download
0
Embed Size (px)
DESCRIPTION
Apresentação feita na RubyConf Brazil 2012.
Citation preview
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