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.
