Patterns for Asynchronous Microservices with NATS

Patterns for Asynchronous Microservices

Raül Pérez - @repejota NATS London - 10/05/2016

Who am I?Raül PérezLead Software Engineer at R3 Labs Ltd.

Twitter: @repejotaGithub: https://github.com/repejotaEmail: [email protected]

2Raül Pérez - @repejota NATS London - 10/05/2016

https://twitter.com/repejota

https://github.com/repejota

mailto:[email protected]



3

● Almost 4 years working on devops & distributed projects.







4


● Still more a dev than op dude.







5



● Proud to be a Gopher after a looong PHP/Ruby/Python/Node.js past experience. :P







6




● Based in Barcelona.Raül Pérez - @repejota NATS London - 10/05/2016






7




● Based in Barcelona.

● Love startups & love remote work!





Summary


● Why microservices?

● Synchronous vs. Asynchronous communication.● Pattern: Broker approach & NATS● Pattern: Autonomy of services vs. Coordination between services.

Why microservices?


● Loosely coupled components.● Specific responsibility, each one delivers a capability.● Designed to be defensive against failures.

Why microservices?


● 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.

Pattern: Sync vs. Async communication.


● The most common interface to communicate is HTTP.● But HTTP is “mostly” synchronous.● Once the number of services grow, HTTP is sometimes not enough.



● 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.



● 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?



● 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...

Pattern: Broker approach & NATS


● Loosely coupled clients and servers.● Multiple patterns: Publish/Subscribe,

Request/Response.● Easy to scale.





● NATS is fast!





● NATS is fast!● Just a message system, no

assumptions, no extra features. Easy to deploy, easy to use.







● It is also secure: SSL, password ...







● It is also secure: SSL, password ...● Simple protocol, it is just text.

Pattern: Autonomy vs. Coordination.


● 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”




● 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.

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

http://microservices.io/

https://en.wikipedia.org/wiki/Cloud_computing

http://nats.io/

http://repejota.com/

http://carrenza.com/

http://ernest.io/

http://apcera.com/

Questions?


Thank you!


Patterns for Asynchronous Microservices with NATS

Technology

Transcript of Patterns for Asynchronous Microservices with NATS