MTC_2016-analise_efetiva_de_microsservicos

B em - v i n d o s

ANÁLISE EFETIVA DE MICROSSERVIÇOS EM 3 PASSOS

Taíse Dias da Silva

BACKGROUND

2

Testes de software

20092006

Ciência da Computação, UFPE Metodologias ágeis Web services

2013

Times distribuídos Microsserviços

2014

Análise de Microsserviços em times distribuídos

FALAREMOS SOBRE

3

Análise

Microsserviços

Contexto & Desafios

3 passos para análise

4

ANÁLISE

Fonte: The Agile Samurai: How Agile Masters Deliver Great Software. Rasmusson, Jonathan.

O QUE É FAZER ANÁLISE?

5

“Deixa que a gente se preocupa com os detalhes.”

Conta com a gente pra

fazermos nossa tarefa de casa, pra toda e cada

iteração!

Ajudar a definir histórias do usuário

Fazer a análise detalhada

Garantir que fizemos nosso trabalho

Sei o que quero, mas como descrevo isso?

Fazer web site

3 meses

Artefatos de análise

O que? Por quê? Pra quem?

HISTÓRIA DO USUÁRIO

6

Como palestrante do MTC que não mora em BH

Eu quero listar nome, preço e localização de hotéis de BH disponíveis em 18 de junho

Para que eu possa escolher um hotel perto do local do evento

I

N

V

E

S

T

Independente

Negociável

Valiosa

Estimável

Pequena (small)

TestávelInterface com o usuário (HTML, CSS) Camada do meio (C#, Java, Python) Camada de dados (Oracle, SQL Server)

Fonte: The Agile Samurai: How Agile Masters Deliver Great Software. Rasmusson, Jonathan.

BACKLOG

▫︎Conjunto das histórias para features do produto

▫︎Geralmente com épicos que agrupam histórias de mesma área do domínio

▫︎ Exemplo de épico: cadastro de cliente

▫︎Cadastro manual: nome, email, etc.

▫︎Cadastro via facebook

7

E quando as histórias são implementadas por microsserviços?

8

9

MICROSSERVIÇOS

O QUE SÃO MICROSSERVIÇOS?

10

Arquitetura monolítica: várias features em um único executável

Arquitetura de microsserviços: conjunto de serviços, cada um sendo um executável e responsável por uma feature

Problemas: -Implantação de uma feature requer implantação de todas -Difícil de manter a modularização -Escalar horizontalmente requer mais infra

Soluções: -Implantação de uma feature independente de outras -Comunicação simples, protege módulos -Escalar horizontalmente requer menos infra

BOAS PRÁTICAS

▫︎ Testes automatizados em todos os níveis

▫︎Unitários, integração, contratos, jornadas de usuários

▫︎ Integração contínua

▫︎ Implantação automatizada

▫︎Monitoração

▫︎ Times cuidando de feature

▫︎ Times mantendo os microsserviços independentes

11

Mas e quando não se consegue adotar todas as boas práticas?

12

13

CONTEXTO & DESAFIOS

ORGANIZAÇÃO DOS TIMES

14

Versus

Produto'B'

Web$Service$A$

Produto'A'

Web$Service$B$

Portal$

Web$Service$C$ Web$Service$D$

Time'4'Time'3'

Aplicação$$$$$Cliente$

Time'2'

Time'1'

Produto'B'

Web$Service$A$

Produto'A'

Web$Service$B$

Portal$


Time'4'Time'3'


Time'2'Time'1'

ORGANIZAÇÃO DO BACKLOG

15

Produto'B'

Web$Service$A$

Produto'A'

Web$Service$B$

Portal$


Backlog'4'Backlog'3'


Backlog'2'

Backlog'1'

Produto'B'

Web$Service$A$

Produto'A'

Web$Service$B$

Portal$





Versus

V

DESAFIOS

▫︎Quando times perdem a visão do todo

▫︎ Escopo das histórias delimitado por endpoints

▫︎ Pode perder o benefício das características INVEST

16

I

T

dependentes das histórias do cliente

endpoints podem ser são features incompletas

usuários não testam endpoints

DESAFIOS

▫︎Quando times ficam bloqueados por dependência em histórias de outros times

▫︎Difícil de alinhar prioridades entre times

▫︎ Time do cliente dependendo do time de serviços

▫︎ Velocidades por histórias em vez de por features podem dar uma falsa visão de progresso

17

DESAFIOS

▫︎Quando demora pra surgirem problemas de integrações

▫︎mau funcionamento do produto

▫︎ pode atrasar ou abortar entregas

18

TIMES DISTRIBUÍDOS

19

▫︎ Escalando desafios

Como conseguir fazer uma análise efetiva nesse contexto?

20

21

3 PASSOS PARA ANÁLISE

3 PASSOS PARA ANÁLISE

1. Mapear features em épicos

2. Mapear dependências entre histórias do épico

3. Definir critérios de aceitação para integrações

22

1. MAPEAR FEATURES EM ÉPICOS

▫︎ Problema: falta de visão do todo

▫︎ Solução: tratar épico como cidadão de primeira classe

▫︎O que? Por quê? Pra quem?

▫︎Usar épico na priorização e velocidade

23

[ÉPICO] Visualizar margem de lucro Como planejador de compras

Eu preciso saber qual a margem de lucro do meu plano de compras

Para que eu possa tomar decisões de planejamento de acordo com meu orçamento

▫︎ Problema: bloqueios por conta de dependências

▫︎ Solução: colaborar para identificar quais as capacidades que cada serviço precisa ter

▫︎ Identificar as possíveis dependências entre elas para que o usuário consiga atingir seu objetivo

▫︎Usar como base a arquitetura definida pelos times para a feature

▫︎ Priorização baseada nas dependências

2. MAPEAR DEPENDÊNCIAS ENTRE HISTÓRIAS DO ÉPICO

24

EXEMPLO

25

[ÉPICO] Visualizar margem de lucro Como planejador de inventário



[Custo] Listar custo do produto

[Plano] Calcular margem de lucro

[Preço] Listar preço do produto

Objetivo do ponto de vista

do usuário

Histórias de serviços para

atingir o objetivo

3. DEFINIR CRITÉRIOS DE ACEITAÇÃO PARA INTEGRAÇÕES

▫︎ Problema: integração causa mau funcionamento dos produtos e possíveis atrasos de entrega

▫︎Usar jornadas de usuário pra definir critérios de aceitação no nível de épico

▫︎ Considerar os produtos impactados

▫︎Definir critérios de aceitação pros serviços com foco em regras de negócio, independente de interface

▫︎ Feedback mais rápido sobre os problemas de integração

26

EXEMPLO: CRITÉRIO DE ACEITAÇÃO PRO ÉPICO

27

[ÉPICO] Visualizar margem de lucro Como planejador de inventário



Jornada passando por múltiplos produtos

1. Usuário do produto de gerenciar custo define o custo do produto

2. Usuário do produto de gerenciar preços define o preço do produto

3. Planejador acessa produto de plano de compras do produto e visualiza a margem de lucro

Teste de sistemas, de ponta a ponta, entre diferentes produtos. Lento pra ser executado, mas de alto valor de negócio. Deve cobrir jornadas de mais alto nível.

EXEMPLO: CRITÉRIO DE ACEITAÇÃO PRAS HISTÓRIAS

28

Serviço que gerencia

custo

[Custo] Listar custo do produto

Dado que camisas regatas brancas pro verão de 2016 custa 2 dólares Quando eu listo custo de camisa regata branca do verão de 2016

Então vejo que o custo é 2 dólares

[Preço] Listar preço do produto

Dado que camisas regatas brancas pro verão de 2016 valem 20 dólares Quando eu listo preço de camisa regata branca do verão de 2016

Então vejo que o preço é 20 dólares


preço


plano

[Lucro] Calcular margem de lucro

Dado que camisas regatas brancas pro verão de 2016 custam 2 dólares e valem 20 dólares Quando eu visualizo a margem de lucro do meu plano de compras Então vejo a margem é de 18 dólares

29

RESUMO

RESUMO

Para o contexto em que:

▫︎ times distribuídos não são organizados por features ▫︎ cuidam de serviços que são utilizados por múltiplos produtos ▫︎ não conseguem usar todas as boas práticas pra se trabalhar com microsserviços

A análise dos microsserviços podem ser feita como segue:

▫︎ mapeando features em épicos para os times não perderem a visão do todo

▫︎ mapeando dependências entre histórias de um mesmo épico pra que um time não fique bloqueado

▫︎ planejando critérios de aceitação nos níveis de épicos e histórias para não agir apenas reativamente aos problemas de integração

30

Perguntas?

OBRIGADA

@taisedias github.com/taisedias

linkedin.com/in/taisedias

REFERÊNCIAS

▫︎ The Agile Samurai: How Agile Masters Deliver Great Software. Rasmusson, Jonathan.

▫︎Microservices. Martin Fowler.

▫︎MicroservicePrerequisites. Martin Fowler.

▫︎Microservice trade offs. Martin Fowler.

▫︎ Enterprise Integration Using REST. Martin Fowler.

32

MTC_2016-analise_efetiva_de_microsservicos

Software

Transcript of MTC_2016-analise_efetiva_de_microsservicos