Palestra introdutória sobre microservices

1. microservices
introdução a quebra de gigantes em pequenos

2. Vinícius Krolow
FULL STACK DEVELOPER
@krolow
krolow.com.br

3. “mas, o que são
microservices?”

4. serviços pequenos!

5. http://martinfowler.com/articles/microservices.html
componente “é aquela unidade de software que pode ser
aprimorada e substituída de forma independente”
serviço “seria na realidade um tipo especial de
componente, o componente descrito acima chamaríamos
de biblioteca. Seria o código que ligamos aquele que
escrevemos. O serviço é oposto, não ligamos o código a
este, apenas executamos fazendo chamadas remotas para
este”
Martin Fowler
o que são serviços /
componentes?

6. hipsters fazendo sistemas
distribuídos

7. ps ax | grep node | awk '{print $1}'
pipeline para unix

8. mas o que é então?
não existe uma definição “concreta”
ainda…
Arquitetura de software que busca
desacoplar/quebrar aplicações em
serviços “pequenos” que atendam
um requisito funcional da aplicação e
que funcionem de forma
independente.

9. “como fazemos aplicações web
normalmente?”

10. browser hey http server get “/”?
for sure, let me see here…
…..
alright here is the response
UI
Store Service
Inventory Service
Shipping Service
Aplicação monolítica

11. @browser: hey @http_server get “/”?
Store service
Inventory Service
Shipping Service
Aplicação monolítica / single page
UI
@http_server, okay here are the
html/js and lets make theses ajax
calls to backend

12. “como é isso tudo
em prática?”

13. Aplicação monolítica
usuários
inventário
ordem de pedidos
pós vendas
diversos components em uma base de código

14. “quais são os obstáculos das
aplicações
monolíticas?”

15. programadores assustados
● base de código normalmente muito grande
● é difícil dominar a camada de negócio
● possível demora ao carregar projeto na IDE
● difícil manter o versionamento de código

16. dificuldades para deploys
frequentes
● um “;” faltando pode quebrar a app inteira
● para alterar um componente precisa fazer redeploy
da app inteira
● ciclos longos de QA
● medo de fazer mudanças

17. dificuldades para criar novas
funcionalidades
● vai performar?
● diversos times trabalhando no mesmo code base
● insegurança nas alterações

18. longa vida com seu stack
escolhido
● escolha de framework/linguagem é vida longa
● migração de código para outras linguagens
normalmente são custosas
● não é possível tirar melhor proveito das ferramentas

19. “e onde entram
os microservices?”

20. para tentar arrumar a casa…

21. para tentar arrumar a casa…
escolher stacksreaproveitar
serviços
dividir responsabilidades
facilitar a escalabilidade falhar pequeno
...
fácil de atualizar

22. http://www.slideshare.net/alvarosanchezmariscal/stateless-authentication-for-microservices

23. Menores e simples
Ao contrário das aplicações monolíticas, os microservices vão focar
em pequenos contextos/soluções o que leva:
● Ser mais fácil de entender
● Menor code base
● Rápido de rodar e fazer deploy
● Reduzir/Dividir developers por
serviços
● Maior controle domínio do
contexto

24. liberdade
escolha o stack que melhor resolva seu problema, mude, jogue fora,
refaça...

25. “como quebrar suas aplicações
em microservices?”

26. Utilizando alguns conceitos
estratégicos

27. Conceitos:
Domínio: Venda de produtos onlines (e-commerce)
Sub-domínios: Venda, Estoque, Controle financeiro, Pós
venda, Histórico de compras, Pagamento, Logística,
etc…
Contextos Delimitadores: “Usuários” podem ter contexto
diferentes no sub-dominío de venda, e no subdomínio
de pós vendas.

28. Bounded Context
http://martinfowler.com/bliki/BoundedContext.html

29. mapear os contextos e suas comunicações,
possibilita
a quebra em serviços
distintos!

30. “bacana mas
como eles se falam?”

31. depende...
Pode ser comunicação síncrona ou assíncrona
HTTP/REST JSON ou Protobuf
Messages Queue (ZeroMQ, RabbitMQ, etc..)
Assim como pode variar o protocolo TCP/UDP...

32. “e onde rodam os
microservices?”

33. usam e abusam da
cloud
● virtual machines
● containers (dockers)
● servidores físicos
● instâncias separadas
● instâncias juntas

34. “quem anda usando
microservices?”

36. http://pt.slideshare.net/adriancockcroft/goto-berlin

37. mas nem tudo são
flores...

38. complexidade de sistemas
distribuídos
1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. There is one administrator.
7. Transport cost is zero.
8. The network is homogeneous.
http://www.rgoarchitects.com/Files/fallacies.pdf
“8 falácias de sistemas distruídos”

39. controlar inconsistências, sem
“transaction”
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

40. testar sistemas distribuídos é
complexo!
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

41. deploy de vários serviços…
automação.
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

42. versionamento, fallback,
coordenadação para evitar quebras
de interface de contrato!
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

43. serviços poliglotas, significa
desenvolvedores poliglotas...
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

44. duplicação de esforços...
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

45. monitoramento da aplicações

46. log de aplicações

47. tolerâncias a falhas

48. “bom então qualé?”

49. é algo que está em
alta
Pode vir a se tornar uma tendência para
os projetos maiores web, por ser uma
tendência/hype, padrões de projetos,
padrões de arquitetura e ferramentas
estão sendo criados para atender essa
demanda.
http://microservices.io/

50. Não é pau de toda
obra…
Mas pode ser uma solução eficaz para
alguns tipos de projetos onde reutilização
de serviços se da necessário e ou
escalabilidade e divisão de esforços são
necessários...

51. eras isso qualquer coisa
krolow.com.br =)