Microservices é um conceito que está na cabeça de todo mundo da tecnologia neste momento. Existem várias outras teorias e patterns que estão ajudando a fazer dos microservices uma estratégia de sucesso para o desenvolvimento de aplicações de média e larga escala. Vamos entrar fundo em alguns conceitos e ver como eles podem ajudar na hora de produzir uma arquitetura robusta de microservices.

1. +
Reactive Architecture e
Microservices:
Microservices, APIs e Event Driven

2. http://sensedia.com/blog/
Petterson Andrade
Software Architect @ Sensedia
petterson.andrade@sensedia.com
@pett4j

3. Topic Title
Agenda
1. Microservice 2. Microservice 3. Microservice

4. Arquitetura de
software

6. Pessoas

8. Monolitico x Microservices
Cruzeiro x Atlético
Grêmio x Inter

9. Microservices

10. Single
Responsibility
principle
Dividir para conquistar
Foco
Pequeno
Bem Feito

11. Por que
adotar?
- Escolha a tecnologia certa para resolver o
problema
- Você não precisa repassar um problema você
pode isolar e se recuperar
- Você precisa escalar somente o que vai utilizar
- Desenvolva e teste rápido e focado
- Serviço pequeno, menos conflito, menos erros e
mais produtividade
- Re-uso! Não reinvente a roda!
- Otimize, joge fora e faça melhor!

12. SOA == Microservices (true)
SOA != Microservices (true)

13. O princípios
são iguais
Desacoplamento
Isolamento
Composição
Integração
Serviços autồnomos

14. A falta dos
princípios não
ESB ligando monolíticos
Comunicação complicada
Ineficiência
Sem flexibilidade

15. SOA == Microservices
SOA Microservices

17. Strangler Application
Pattern
Martin Fowler - 29 June 2004

18. Paul Hammant
http://paulhammant.com/2013/
07/14/legacy-application-strang
ulation-case-studies/

19. Você venceu sua jornada: é o fim do monolítico

20. Mas lembre-se: Você está em rota de colisão

21. E agora? Quem
poderá nos
defender?

22. San
Newman
samnewman.io

23. Chris
Richardson
microservices.io

24. Jonas Bonér
www.lightbend.com

25. Martin
Fowler
martinfowler.com

26. Eric Evans
domainlanguage.com/ddd

27. The Reactive
Manifesto
Published on September 16 2014. (v2.0)

29. - Aplicações eram gigantes e com dezenas de servers
- Segundo é a unidade de medida de resposta
- Horas de manutenção e de sistemas fora do ar
- Gigabytes é a unidade de medida de armazenamento

32. - Aplicações distribuídas
- Você faz tudo com um comando pelo smartphone
- Nuvem rodando milhares de máquina multi-core
- Milissegundos é obrigatoriamente a unidade de medida de
resposta
- 100% uptime.
- Data is measured in Petabytes.

33. Transformação
Digital

34. S M A C IoT
TODO NEGÓCIO SERÁ DIGITAL

35. The Reactive Manifesto
Se um sistema é:
Responsive, Resilient, Elastic and Message Driven,
Ele pode ser chamado de Reactive System

36. The Reactive Manifesto:
Responsive
Sempre da feedback aos usuários
Responde em tempo hábil
Detecta problemas e trata
Rápido e consistente
Alta confiabilidade
.

37. The Reactive Manifesto: Resilient
Responde em caso de falha
Replicação
contenção,
isolamento e
delegação.

38. The Reactive Manifesto: Elastic
Continua responsivo mesmo com aumento da demanda
Aumenta e diminui os recursos conforme a demanda
Distribui demanda

39. The Reactive Manifesto:
Message Driven
Usa mensagens assíncronas
Baixo acoplamento
Tratamento de erros por mensagem
Comunicação não blocante
Evita desgaste do sistema

41. Aqui é reativo p…!
BIIIIRRRLLL!
Sai de casa escrevi
código pra c……!

42. Fonte de dados
isolada

44. Event Driven
Data

49. Event Source

51. Synchronous
Versus
Asynchronous

52. 100
ms
70
ms
50
ms
100
ms
Synchronous
320 ms
Req Resp

53. Req
70
ms
50
ms
100
ms
Asynchronous
Resp
100ms

54. Req
70
ms
50
ms
100
ms
Asynchronous
Resp
?

56. Backpressure

57. - O sistema precisa ser capaz de reagir ao erro
- Tempo de resposta não pode ser afetado
- Não pode propagar o erro
- Precisa ser capaz de fazer Rollback

58. Asynchronous

59. Orchestration vs
Choreography

60. Service 1 Service 3
Service 4
Service 2
Orchestration

61. Service 1 Service 3
Service 4
Service 2
Choreography
Service 3
pub
sub
sub
sub

62. API Management

63. API Gateway

64. API Gateway
Simplifica o client side
Roteamento
Encapsulamento de serviços
Tradução de protocolo

65. Service Discovery

67. - Inversão de controle
- Cada serviço se registra
- Configuração deixa de ser estática
- Pode ser aplicado ao cliente
- Deve ser aplicado ao server

68. API / REST / RESTFul

69. APIs
The Digital Glue
Backend
Ecossistema de
Parceiros Digitais
Integrações com
Aplicações SaaS
Aplicações Móveis e
Internet of Things

70. - Over HTTP
- Tira dependência de tecnologia
- O sistema precisa ser capaz de reagir ao erro
- Use padrões
- Implemente Restful de verdade

71. Hypermedia

73. - Use HAL (Hypertext Application Language)
- Hypermedia garante flexibilidade
- Possui suporte de várias bibliotecas

74. Front-end isolado

75. Aplicação 1
Aplicação
Web App
HTML
JS
Services
Acoplado Desacoplado
Web App
HTML
JS
Aplicação 2
Services

76. WEB Sockets

77. - Padrão no HTTP 2.0
- Torna o sistema mais responsivo
Client
API
WebSocket Server
Fire and forget
Events

78. Programação
reativa

79. - Padrão no HTTP 2.0
- Torna o sistema mais responsivo

80. Programação
reativa

81. - Use ferramentas para auxiliar
- RXJava
- RXJS
- Avalie usar imutabilidade
- Avalie usar funcional

82. Monitoramento

83. - Monitore tudo que for possível e mais um pouco
- Alerte a performance do serviço
- Alerte qualquer anomalia a estrutura
- Evite falsos positivos, refine os alertas
- Avalie o tempo todo as métricas
- Automatize e depois automatize de novo

84. Scalability

85. - Scale out
- Services Stateless
- Comunicação por eventos
- Nunca use pooling
- Deployment

86. Deployment