Os melhores design patterns para microservices: uma abordagem prática

Você já teve dúvidas sobre como começar uma aplicação baseada em microservices? Ou sobre como quebrar um monolito em vários microservices?

Muitas vezes as respostas não são apenas variadas, mas são até mesmo opostas! O que não ajuda em nada… E daí vem outra questão: há algum caminho seguro que eu possa trilhar para ter sucesso em meus projetos com microservices?

Pode apostar! Alguns design patterns específicos para microservices podem salvar o seu projeto, e nesta sessão vamos mostrar alguns dos melhores deles em uma abordagem 100% prática.

Participe dessa sessão e aprenda as melhores práticas que levarão os seus microservices ao próximo nível. Hoje!

Transcript

1. Os melhores design patterns para microservices: uma abordagem prática Elder Moraes Developer Advocate @elderjava
2. @elderjava 2 Arquitetura de Microservices Estrutura uma aplicação como uma coleção de serviços que sejam: • De fácil manutenção • Altamente testáveis • Implantados de forma independente • Organizados em torno de requisitos de negócio • Controlados por um time pequeno
3. @elderjava 3 Fonte: https://microservices.io/patterns/index.html Cerca de 50 patterns catalogados
4. @elderjava 4 Quais patterns eu posso aprender hoje e já sair usando?
5. @elderjava 5 bit.ly/elderyt Developer Advocate na Red Hat Board Member no SouJava Autor do livro Jakarta EE Cookbook Foco: ajudar desenvolvedores a construir e entregar aplicações incríveis
6. @elderjava 6 6 Design Patterns • Service per team • Externalized Configuration • Circuit Breaker • Health Check API • Distributed Tracing • Application Metrics
7. @elderjava 7 Service per Team (o único que não tem código)
8. @elderjava 8 Service per Team Fonte: https://microservices.io/patterns/decomposition/service-per-team.html
9. @elderjava 9 "Any organization that designs a system… will produce a design whose structure is a copy of the organization's communication structure.” - Melvin E. Conway Lei de Conway
10. @elderjava 10 Service per Team • Times se tornam mais autônomos • Times trabalham mais desacoplados • Favorece qualidade de código devido ao fator de longo prazo • Times não necessariamente estão alinhados com o usuário final • Maior complexidade com funcionalidades que dependem de outros serviços
11. @elderjava 11 Code Time!!!
12. @elderjava 12 • Externalized Configuration • Circuit Breaker • Health Check API • Distributed Tracing • Application Metrics
13. @elderjava 13 developers.redhat.com