microservices: mais que uma arquitetura de software, uma filosofia de desenvolvimento de software

Microservices

Emmanuel Neri

Mais que uma arquitetura de software, uma filosofia de

desenvolvimento de software

Agenda

● O que é microservices

● Comunicação entre serviços

● Um exemplo de aplicação

● Boas práticas

● Mudanças

● Conclusões

Microservices

“Microservices are small, autonomous services that work together”

Sam Newman

“A small application that can be deployed independently, scaled independently, and

tested independently and that has a single responsibility.”

Johannes Thones

Linha do tempo

Lei de Conway

“Any organization that designs a system (defined more broadly here than just information

systems) will inevitably produce a design whose structure is a copy of the organization’s

communication structure. “

Melvin Conway’s

Características

FOWLER; LEWIS (2014)

● Composto por um conjunto de serviços “pequenos”● Serviços autônomos● Permite ser escalado horizontal e vertical● Possui liberdade de tecnologia● Flexibilidade de deploy● Facilidade para integrações● Maior tolerância a falhas

Escalabilidade

● Eixo X - Duplicação horizontal

● Eixo Y - Decomposição vertical

● Eixo Z - Separação dos dados

Microservices é igual SOA?

“SOA é algo maior, utilizando para

integração de monolitos”

FOLWER; LEWIS (2014)

● Serviços reutilizáveis

● Serviços compartilham um contrato formal

● Serviços possuem baixo acoplamento

● Serviços autônomos

● Etc...

Princípios de SOA:

Como organizar os serviços?

Comunicação entre os serviços

● “HTTP é o padrão de comunicação no microservices”

○ Martin Fowler

● “O serviços devem ser assíncronos”

○ Jonar Bonér (Reactive Microservices Architecture)

■ Terceira onda de bigdata: “data in motion”

Características das comunicações ● Síncrona

○ Espera resposta

○ Comunicação em “tempo real”

○ Balanceador de carga a nível de infraestrutura

○ Tratamento de erros pode ser pelo status do http

● Assíncrona

○ Não espera resposta

○ Comunicação entre os dados pode ser “delay” entre as estruturas

○ Balanceador de carga pode ser uma fila

○ Possibilidade de Service Discovery / Message broker

○ Tratamento de erros pode ficar no gerenciador da fila

○ Em caso de erros o gerenciador de mensagens pode tratar o reenvio

Implementações de comunicação ● Síncrona

○ Rest, SOAP, CDI

● Assíncrona

○ Mensagens, Eventos, Replicação de base

Exemplo

Síncrona Assíncrona

Síncrona Assíncrona

Síncrona Assíncrona

Síncrona Assíncrona

Síncrona Assíncrona

Comparativo de tempo execução do relatório que utiliza dados das aplicações de pedidos e cadastros.

Testes Tempo

Execução 1 175

Execução 2 31

Execução 3 31

Execução 4 30

Execução 5 29

Média: 59,2 milissegundos

Testes Tempo

Execução 1 15

Execução 2 9

Execução 3 10

Execução 4 10

Execução 5 9

Média: 10,6 milissegundos

Conclusões do exemplo

Síncrona AssíncronaVantagens Desvantagens

Dados em tempo real Maior tempo entre as comunicações (maior

preocupação com performance)

Dados Centralizados Baixa integridade entre os relacionamentos

Maior reaproveitamento dos serviços

Serviços impactante em outras funcionalidades

Vantagens Desvantagens

Sincronizações transparentes para o usuário

Possibilidade de indisponibilidade dos dados

Serviços totalmente independentes

Replicação dos dados / Replicação de código

Maior complexidade com sincronizações

Frameworks● Dropwizard

● KumuluzEE

○ Duke's Choice Award Winner 2015

● Micro Profile

○ Wildfly Swarm

● Spring Boot

Boas práticas● Baixo acoplamento ● Bounded Context (DDD)

Boas práticas● Single Responsibility Principle ● Single Point of Failure

Mudanças no desenvolvimento● Desenvolvimentos voltados a APIs

● Desafios de Sistemas distribuídos

○ Base de dados distribuídas, Transações distribuídas, Latência de rede

● Complexidade nos testes automatizados

○ Testes distribuídos

● Segurança

Mudanças na cultura● DevOps

● Maior número de aplicações / instâncias

● Integrações constantes

● Governança dos serviços (APIs)

● Desenvolvimento multiprojetos

Por onde começar?

● Migração por camadas

○ Aplicação? Banco de dados?

● Começar de uma aplicação existente

Padrões de migração de monolitos

● Strangler Application ● Depedency Inversion Principles

Conclusão

● Vários trade-offs

○ Como fazer comunicação entre os serviço?

○ Como separar os serviços?

● Mudanças de cultura

● Mudança na forma de desenvolvimento

Referências● Building Microservices: Designing Fine-Grained Systems - Sam Newman

● The Art of Scalability - Martin L, Abbott, Michael T. Fisher ● Domain-Driven Design - Eric Evans● DevOps: A Software Architect's Perspective - Len Bass, Ingo Weber, Liming Zhu● Reactive Microservices Architecture - Jonas Bonér● http://martinfowler.com/articles/microservices.html● http://pt.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in-microservices● http://pt.slideshare.net/gutomcosta/como-ddd-e-strategic-design-esto-nos-ajudando-a-m

odernizar-um-legado● http://pt.slideshare.net/ewolff/rest-vs-messaging-for-microservices● https://www.infoq.com/br/presentations/microservicos-uma-jornada-inesperada● http://pt.slideshare.net/tdc-globalcode/tdc2016sp-trilha-microservices-64181673