Upload
vinicius-krolow
View
247
Download
3
Embed Size (px)
Citation preview
microservicesintrodução a quebra de gigantes em pequenos
Vinícius Krolow
FULL STACK DEVELOPER
@krolow
krolow.com.br
“mas, o que são
microservices?”
serviços pequenos!
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?
hipsters fazendo sistemas
distribuídos
ps ax | grep node | awk '{print $1}'
pipeline para unix
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.
“como fazemos aplicações web
normalmente?”
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
@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
“como é isso tudo
em prática?”
Aplicação monolítica
usuários
inventário
ordem de pedidos
pós vendas
diversos components em uma base de código
“quais são os obstáculos das
aplicações
monolíticas?”
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
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
dificuldades para criar novas
funcionalidades
● vai performar?● diversos times trabalhando no mesmo code base● insegurança nas alterações
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
“e onde entram
os microservices?”
para tentar arrumar a casa…
para tentar arrumar a casa…
escolher stacksreaproveitar
serviços
dividir responsabilidades
facilitar a escalabilidade falhar pequeno
...
fácil de atualizar
http://www.slideshare.net/alvarosanchezmariscal/stateless-authentication-for-microservices
Menores e simplesAo 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
liberdadeescolha o stack que melhor resolva seu problema, mude, jogue fora,
refaça...
“como quebrar suas aplicações
em microservices?”
Utilizando alguns conceitos
estratégicos
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.
Bounded Context
http://martinfowler.com/bliki/BoundedContext.html
mapear os contextos e suas comunicações,
possibilita
a quebra em serviços
distintos!
“bacana mas
como eles se falam?”
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...
“e onde rodam os
microservices?”
usam e abusam da
cloud
● virtual machines
● containers (dockers)
● servidores físicos
● instâncias separadas
● instâncias juntas
“quem anda usando
microservices?”
http://pt.slideshare.net/adriancockcroft/goto-berlin
mas nem tudo são
flores...
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”
controlar inconsistências, sem
“transaction”
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
testar sistemas distribuídos é
complexo!
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
deploy de vários serviços…
automação.
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
versionamento, fallback,
coordenadação para evitar quebras
de interface de contrato!
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
serviços poliglotas, significa
desenvolvedores poliglotas...
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
duplicação de esforços...
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
monitoramento da aplicações
log de aplicações
tolerâncias a falhas
“bom então qualé?”
é 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/
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...
eras isso qualquer coisa
krolow.com.br =)