Raül Pérez gave a presentation on patterns for asynchronous microservices. He discussed how synchronous communication suffers from latency issues and asynchronous communication increases complexity. He proposed using a message broker like NATS to orchestrate communication between loosely coupled microservices using patterns like publish/subscribe and request/response. This approach provides scalability. He also emphasized designing autonomous microservices that minimize coordination to allow freedom of evolution, while ensuring each service delivers a specific business capability.

1. Patterns for Asynchronous
Microservices
Raül Pérez - @repejota NATS London - 10/05/2016

2. Who am I?
Raül Pérez
Lead Software Engineer
at R3 Labs Ltd.
Twitter: @repejota
Github: https://github.com/repejota
Email: repejota@gmail.com
2
Raül Pérez - @repejota NATS London - 10/05/2016

3. Who am I?
Raül Pérez
Lead Software Engineer
at R3 Labs Ltd.
Twitter: @repejota
Github: https://github.com/repejota
Email: repejota@gmail.com
3
● Almost 4 years working on devops & distributed projects.
Raül Pérez - @repejota NATS London - 10/05/2016

4. Who am I?
Raül Pérez
Lead Software Engineer
at R3 Labs Ltd.
Twitter: @repejota
Github: https://github.com/repejota
Email: repejota@gmail.com
4
● Almost 4 years working on devops & distributed projects.
● Still more a dev than op dude.
Raül Pérez - @repejota NATS London - 10/05/2016

5. Who am I?
Raül Pérez
Lead Software Engineer
at R3 Labs Ltd.
Twitter: @repejota
Github: https://github.com/repejota
Email: repejota@gmail.com
5
● Almost 4 years working on devops & distributed projects.
● Still more a dev than op dude.
● Proud to be a Gopher after a looong PHP/Ruby/Python/Node.js past
experience. :P
Raül Pérez - @repejota NATS London - 10/05/2016

6. Who am I?
Raül Pérez
Lead Software Engineer
at R3 Labs Ltd.
Twitter: @repejota
Github: https://github.com/repejota
Email: repejota@gmail.com
6
● Almost 4 years working on devops & distributed projects.
● Still more a dev than op dude.
● Proud to be a Gopher after a looong PHP/Ruby/Python/Node.js past
experience. :P
● Based in Barcelona.
Raül Pérez - @repejota NATS London - 10/05/2016

7. Who am I?
Raül Pérez
Lead Software Engineer
at R3 Labs Ltd.
Twitter: @repejota
Github: https://github.com/repejota
Email: repejota@gmail.com
7
● Almost 4 years working on devops & distributed projects.
● Still more a dev than op dude.
● Proud to be a Gopher after a looong PHP/Ruby/Python/Node.js past
experience. :P
● Based in Barcelona.
● Love startups & love remote work!
Raül Pérez - @repejota NATS London - 10/05/2016

8. Summary
8
Raül Pérez - @repejota NATS London - 10/05/2016
● Why microservices?
● Synchronous vs. Asynchronous communication.
● Pattern: Broker approach & NATS
● Pattern: Autonomy of services vs. Coordination between services.

9. Why microservices?
9
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled components.
● Specific responsibility, each one delivers a capability.
● Designed to be defensive against failures.

10. Why microservices?
10
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled components.
● Specific responsibility, each one delivers a capability.
● Designed to be defensive against failures.
● Designed around business needs.
● Decentralised governance.
● Decentralised data management.
● Connected through a common interface.

11. Pattern: Sync vs. Async communication.
11
Raül Pérez - @repejota NATS London - 10/05/2016
● The most common interface to communicate is HTTP.
● But HTTP is “mostly” synchronous.
● Once the number of services grow, HTTP is sometimes not enough.

12. Pattern: Sync vs. Async communication.
12
Raül Pérez - @repejota NATS London - 10/05/2016
● The most common interface to communicate
is HTTP.
● But HTTP is “mostly” synchronous.
● Once the number of services grow, HTTP is
not enough.
● It also has a complex error
management.

13. Pattern: Sync vs. Async communication.
13
Raül Pérez - @repejota NATS London - 10/05/2016
● Synchronous communication is simple but….
○ Drawback: Suffers from latency on each connection.
● Asynchronous communication is faster but…
○ Drawback: Increases the complexity.
○ Drawback: Snowball effect, difficult to manage and orchestrate.
So, Is there a better communication interface?

14. Pattern: Sync vs. Async communication.
14
Raül Pérez - @repejota NATS London - 10/05/2016
● Pattern: Use a broker to orchestrate your communication needs.
○ AMPQ, RabbitMQ, NSQ, etc ….
○ NATS :)
● A broker is flexible, allows you to use:
○ Work queues.
○ Publish/Subscribe.
○ Request/Response.
○ Message routing.
○ etc...

15. Pattern: Broker approach & NATS
15
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled clients and servers.
● Multiple patterns: Publish/Subscribe,
Request/Response.
● Easy to scale.

16. Pattern: Broker approach & NATS
16
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled clients and servers.
● Multiple patterns: Publish/Subscribe,
Request/Response.
● Easy to scale.
● NATS is fast!

17. Pattern: Broker approach & NATS
17
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled clients and servers.
● Multiple patterns: Publish/Subscribe,
Request/Response.
● Easy to scale.
● NATS is fast!
● Just a message system, no
assumptions, no extra features.
Easy to deploy, easy to use.

18. Pattern: Broker approach & NATS
18
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled clients and servers.
● Multiple patterns: Publish/Subscribe,
Request/Response.
● Easy to scale.
● NATS is fast!
● Just a message system, no
assumptions, no extra features.
Easy to deploy, easy to use.
● It is also secure: SSL, password ...

19. Pattern: Broker approach & NATS
19
Raül Pérez - @repejota NATS London - 10/05/2016
● Loosely coupled clients and servers.
● Multiple patterns: Publish/Subscribe,
Request/Response.
● Easy to scale.
● NATS is fast!
● Just a message system, no
assumptions, no extra features.
Easy to deploy, easy to use.
● It is also secure: SSL, password ...
● Simple protocol, it is just text.

20. Pattern: Autonomy vs. Coordination.
20
Raül Pérez - @repejota NATS London - 10/05/2016
● Make your services autonomous.
● Avoid coordination between different services.
● The minimal coordination the more optimal autonomy.
● Increased autonomy gives it freedom to evolve.

21. Pattern: Autonomy vs. Coordination.
21
Raül Pérez - @repejota NATS London - 10/05/2016
● Make your services autonomous.
● Avoid coordination between different services.
● The minimal coordination the more optimal autonomy.
● Increased autonomy gives it freedom to evolve.
● Your services delivers “capabilities”

22. Pattern: Autonomy vs. Coordination.
22
Raül Pérez - @repejota NATS London - 10/05/2016
● Make your services autonomous.
● Avoid coordination between different services.
● The minimal coordination the more optimal autonomy.
● Increased autonomy gives it freedom to evolve.
● Your services delivers “capabilities”
● What is a capability?
A complete business capability is a process that can be finished
consecutively without interruptions or excursions to other services.

23. Resources
● http://microservices.io
● https://en.wikipedia.org/wiki/Cloud_computing
● http://nats.io
23
● http://repejota.com
● http://r3labs.io
● http://ernest.io
● http://apcera.com
Raül Pérez - @repejota NATS London - 10/05/2016

24. Questions?
Raül Pérez - @repejota NATS London - 10/05/2016

25. Thank you!
25
Raül Pérez - @repejota NATS London - 10/05/2016