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

Transcript

1. Seu microsserviço realmente está pronto para produção? Kamila Santos @kamila_code
2. 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
3. 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?
4. Autônomos - Cada serviço pode ser desenvolvido, escalado e implantado sem interferir em outros serviços. Características dos microsserviços
5. 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
6. Especialistas - Cada serviço é desenhado para resolver um problema específico, se começar a ser necessário ter outras responsabilidades, é indicado que se crie um novo serviço. Características dos microsserviços
7. 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 fluxo. Características dos microsserviços
8. Algumas das boas práticas apresentadas aqui são as mesmas apresentadas no livro Microsserviços prontos para produção Boas práticas
9. 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
10. Um microsserviço confiável é aquele que outros microsserviços daquele ecossistema podem confiar. Confiablidade
11. 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
12. 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
13. Possui seus clientes (serviços que o consomem) conhecidos. Um microsserviço pode ser considerado estável e confiável quando
14. Nunca deve existir uma parte do ecossistema de microsserviços que uma falha pode parar todo o fluxo. Tolerância a falhas
15. 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
16. 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
17. Ele é testado por meio de testes de carga e teste de caos. Um microsserviço pode ser considerado tolerante a falhas quando
18. Existe um procedimento padrão para tratar incidentes dentro das equipes. Um microsserviço pode ser considerado tolerante a falhas quando
19. É possível acompanhar o que está acontecendo e o que já aconteceu com os seus microsserviços Monitoramento
20. Seu logging reflete com precisão os estados passados do microsserviço Um microsserviço pode ser considerado com um bom monitoramento quando
21. 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
22. Possui bons alertas Um microsserviço pode ser considerado com um bom monitoramento quando
23. 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
24. 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
25. Contém uma descrição da responsabilidade daquele microsserviço É atualizada frequentemente Um microsserviço pode ser considerado bem documentado quando a documentação
26. 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
27. 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
28. 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
29. - Realizar hash/encriptação de dados sensiveis e senhas - não trafegar dados sensíveis em logs - Fazer uso de APIs gateways Segurança
30. - 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
31. - 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
32. - Snyk, Fortify - Owasp TOP10 e conteúdos OWASP em geral Segurança
33. Você tem uma aplicação que acabou crescendo demais e precisa separa-la em partes menores, pontos a serem considerados: Decompose by business capability
34. https://microservices.io/patterns/decomposition/decompose-by-business-capability.html ▹ Decompose by business capability
35. Com o tempo as aplicações vão crescendo , o código vai ficando 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
36. ▹ Strangler Application https://microservices.io/patterns/refactoring/strangler-application.html
37. 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
38. Problema: como implementar consultas em uma arquitetura de microsserviços? Solução: implemente uma consulta definindo um API consumer, que invoca os serviços que possuem os dados e executa uma junção na memória dos resultados. API composition
39. ▹ Pattern: API Composition
40. Problema: como implementar uma consulta que recupera dados de vários serviços em uma arquitetura de microsserviços? Solução: defina um banco de dados de somente leitura, que é uma replica do "oficial" somente para consulta, a aplicação manterá essa replica atualizada por meio de eventos CQRS
41. ▹ CQRS https://microservices.io/patterns/data/cqrs.html
42. 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
43. ▹ API GATEWAY https://microservices.io/patterns/apigateway.html
44. ▹ BFF https://microservices.io/patterns/apigateway.html
45. Obrigada!