Diego de Oliveira e Marden Neubert Abril de 2017

Transcrição

1 Diego de Oliveira e Marden Neubert Abril de 2017

2 Marden Neubert Formador de times Obcecado por soluções Agilista Aprendiz Diego de Oliveira Apaixonado por desafios Devorador de livros Nerd Pai

3 [ Colocar uma foto do hackaton ]

4 microserviços aparecem em sistemas

5 Responsabilidade única Estado exclusivo Atua em um contexto de domínio bem definido Não compartilha banco de dados, filesystem, Isolado Ciclo de vida, dados, deployment, monitoração, etc Mobilidade Elástico Possível adicionar ou remover instâncias Capacidade de ser migrado com pouco esforço Responsivo Baixa latência, fail fast, Resiliente Não propaga falhas em cascata, boa disponibilidade

6 Paradigma maduro Comunicação assíncrona Tão antigo quanto programação orientada a objetos Incorporada de forma inerente ao modelo Atores criam outros atores Isso viabiliza elasticidade e leva a uma topologia dinâmica Programação ou arquitetura Aplicável como paradigma de programação ou como estilo de arquitetura

7 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

8 Microserviços reativos Focado na integração entre os microserviços Padrões de integração Event Sourcing CQRS

9 Não há rota pronta não achamos nenhum mapa, tem que atuar na cultura no fim das palestras, blogs e livros sempre ficava um depende Novos processos e técnicas devem ser internalizadas Imprevisibilidade

10 Não faça nada A princípio não se preocupe com isso, fique atento ao problema de negócio O crescimento dele irá definir a real necessidade Comece 1 2 Quando seu sistema começar a ganhar tamanho, comece a testar novos modelos em partes menos críticas Ações Direcione Crie mecanismos, práticas e facilidades para reduzir a fricção de uso do novo modelo 4 Entenda Observe os resultados, como o time está absorvendo as mudanças Relacione com referências já conhecidas de mercado 3

11 No começo surgir um monolito é natural Deve-se observar o crescimento do time e das funcionalidades atento ao ponto crítico Há pouca necessidade de comunicação

12 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

13 Várias peças móveis, necessidade de maturidade nos mecanismos de monitoração e operação Muita comunicação e necessidade de coordenação, mas ainda pode melhorar

14 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

15 MB A MB A B B ME MC MA MD E C (MA) (MA) log C (MA) D D E

16 Conteúdo MA MA Qualquer sistema interessado pode ouvir o log de eventos v3 v2 MAv1 log log log 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

17 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 GUI de Cadastro Serviço de Usuários Serviço de conciliação Serviço de Vendas Serviço de classif Vendedor GUI de Vendas URA

18 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 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

19 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

20 Complexidade adicional Desafio técnico e cultural É preciso atuar na formação e na capacitação dos times Revisão de modelo existente Não é hype, é uma nova leitura de um modelo maduro e consolidado Muda a forma de estimar Menor dependência entre times, porém com maior sincronização Modelo de crescimento Maior resiliência Escala para grandes projetos e times Permite isolamento de pontos de falha, backpressure, etc Motiva os times Menor lead time traz sensação de trabalho realizado Requer maturidade e ferramental para ser efetivo

21 Buscando desafios? Diego de Oliveira e Marden Neubert Abril de 2017