O documento apresenta princípios fundamentais para integração de sistemas em 2013, como usar micro-serviços, HTTP e JSON para comunicação, e padrões abertos. Recomenda decompor sistemas em micro-serviços especializados e fracamente acoplados, compondo-os para aplicações. Também destaca logging, assincronicidade, testes, documentação e simplicidade.

1. COMPOSIÇÃO E INTEGRAÇÃO
DE SISTEMAS EM 2013
Leandro Silva
TDC 2013
http://leandrosilva.com.br
@codezone
http://github.com/leandrosilva

2. QUEM SOU EU?

3. LEANDRO SILVA @codezone
•+15 na indústria (escrevendo software de produção)
•Fissurado em programação (Ruby, Java, Erlang, Clojure, C#, F#)
•Blogueiro preguiçoso (http://leandrosilva.com.br)
•Já fui gerente de sistemas, arquiteto de sistemas, líder técnico,
programador e instrutor de programação e arquitetura
•Tenho código no GitHub (https://github.com/leandrosilva)
•E perfil no LinkedIn (http://linkedin.com/in/lesilva)

4. NÃO SOU
UM .NET EXPERT

5. CONSEGUE LIDAR
COM ISSO?

7. PROSIGAMOS...

8. .NET NÃO É MAIS
O PATINHO FEIO

10. ASP.NET MVC
C#
Entity Framework
Web API
F#
Ninject
Unit Testing Framework
NUnit
SignalR
Reactive Extensions
LINQ
Razor
HDInsight
a.k.a. Hadoop on Azure
async Redis
Log4Net
ActorFx
The Actors Framework for Azure

11. “É POSSIVEL
CONSTRUIR
SISTEMAS
BEM
DECENTES
COM .NET”
– BlackWidow

12. COMUNIDADE
hadoop
rest
json
javascript
redis
unit testing
mvc
orm
STANDARD
OPEN SOURCE
git

13. “NÃO
QUEIRA
BANCAR O
GÊNIO.
APENAS SIGA
A DROGA DO
PADRÃO!”
– Nick Fury

14. COMO INTEGRAR
SISTEMAS HOJE?

15. “SIMPLES. USE HTTP &
JSON. E CRIE ALGUNS
MICRO-SERVIÇOS.”
–Tony Stark

16. “ESQUEÇA OS PROTOCOLOS
PROPRIETÁRIOS. USE PADRÕES
ABERTOS E CONHECIDOS DE TODOS.”
–Tony Stark

17. “ATUALMENTE, SÓ
CONSTRUO MEUS
MICRO-SERVIÇOS
USANDO ASP.NET MVC
WEB API. É SIMPLES E
MUITO SEXY.”
– BlackWidow

18. AFINAL, O QUE SÃO
MICRO-SERVIÇOS?

19. “NÃO HÁ UMA DEFINIÇÃO
EXATA DO QUE É UM
MICRO-SERVIÇO, MAS UMA
SÉRIE DE PRINCÍPIOS QUE
PODEM SER OBSERVADOS.”
fracamente acoplados
algumas poucas linhas de código
favorecem a reescrita
escritos em frameworks leves
deployados independentemente
web apis com poucas rotas
domínio específico
interface opaca
favorecem a composição
repositórios de código independentes
uma responsabilidade

20. PRINCÍPIOS FUNDAMENTAIS
PARA INTEGRAÇÃO DE
SISTEMAS

21. PRINCÍPIOS FUNDAMENTAIS
PARA INTEGRAÇÃO DE
SISTEMAS
O QUE VOCÊ PECISA SABER
CRIAR
EM PLENO 2013
* Nada do que vou dizer
é tão novo assim. Sorry!
INTEGRAR
E

22. DECOMPOSIÇÃO
THE ALMIGHTY WEB SERVICE
BADASS
MICRO
SERVICE
BADASS
MICRO
SERVICE
BADASS
MICRO
SERVICE
BADASS
MICRO
SERVICE
BADASS
MICRO
SERVICE
BADASS
MICRO
SERVICE
“Todas as vezes que você tem um componente que faz 1000 coisas, com dezenas de
dependentes, você sofre com a manutenção, com a escala do time de desenvolvimento
e com a disponibilidade do serviço, só para citar alguns problemas.”
(Cuidado! Compartilhar classes de
domínio é legal, mas tende a
migrar o gesso para outro lugar. Um
pouco de duplicação de código
“nem sempre” é um problema.)

23. COMPOSIÇÃO
WEB
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MOBILE WORKER
Application Domain Logic Application Domain Logic Application Domain Logic
“Micro-serviços são como pacotes de procedimentos e funções, que
as aplicações usam para compor suas próprias regras de negócio
especializadas. Mas o ideal é que não sejam muito abrangentes.”
(Regras de negócio que são
fundamentais à empresa,
devem estar contidas em
micro-serviços. As demais, nas
apps; ainda que haja uma ou
outra duplicação de código.)
(DICA: Windows Task Scheduler + cURL,
por exemplo, já dá conta aqui. Não
precisa nem reinventar a roda.)
(É “micro”, lembra?!)

24. ESPECIALIZAÇÃO
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
“Cada micro-serviço deve
ter uma única
responsabilidade, com um
contrato muito bem
definido, e deve fazer muito
bem o seu trabalho.”
The Unix Way
bitch!
(Em alguns casos, você pode granularizar
por domínio. Mas se o domínio for amplo,
granularize ainda um pouco mais.)

25. ISOLAMENTO
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
“A falha em um micro-
serviço não deve afetar os
demais. Nem devem as apps
consumidoras serem
drasticamente afetadas.”
puff!
crash!
Yeah, let it crash
(A regra aqui é um Web
API Project por micro-
serviço. Quero dizer, um
deploy por micro-serviço.)
(Na hora de escalar, isso também vai te ajudar a
botar recurso onde realmente precisa de recurso.)

26. SIMPLICIDADE
APP
MICRO
SERVICE
GET /top/secret/data/123
X-Auth-User: codezone
X-Auth-Ticket: k3ki7s1mpl3stuff898sdATy7why3noT83ab
POST /ticket
X-Auth-User: codezone
X-Auth-Request-Timestamp: 2013081506
X-Auth-Token: h3J87Ui2i90oLkLL8j4khUUij282h3
HTTP/1.1 200 OK
X-Auth-Ticket: k3ki7s1mpl3stuff898sdATy7why3noT83ab
AUTH
DLL
(Token = Hash(User + SecretKey + Timestamp))
(Lembre-se: Ticket precisa
ter um tempo de validade)
(Agora é só validar se existe esse ticket associado
a esse usuário e se ele ainda está válido)
Não precisa
implementar IGUALZINHO. Isso é só
uma idéia!

27. ASSINCRONICIDADE
APP
MICRO
SERVICE
GET /some/big/task/i7s898sdATy
POST /some/big/task
{ “A”: “123”, “B”: “456” }
HTTP/1.1 200 OK
{ “SomeBigTaskID”: “i7s898sdATy” }
QUEUE
WORKER
DATABASE
(Se a coisa pode demorar, fuja do síncrono!)
(Uma outra abordagem aqui seria usar
Web Hook. Ou seja, receber um post
dizendo que o processo terminou.)

28. LOGGING
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
MICRO
SERVICE
EVENTVIEWER GRAYLOG
LOG4NET
(EventLog) (Gelf4Net)
(Log tudo, absolutamente, tudo.
Só tome cuidado com dados
sensíveis. Não se empolgue!)
(É interessante ter um identificador
para a transação que está sendo
logada, de modo que ela possa ser
rastreada de ponta a ponta.)
(Ah! E logar as mensagens em
JSON também pode ser uma
boa, viu?! Ajuda a parsear e
extrair informações úteis.)

29. ACESSIBILIDADE
POST http://codezo.ne/api/deliveries/new
GET http://codezo.ne/api/deliveries/123
POST http://codezo.ne/api/deliveries/123/done
DELETE http://codezo.ne/api/deliveries/123
POST http://codezo.ne/api/deliveries/tasks/sync
POST http://codezo.ne/api/deliveries/123/refused
GET http://codezo.ne/api/deliveries/doc
“Se você não quiser que seu micro-serviço seja odiado logo de cara, você
tem que prover uma boa URL e documentação facilmente acessível.”
(DICA: Cuidado para
não inchar a coisa.
É sempre bom
pensar na menor
unidade de
responsabilidade
que seu micro-
serviço pode ter. Às
vezes, por exemplo,
vale a pena botar as
tasks em outro
micro-serviço. Não
se deixe levar
apenas pela URI,
porque ela é só uma
interface com o
usuário.)

30. RESUMINDO

31. Esqueças as soluções proprietárias e os protocolos pesados
Use ASP.NET MVC Web API – é fácil, testável e tem tudo que você precisa
Crie um projeto e um repositório por micro-serviço
Mantenha seus micro-serviços bem pequenininhos – umas 100 LoC
Se você não consegue ter um micro-serviço inteiro na sua cabeça, quebre-o!
“Deploye” cada micro-serviço separadamente – hamm, app pools?
Ofereça URIs amigáveis e auto-explicativas
Tenha interfaces bem definidas e opacas para quem as vê
Sempre que possível, use um fluxo assíncrono
Autenticação/autorização simples – HTTP Header, user, token, ticket, expiration
Filters e Attributes são seus amigos na hora de autenticar/autorizar, aproveite!
Faça log tudo. Depois, faça log do que faltou
Agregue seus logs em algum lugar – EventViewer e mais algum outro agregador
Windows Task Scheduler + cURL + POST /tasks/do/something é legal
Construa uma fachada para seu ERP, você vai ser muito mais feliz – vai por mim
(In Memory Server para teste de integração)
(isso vai ter ajudar a escalar o desenvolvimento)
(não precisa ser tão purista em relação a REST)
(tem que ser uma coisa binária, entra X, saí Y)
(assim fica fácil de propagar)
(só cuidado para não deixar a coisa inchada, use o princípio dos micro-serviços)

32. DÚVIDAS?

33. MUITO OBRIGADO!
Leandro Silva
TDC 2013
http://leandrosilva.com.br
@codezone
http://github.com/leandrosilva