Diego de Oliveira e Marden NeubertAbril de 2017

Marden Neubert Formador de times Obcecado por soluções Agilista Aprendiz

Diego de Oliveira .Apaixonado por desafios .

Devorador de livros .Nerd .

Pai .

[ Colocar uma foto do hackaton ]

microserviços aparecem em sistemas

ResponsivoBaixa latência, fail fast, ...

ResilienteNão propaga falhas em cascata, boa disponibilidade

ElásticoPossível adicionar ou remover instâncias

IsoladoCiclo de vida, dados, deployment, monitoração, etc.

Responsabilidade únicaAtua em um contexto de domínio bem definido

Estado exclusivoNão compartilha banco de dados, filesystem, ...

MobilidadeCapacidade de ser migrado com pouco esforço

Paradigma maduro Tão antigo quanto programação orientada a objetos

Comunicação assíncronaIncorporada de forma inerente ao modelo

Atores criam outros atoresIsso viabiliza elasticidade e leva a uma topologia dinâmica

Programação ou arquiteturaAplicável como paradigma de programação ou como estilo de arquitetura

Sistema com programação Reativa

Focado dentro do serviço

● IO não blocante● Event looping● Bibliotecas como RxJava, Akka● Linguagens e frameworks como

Golang, Elixir, NodeJs, Vertx,

o seu sistema pode ser multithread, não blocante, reativo, concorrente, paralelo...

Microserviços reativos

Focado na integração entre os microserviços

● Padrões de integração● Event Sourcing● CQRS

no fim das palestras, blogs e livros sempre ficava um “depende”

não achamos nenhum mapa, tem que atuar na cultura

Imprevisibilidade

Não há rota pronta

Novos processos e técnicas devem ser internalizadas

Não faça nadaA princípio não se preocupe

com isso, fique atento ao . problema de negócio. .

O crescimento dele .irá definir a real .

necessidade .

. Entenda

. Observe os resultados,

. como o time está absorvendo

. as mudanças. Relacione com

. referências já conhecidas de

. mercado

Comece Quando seu sistema começar a ganhar tamanho, comece a testar novos modelos em partes menos críticas

Direcione .Crie mecanismos, práticas .

e facilidades para reduzir .africção de uso do .

novo modelo

12

3

4

Ações

Há pouca necessidade de comunicaçãoNo começo surgir um monolito é natural.

Deve-se observar o crescimento do time e das funcionalidades atento ao ponto crítico

Uma vez percebido problemas com delivery, velocidade do time, dificuldade de refatoração, etc, é preciso aprender a modularizar, aqui começam a aparecer macroserviçes

Faz parte do processo de aprendizagem para evitar vazamento de contextos entre os

módulos

Alguma comunicação ativa entre sistemas. A origem da informação notifica os interessados

Muita comunicação e necessidade de coordenação, mas ainda pode melhorar...

Várias peças móveis, necessidade de maturidade nos mecanismos de monitoração e operação

Não é preciso ficar na moda de. microserviços, eles devem ser. do tamanho certo

O processo evolutivo permite ao time aprender a achar a. delineação das fronteiras dos sistemas

Muita comunicação e coordenação entre os sistemas

log

MB

MA

BA

MC

D

MD

ME

E

A BMB

C

D

E(MA)

(MA)

(MA)

C

MAv1

MAv2

MAv3

… log ...

... log ...

... log ...

Qualquer sistema interessado pode ouvir o

log de eventos

Conteúdo

● As mensagens deve ser versionadas● Schema formalmente definido (json

schema, Protobuf, Avro)● Curadoria sobre o modelo das

mensagens● Portável entre plataformas e

linguagens

Armazenamento

● Garantias de Ordem● Distribuído● Extensível

GUI de Cadastro

Serviço de Usuários

Serviço de Vendas

GUI de Vendas

Serviço de conciliação

Serviço de classif. Vendedor

URA

● Alguns serviços atuam de forma ativa

● Alguns serviços atuam de forma reativa

● API First● Cada um com banco de

dados próprio● Visão própria dos dados

de sistema

≠

● Os times atuam em um ou poucos componentes● Times trabalham com mock de componentes não essenciais● Componentes essenciais executando para auxiliar o desenvolvimento● Uso de perfis de execução

● Especialização em sub-sistemas● Ecossistema heterogêneo:

Nodejs, Java + Springboot, Java + Vertx, Reactjs, Server side templating, Vuejs, Golang, Rabbit, Kafka, MySQL, Oracle, Memcached, Cassandra, etc

You must be this big to ride

Atende muito bem se você:

● tem um número grande de times● está em uma fase de super

crescimento● tem cultura ágil e devops● aplica arquitetura evolutiva● usa ferramental adequado

Desafio técnico e culturalÉ preciso atuar na formação e na capacitação dos times

Muda a forma de estimarMenor dependência entre times, porém com maior sincronização

Revisão de modelo existenteNão é hype, é uma nova leitura de um modelo maduro e consolidado

Modelo de crescimentoEscala para grandes projetos e times

Complexidade adicionalRequer maturidade e ferramental para ser efetivo

Maior resiliênciaPermite isolamento de pontos de falha, backpressure, etc.

Motiva os timesMenor lead time traz sensação de trabalho realizado

Buscando desafios?https://goo.gl/vGbSb2

Diego de Oliveira e Marden NeubertAbril de 2017