COMPOSIÇÃO E INTEGRAÇÃO DE SISTEMAS EM 2013

Leandro Silva

TDC 2013

http://leandrosilva.com.br

@codezonehttp://github.com/leandrosilva

QUEM SOU EU?

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)

NÃO SOU UM .NET EXPERT

CONSEGUE LIDAR COM ISSO?

PROSIGAMOS...

.NET NÃO É MAIS O PATINHO FEIO

ASP.NET MVC

C#

Entity Framework

Web APIF#

Ninject

Unit Testing Framework

NUnit

SignalR

Reactive Extensions

LINQRazor

HDInsight a.k.a. Hadoop on Azure

async Redis

Log4Net

ActorFx The Actors Framework for Azure

“É POSSIVEL CONSTRUIR SISTEMAS BEM DECENTES COM .NET”– Black Widow

COMUNIDADE

hadooprest

json

javascript

redis

unit testing

mvc

orm

STANDARD

OPEN SOURCE

git

“NÃO QUEIRA

BANCAR O GÊNIO.

APENAS SIGA A DROGA DO

PADRÃO!”– Nick Fury

COMO INTEGRAR SISTEMAS HOJE?

“SIMPLES. USE HTTP & JSON. E CRIE ALGUNS

MICRO-SERVIÇOS.”– Tony Stark

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

– Tony Stark

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

– Black Widow

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

“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 reescritaescritos 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

PRINCÍPIOS FUNDAMENTAIS PARA INTEGRAÇÃO DE

SISTEMAS

PRINCÍPIOS FUNDAMENTAIS PARA INTEGRAÇÃO DE

SISTEMAS

O QUE VOCÊ PECISA SABER

CRIAREM PLENO 2013

* Nada do que vou dizer

é tão novo assim. Sorry!

INTEGRARE

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

COMPOSIÇÃO

WEB

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MOBILE WORKERApplication 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?!)

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 Waybitch!

(Em alguns casos, você pode granularizar

por domínio. Mas se o domínio for amplo,

granularize ainda um pouco mais.)

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

SIMPLICIDADE

APPMICRO SERVICE

GET /top/secret/data/123X-Auth-User: codezoneX-Auth-Ticket: k3ki7s1mpl3stuff898sdATy7why3noT83ab

POST /ticketX-Auth-User: codezoneX-Auth-Request-Timestamp: 2013081506X-Auth-Token: h3J87Ui2i90oLkLL8j4khUUij282h3

HTTP/1.1 200 OKX-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!

ASSINCRONICIDADE

APPMICRO 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.)

LOGGING

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

MICRO SERVICE

EVENT VIEWER 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.)

ACESSIBILIDADEPOST 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.)

RESUMINDO

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)

DÚVIDAS?

MUITO OBRIGADO!Leandro Silva

TDC 2013

http://leandrosilva.com.br

@codezonehttp://github.com/leandrosilva