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
Culture of automation
Hide implementation
details
Decentralize all
the things
Deploy independently
Consumer first
Isolate failure
Highly
observable
Modeled around
business domain
N tier ou Onion arch
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
Culture
of
automation
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.
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
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!
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