Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Patterns for Asynchronous Microservices with NATS

Presentation from a talk by Raul Perez (@repejota) of R3Labs on asynchronous microservices patterns using NATS (@nats_io), the lightweight, high performance open source messaging system written in Go.

You can learn more about NATS at http://www.nats.io

  • Login to see the comments

Patterns for Asynchronous Microservices with NATS

  1. 1. Patterns for Asynchronous Microservices Raül Pérez - @repejota NATS London - 10/05/2016
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Questions? Raül Pérez - @repejota NATS London - 10/05/2016
  25. 25. Thank you! 25Raül Pérez - @repejota NATS London - 10/05/2016

×