Microservices

Quebrando gigantes em pequenos

Transcript

1. microservices introdução a quebra de gigantes em pequenos
2. Vinícius Krolow @krolow krolow.com.br
3. “mas, o que são microservices?”
4. serviços pequenos!
5. o que são serviços / componentes?
6. hipsters fazendo sistemas distribuídos
7. 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 • • • •
16. dificuldades para deploys frequentes • • • •
17. dificuldades para criar novas funcionalidades • • •
18. longa vida com seu stack escolhido • • •
19. “e onde entram os microservices?”
20. …
21. … escolher stacks reaproveitar serviços dividir responsabilidades facilitar a escalabilidade falhar pequeno ... fácil de atualizar
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
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?”
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.
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 =)