O documento discute a arquitetura orientada a serviços em Ruby e Java, descrevendo como o autor dividiu uma grande aplicação Rails monolítica em duas aplicações separadas para gestão de documentos e processamento de documentos, comunicando-se via fila de mensagens e API REST. Isso trouxe benefícios como ciclos de deploy mais curtos e menos testes, porém também desafios de comunicação entre equipes. O autor conclui recomendando aplicações pequenas e focadas, compartilhando dados apenas via API.

1. Unindo mundos –
Arquitetura orientada a
serviços em Ruby e
Java
Maurício Linhares

2. WHO?
Software Developer da OfficeDrop.com
@mauriciojr
https://github.com/mauricio

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

5. SOA é construir
aplicações
independentes, que
fazem uma coisa bem e
delegam o que não
sabem pra outros
Lembra de alguma coisa?

6. 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

7. Blame the
messenger, not the
message

9. Aplicação Rails antiga
(2.x), grande, com uma
equipe crescente
trabalhando nela

10. Rodar todos os testes dava
uma preguiça…

11. Usávamos o banco de dados como fila

12. Longos períodos de QA

13. Tudo acontece num só
lugar, numa aplicação
única, onde todos
trabalham o dia inteiro
Por Que?

14. Como resolver isso?

15. Ah, o divórcio!

16. As duas zonas
Gestão de Documentos
Processamento de
Documentos

17. Gerenciar documentos
fica na
webapp, processamento
de documentos migra
para uma nova
aplicação

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

19. resque como fila de
trabalhos
nosso fork do jesque em - https://github.com/mauricio/jesque

20. API REST com JSON
para comunicação

21. S3 para armazenamento
de resultados

22. Cliente envia arquivo para app servers
Worker
sinaliza que o
arquivo foi
processado
Worker aceita o trabalho

23. Funcionou?

24. As duas aplicações
passaram a evoluir em
separado

25. O backend tinha ciclos
de deployment mais
curtos, que não
afetavam a aplicação
web
Lembre-se, fila do resque e interface REST

26. Menos código na
aplicação web
significava menos testes
sendo rodados
Quem estava lá não se preocupava mais com backend

27. Não haviam mais
dependências diretas na
hora de um release, se
os contratos fossem
honrados, as aplicações
funcionavam

28. Mensagens auto-
contidas – o backend
recebe tudo o que
precisa na mensagem

29. WHERE DID WE

30. Ter aplicações
separadas trouxe
problemas de
comunicação entre
equipes
Você não pode esquecer que estão todos no mesmo barco

31. Nem todo mundo rodava
o ambiente completo e a
documentação nem
sempre era atual
As aplicações ainda devem ser usadas em conjunto

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

33. API pública e API
privada não devem ser
misturadas

34. Ter várias aplicações
com vários ambientes
diferentes complica
deployments e
montagem de equipes

35. O que aprendemos?

36. Construa aplicações
pequenas e focadas em
algum trabalho

37. Só compartilhe dados
pela API, não use
bancos de dados pra
isso.

38. Defina o que cada
aplicação deve fazer
claramente

39. Crie uma interface
mínima somente com o
que está sendo utilizado
agora

40. Não misture a
representação de saída
com os seus modelos!
Procure soluções como o Roar - https://github.com/apotonick/roar

41. Separe fontes/bancos
de dados.
A escalabilidade
agradece.

42. Planeje e construa para
falhas

43. Construa para falhar

44. Rails Engines? Será?

45. Onde nós estamos
hoje?

46. Front-end HTML
migrando pra outra
aplicação

47. Cluster com auto-scaling
e independente de
ambiente para o
backend a caminho

48. ELES DISSERAM QUE SOA ERA RUIM
NÃO DIZEM MAIS

49. FIM
Obrigado a todos 