Microservices - Quebrando gigantes em pequenos

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