The document is a presentation by Raül Pérez discussing patterns for asynchronous microservices, emphasizing the importance of using a broker approach like NATS for communication to enable scalability and flexibility. It compares synchronous and asynchronous communication, highlighting the trade-offs between simplicity and complexity. Additionally, it stresses the significance of autonomy in services to allow them to evolve independently while delivering complete business capabilities.

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.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.comRaül Pérez - @repejota NATS London - 10/05/2016

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

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