Microservices
101

alexrios.github.io

alex.rios@pm.me

@alextrending

Pequenos serviços autônomos que funcionam em conjunto, modelados pelo domínio do negocio.

tradução livre

Não é nada mais que um SOA feito de maneira dogmática

Que tipo de dogma?

Dogma é uma crença ou doutrina estabelecida de uma religião, ideologia ou qualquer tipo de organização, considerada um ponto fundamental e indiscutível de uma crença

https://12factor.net

Time DevOps quando pega uma App no padrão 
12 factor

Os 8 pilares em uma arquitetura de microserviços

Modeled around 
business domain

Modelo anemico == BOLOVO

Time especialista naquele negocio

O grande desafio é achar os bounded contexts do sistema atual para alcançar a independência das Squads

Job rotation é legal, mas tem que ser desejo do DEV

Bounded context?

É o foco da seção de design estratégico do DDD, que trata de grandes modelos e equipes

 O DDD lida com grandes modelos dividindo-os em diferentes contextos limitados e sendo explícito sobre suas inter-relações

https://martinfowler.com/bliki/BoundedContext.html

Infra automatizada

Testes (unitário, integração, aceitação, performance, carga) automatizados

CI/CD

Automatize tudo que for possível e, em médio prazo, se preocupe apenas com resolver os problemas do negocio

Hide implementation details

1 servico por db = OK

2 servicos por db = meh... ok

Uma alteração de schema provoca uma coordenação maior entre os serviços, mas ainda assim é uma operação segura

Uma vez que você deixa um novo serviço acessar a mesma base, isso provoca uma exposição desnecessária de seus detalhes internos de implementação.

Precisa da informacao? API CALL!

O controle do que deve ser visto ou não, é do provedor da informação.

3 - Hide implementation details

Costumer e Products são conceitos diferentes em sistemas diferentes

Expor informação é caro, pois uma vez exposto não tem uma volta simples.

4 - Descentralize all the things

Times independentes, autônomos

4 - Descentralize all the things

O que  é autonomia?

Dar às pessoas quanta liberdade for possível para que o trabalho delas seja feito

4 - Descentralize all the things

O time controla o destino do seus projetos

(Isso é ownership)

4 - Descentralize all the things

Quer uma maquina na GCP para subir seu projeto? um novo tópico, dataset e etc?

Não demande a ninguém, faca você mesmo.

http://gilt-tech.tumblr.com/post/102628539834/making-architecture-work-in-microservice

4 - Descentralize all the things

Dumb pipes, Smart endpoints

https://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

4 - Descentralize all the things

Dumb API Gateways, Smart Services

(2018)

5 - Deploy Independently

Services per host?

Host = isolated system (container, virtual machine)

5 - Deploy Independently

Application servers = custo de provisionamento

Mais services por host = um "atrapalha" o outro compartilhando performance

Como monitorar um recurso compartilhado? quem eh o ofensor naquele host?

Quando eu faço uma mudança, quem eu afeto?

Sempre deployar tudo junto funciona para ganhar segurança, mas isso causa dependência e diminui a velocidade das releases

Como eu garanto que o serviço que depende de mim (que eu não sei como foi implementado) vai continuar funcionando apos a minha mudança?

5 - Deploy Independently

Consumer driven contracts

(pact.io)

5 - Deploy Independently

Durante a integração continua meu projeto vai rodar baseado no contrato que meus clientes esperam do meu serviço

Uma falha garante que não vamos colocar nada errado em produção e nos vai apontar com que consumidor temos que procurar para alinhar as mudanças

5 - Deploy Independently

5 - Deploy Independently

Deploy independentes!

Precisamos quebrar eventualmente os consumidores, pois simplesmente não podemos forca-los a se atualizar

Manter a versão antiga coexistindo e ter um deadline para remover a API

5 - Deploy Independently

Deploy independentes!

Manter 2 APIs vai ser necessário em algumas vezes, então prepare-se para manter 2 base de códigos para o mesmo serviço

Monitore as versões legadas e se um dia a essa versão não for mais chamada, simplesmente remova a branch

5 - Deploy Independently

Documentação de qualidade

6 - Consumer first

swagger.io

Muitas APIs hoje em dia suportam exportar para Swagger

6 - Consumer first

SwaggerUI pode testar e brincar com sua API diretamente da documentação

Service discovery

6 - Consumer first

Consul - etcd - zookeeper

Humane Registries

(README - Wiki page)

Explodir o seu monolito em vários serviços não vai fazer você ter um conjunto de serviços mais eficiente/resiliente. na verdade vai ser ao contrario

7 - Isolate failure

7 - Isolate failure

Mais maquinas, falhas mais frequentes,

mais saltos (hops) de redes, mais problemas de rede

7 - Isolate failure

Distributed single point of failure

O que é falha?

7 - Isolate failure

A failure is the inability of a software system or component to perform its required functions within specified performance requirements.

7 - Isolate failure

Strangler App

https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/

O que é pior que falhar?

7 - Isolate failure

7 - Isolate failure

Falhar devagar

7 - Isolate failure

Saturação do thread pool

Reconfigurar timeouts?

7 - Isolate failure

Bulkhead (downstream connections)

7 - Isolate failure

Bulkhead (downstream connections)

7 - Isolate failure

Circuit breakers

7 - Isolate failure

8 - Highly observability

Gerenciar e monitorar servidores, apps, logs, heatmaps UX/UI e etc

Agregar logs: stack driver, kibana, paper trail

Agregar status: new relic, app dynamics, data dog, prometheus

8 - Highly observability

Serviços interconectados?

Correlation id!

Zipkin.io

Menção honrosa

Conway's law

Menção honrosa

Conway's law

Resumão (1/2)

As fronteiras da sua API devem ser estaveis

O time precisa de um especialista do negocio com eles para terem independência e ownership

Automatize tudo que for possível para não ter peças soltas ou com longos processos manuais

Esconder os detalhes da implementação vai te dar independência de mudar seus processos e tecnologias sem quebrar nenhum outro serviço

Serviços existem para serem chamados, pense com a visão do chamador/cliente sempre

Entenda seus pontos de falha, se planeje para aplicar técnicas mitiga-los

Crie monitoramentos e alertas para ter um sistemas altamente observável

Deploys independentes!!!

Resumão (2/2)