Microservices with Pattern Matching and Seneca.JS

[blainsmith]

About Me Most of my info can be seen on my website: http://blainsmith.com. I am also a core contributor to Seneca.JS.

Description Microservices are the new hotness. We have started to heavily use http://senecajs.org for all of our services. I've tried to really ingrain myself with the maintainers to help this grow. I would like to bring microservices to more people to see the power of pattern matching, JSON messages, and small deployable services that limit the downtime of the entire platform and even flexibility of tech.

Abstract When we started Odd Networks we knew we had a blank slate to build our platform. Given that our platform was going to eventually support a lot of traffic and clients we knew we had to make sure it was able to scale accordingly and more importantly, easily, given our lean team. We started investigating the idea of microservices which would allows us to build and deploy smaller bits of our platform independently of each other. This seems like a monumental task because it meant building a "distributed system" with "eventual consistency". We learned a lot about this pattern from http://martinfowler.com/microservices/. Both terms just sound scary for a small team to take on. However, we found SenecaJS.org and with their approach to microservices and using pattern matching of plain JSON we felt like we had a great project to get us started.

Once we started digging into it we saw how easy it was to create these small laser focused services that we could have talk to each other with JSON. It was trivial to spin up a new service, deploy it connected to the same message bus as all the other services and have it join the conversation with each other. If one of those services was getting overwhelmed, not a problem, we would deploy a copy of that to the same network. Even choosing the common transport layer was trivial. SenecaJS abstracts that all and lets you choose whatever you want be it Amazon SQS, ZeroMQ, TCP, HTTP, or a mesh network.

Pattern matching has become such a nice piece of the platform as well. Being able to just send a message that is just JSON means in the future any of our services can change to Elixir, Go, you name it. As long as it can pattern match JSON it will seamlessly integrate. Pattern matching also gives us events as well. If Service A tells Service B to do something we send a message to indicate that. Transparently though, Service C can be listening to the same pattern and also do a job based on the message. Service A doesn't even need to know Service C exists. Once Service A joins the network it can automatically start sending messages to Service C without knowing its address.

Before using SenecaJS I was always put off trying to build a distributed system. It sounded too complex and overkill for any product I could think of. However, from all that I have learned it is not as complex as it seemed. It introduces some new challenges, but for us the pros outweighed the cons and has proven to be vital in the success of our product.

You can actually see the result of our platform powering a 24/7 poker network on all devices on the market https://www.pokercentral.com/find-us

Takeaway Understanding the power of smaller more focused services that can speak JSON really opens up the idea for choosing any tech that is right for the job.

Prerequisites Understanding of Node.js and communication protocols like TCP, HTTP, and message queues.

[edgarbjorntvedt]

Would really like to hear more about this

[blainsmith]

Thanks for the interest @edgarbjorntvedt! I am hoping I get to share the chance to talk about it!

[blainsmith]

I wouldn't even mind talking microservices in general outside of using Seneca too. The concepts are the same regardless of framework. I am really just using Seneca to show examples.