Nick Nance2014-12-03T16:02:45+00:00http://nnance.meNick Nancenance.nick@gmail.comReactive Microservice Architecture in Node2014-12-01T00:00:00+00:00http://nnance.me/2014/12/01/reactive-architecture<p><img src="/public/react.jpg" alt=""></p>
<p>This is the start of what I expect to be several posts on the subject of applying Node in a reactive microservice architecture. I have found that by building single purpose node modules as microservices that live on a scalable message queue, I am able to piece together interesting applications simply as a result of how I deploy and configure these services. In this series of articles I will provide code and deployment examples that show this architecture in action.</p>
<!--more-->
<h2>Inspiration</h2>
<p>For years I have been working at SAAS companies as a software architect building applications that integrate many other SAAS services and internal platforms. Over this time, my team and I have run into many challenges knitting these things together in a way that makes a system:</p>
<ul>
<li>Reliable - In the face of outages / slow responses from external services</li>
<li>Responsive - Provide a user experience that minimizes wait time</li>
<li>Scalable - Available to thousands of customers on a common infrastructure</li>
</ul>
<p>I have recently been inspired by a combination of articles that have led to my initial thoughts on this architecture. Some of these articles include:</p>
<ul>
<li><a href="http://www.reactivemanifesto.org/">The reactive manifesto</a></li>
<li><a href="http://eventuallyconsistent.net/2013/08/12/messaging-as-a-programming-model-part-1/">Messaging as a programming model</a></li>
<li><a href="http://martinfowler.com/articles/microservices.html">Microservices</a></li>
</ul>
<p>I have also been a long time Java and Javascript developer and over the last couple of years I have fallen in love with the power and simplicity of building modules in Javascript on Node. As I have worked with Node, I have realized that the small footprint of Node is a fantastic use for an architecture that consists of tens of hundreds of microservices deployed as an application.</p>
<h2>Microservices</h2>
<p>Microservices are very small services running in their own process built around business capabilities and independently deployable by fully automated deployment systems. There are a few significant properties of Microservices that apply to this architecture:</p>
<ul>
<li><p>Componentized - Microservices should be very small with a single responsibility and be out of process. This is very different from a typical library where components are assembled in process.</p></li>
<li><p>Message Driven - Microservices should be driven by asynchronous messaging where the intelligence is left up to the microservice implementation and not provided by the messaging fabric</p></li>
<li><p>Decentralized Data - Each service should manage its own database, either different instances of the same database technology, or entirely different database systems. You can think of this model as the OO concept of data encapsulation. No service can access the database of another service.</p></li>
</ul>
<h2>Message Queue</h2>
<p>When combining a fast and reliable message queue with the microservices architecture, the individual components of the entire solution can be decoupled. The Reactive Microservices architecture relies on asynchronous message-passing to establish a boundary between services that ensures loose coupling, isolation, and location transparency.</p>
<p>The message queue should provide messaging over a lightweight message bus. The infrastructure chosen is typically dumb (i.e., it acts as a message router only) - simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric - the smarts still live in the end points that are producing and consuming messages; in the services.</p>
<h2>Conclusion</h2>
<p>By building these single purpose microservices that simply respond to messages on a message queue, the application can be extremely decoupled and the individual modules can be built without any concern for the expected architecture. This allows application architects to work with DevOps engineers to provide a new solution by simply deploying and configuring a set of services. It provides a LEGO-style application assembly similar to the way that UI engineering often uses components to construct a user interface.</p>
<p>This will change the role DevOps plays in the application architecture. Historically DevOps have been focused on how to deploy load balancers, web servers, application containers and databases in a way that allows the application to scale reliably. Now DevOps can take these pre-constructed microservices and deploy them in many different ways to provide many different application solutions. This allows the actual solution engineering to occur at deployment time instead of at development time.</p>
<h2>Next Steps</h2>
<p>Now that we have a foundation established, in my next article I will provide some microservice code examples followed by some deployment examples that will bring this all together in some basic applications.</p>
Introducing Backbone Composer2014-11-24T00:00:00+00:00http://nnance.me/2014/11/24/introducing-backbone-composer<p><img src="/public/projects/backbone-composer.png" alt=""></p>
<p>You're probably asking yourself why would anyone be releasing a new plugin for managing <a href="http://backbonejs.org">Backbone</a> views. Especially now that Backbone is no longer in vogue. Well, in short, I am still a strong supporter of Backbone. I believe in it's minimal unopionated philosophy. I prefer frameworks which give each project the most flexibility possible while providing a minimal application structure and utility. </p>
<!--more-->
<p>As a software architect for many different projects, I have been responsible for making technology decisions as it applies to the software stack. I have selected to work with everything from very large frameworks <a href="http://www.sencha.com/products/extjs/">ExtJS</a> to minimal frameworks like Backbone. As a result, I have come to appreciate the value in flexibility that minimum frameworks provide. </p>
<p>With this being said, Backbone provides you with many ways to shoot yourself in the foot. One of them is creating memory leaks in a Backbone application as a result of composing and destroying views. When I searched for a simple solution to this problem I couldn't seem to find something that fit my needs. This resulted in the creation Backbbone.Composer. Which follows in the footsteps of Backbone and provides a minimal approach to manage views and subviews. It also provides a default rendering implementation just to help cut down on bowler plate code.</p>
<p>Composer can be used in whole or in parts. If you think you might be interested in using this plugin, I have several articles to help you get started:</p>
<ul>
<li><a href="https://github.com/nnance/backbone-composer/wiki/usage">Usage Documentation</a></li>
<li><a href="http://slides.com/nicknance/composer/">Slide Presentation</a></li>
<li><a href="https://github.com/nnance/backbone-composer/wiki/api">API</a></li>
</ul>
<p>If you find this plugin useful please star the <a href="https://github.com/nnance/backbone-composer">Github Project</a>. Or better yet <a href="https://github.com/nnance/backbone-composer">fork it</a> and contribute.</p>