Seu microsserviço realmente está pronto para produção?

Slide 1

Slide 1 text

Seu microsserviço realmente está pronto para produção? Kamila Santos @kamila_code

Slide 2

Slide 2 text

Kamila Santos Tech Lead na Zup Innovation Microsoft MVP Co-org WomakersCode, DevsJavaGirl e Perifacode Criadora de conteúdo no @kamila_code co-autora dos livros Jornada Java e Jornada Microsserviços

Slide 3

Slide 3 text

São uma abordagem de arquitetura na qual o software é composto de pequenos serviços independentes que se comunicam entre si e são organizados de acordo com seus domínios de negócio. O que são microsserviços?

Slide 4

Slide 4 text

Autônomos - Cada serviço pode ser desenvolvido, escalado e implantado sem interferir em outros serviços. Características dos microsserviços

Slide 5

Slide 5 text

Autônomos - Não é necessário compartilhar nenhum código e a comunicação acontece por meio de chamadas as APIs (síncronas) ou de forma assíncrona. Características dos microsserviços

Slide 6

Slide 6 text

Especialistas - Cada serviço é desenhado para resolver um problema especíﬁco, se começar a ser necessário ter outras responsabilidades, é indicado que se crie um novo serviço. Características dos microsserviços

Slide 7

Slide 7 text

Resilientes - A independência do serviço aumenta a resiliência a falhas na arquitetura , se um deles tiver algum problema , só afetará alguma parte do ﬂuxo. Características dos microsserviços

Slide 8

Slide 8 text

Algumas das boas práticas apresentadas aqui são as mesmas apresentadas no livro Microsserviços prontos para produção Boas práticas

Slide 9

Slide 9 text

Um microsserviço considerado estável é aquele que durante o desenvolvimento, deploy, inclusão de novas tecnologias e desativação de outros serviços não resulta em instabilidade do ecossistemas de microsserviços que ele faz parte. Estabilidades

Slide 10

Slide 10 text

Um microsserviço confiável é aquele que outros microsserviços daquele ecossistema podem confiar. Confiablidade

Slide 11

Slide 11 text

Tem um ciclo de desenvolvimento padronizado (para se proteger de más práticas de desenvolvimento) Um microsserviço pode ser considerado estável e confiável quando

Slide 12

Slide 12 text

O código é submetido a testes de unidade, integração, e2e, regras de coverage (o tanto que um teste é coberto por testes) etc. Um microsserviço pode ser considerado estável e confiável quando

Slide 13

Slide 13 text

Possui seus clientes (serviços que o consomem) conhecidos. Um microsserviço pode ser considerado estável e confiável quando

Slide 14

Slide 14 text

Nunca deve existir uma parte do ecossistema de microsserviços que uma falha pode parar todo o fluxo. Tolerância a falhas

Slide 15

Slide 15 text

Também não deve haver qualquer parte individual dentro da arquitetura de um microsserviço que possa derrubar o microsserviço todo quando ele falhar. Tolerância a falhas

Slide 16

Slide 16 text

Microsserviços devem suportar falhas internas (do próprio microsserviço) e falhas externas (que acontecem em outras camadas e serviços externos). Tolerância a falhas

Slide 17

Slide 17 text

Ele é testado por meio de testes de carga e teste de caos. Um microsserviço pode ser considerado tolerante a falhas quando

Slide 18

Slide 18 text

Existe um procedimento padrão para tratar incidentes dentro das equipes. Um microsserviço pode ser considerado tolerante a falhas quando

Slide 19

Slide 19 text

É possível acompanhar o que está acontecendo e o que já aconteceu com os seus microsserviços Monitoramento

Slide 20

Slide 20 text

Seu logging reflete com precisão os estados passados do microsserviço Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 21

Slide 21 text

Seus dashboards são fáceis de interpretar e possuem todas as métricas principais. Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 22

Slide 22 text

Possui bons alertas Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 23

Slide 23 text

Os logs não contêm informações sensíveis e só informações relevantes. Um microsserviço pode ser considerado com um bom monitoramento quando

Slide 24

Slide 24 text

As pessoas que entram na equipe desse serviço conseguem ter acesso a esse histórico de informações, sabe como preparar o ambiente, desenho da arquitetura, dentre outras informações essenciais para que possa iniciar o desenvolvimento? Uma equipe que quiser saber desse microsserviço vai conseguir entender o papel dele somente com a documentação? Documentação

Slide 25

Slide 25 text

Contém uma descrição da responsabilidade daquele microsserviço É atualizada frequentemente Um microsserviço pode ser considerado bem documentado quando a documentação

Slide 26

Slide 26 text

Contém um diagrama de arquitetura Contatos das pessoas responsáveis Guia de bordo de desenvolvimento Collections Faq Um microsserviço pode ser considerado bem documentado quando a documentação

Slide 27

Slide 27 text

Qual o papel dele/em que parte esse microsserviço entra dentro daquele ecossistema. Todas as pessoas da equipe devem saber do conteúdo e pessoas de fora devem compreender. Um microsserviço pode ser considerado bem documentado quando a documentação

Slide 28

Slide 28 text

Algumas regras básicas quando falamos de segurança de aplicações / microsserviços: - Usar autenticação via jwt com tempo de expiração curto Segurança

Slide 29

Slide 29 text

- Realizar hash/encriptação de dados sensiveis e senhas - não trafegar dados sensíveis em logs - Fazer uso de APIs gateways Segurança

Slide 30

Slide 30 text

- Separar tokens de aplicação e token de usuário - Conceder somente os acessos/permissões necessários - Matenha suas dependências atualizadas Segurança

Slide 31

Slide 31 text

- Utilize ferramentas de SAST(Static application security testing ): analisa o código fonte em busca de vulnerabilidades e DAST (Dynamic application security testing): identificar possíveis vulnerabilidades em um aplicativo em execução. Segurança

Slide 32

Slide 32 text

- Snyk, Fortify - Owasp TOP10 e conteúdos OWASP em geral Segurança

Slide 33

Slide 33 text

Você tem uma aplicação que acabou crescendo demais e precisa separa-la em partes menores, pontos a serem considerados: Decompose by business capability

Slide 34

Slide 34 text

https://microservices.io/patterns/decomposition/decompose-by-business-capability.html ▹ Decompose by business capability

Slide 35

Slide 35 text

Com o tempo as aplicações vão crescendo , o código vai ﬁcando mais confuso e ainda vamos evoluindo tecnicamente e pensamos em soluções e implementações melhores do que as anteriores. Para isso, também existem os padrões de refatorações de microsserviços Padrões de refatoração

Slide 36

Slide 36 text

▹ Strangler Application https://microservices.io/patterns/refactoring/strangler-application.html

Slide 37

Slide 37 text

Em sistemas distribuids é muito importante garantir a consistência dos dados, que estejam com os valores corretos e que nenhum dado se perca entre os sitemas. Padrões de gerenciamento de dados

Slide 38

Slide 38 text

Problema: como implementar consultas em uma arquitetura de microsserviços? Solução: implemente uma consulta deﬁnindo um API consumer, que invoca os serviços que possuem os dados e executa uma junção na memória dos resultados. API composition

Slide 39

Slide 39 text

▹ Pattern: API Composition

Slide 40

Slide 40 text

Problema: como implementar uma consulta que recupera dados de vários serviços em uma arquitetura de microsserviços? Solução: deﬁna um banco de dados de somente leitura, que é uma replica do "oﬁcial" somente para consulta, a aplicação manterá essa replica atualizada por meio de eventos CQRS

Slide 41

Slide 41 text

▹ CQRS https://microservices.io/patterns/data/cqrs.html

Slide 42

Slide 42 text

Problema: como os clientes de uma aplicação baseados em microsserviços acessem os serviços individuais. Solução: implemente um API Gateway que seja o único ponto de entrada para todos os clientes APIS EXTERNAS