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.
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)
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
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
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?!)
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!
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.)
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)