Announcements

NAP::Messaging – glue and policies for interacting with ActiveMQ

As part of our service oriented architecture, our Perl applications send messages over ActiveMQ; a few of them also consume those messages and act on them.

All these consumer applications are based on Catalyst. Initially, we used Catalyst::Engine::Stomp and a rather complicated set of in-house libraries to wrap it.

Those in-house libraries have, in time, grown to incorporate more and more responsibilities, including testing, logging, message serialisation, plugin loading… it was time to break them apart and write something cleaner.

Continue reading

Architecture

Net-A-Sparkle

At NAP, our code bases have organically grown as we’ve added more capabilities in order to support the rapid growth of our business.

From Monolithic to Microservices

The microservices architecture is an alternative pattern that addresses the limitations of the monolithic architecture. With Microservices the ambition is to be small. The flexibility that comes from Microservices is driven largely because of their size, so to keep these benefits we need to fight against the urge to add more and more lines of code.

Continue reading

Architecture

Isolate and Test

Diving into a new technology, language, tool or architecture is always fun. At least for the first day or so of playing around with it.

Fairly soon, you and your fellow pioneers will decide on building this amazing new thing with this even more awesome new technology that will provide the business with so many cool features that you really think a plaque with your name at the entrance of the office is the minimum they can do to thank you.

Continue reading

Architecture

When Latency Strikes

As a developer-by-nature, I’ve been fortunate not have to understand
global networking, and the effect of the speed of light, in any great detail.
I’ve been in the lucky position where I have been able to write code that
“does what it’s supposed to” without much thought to global server
positioning.

This changed quickly and suddenly for me towards the end of 2012.

Continue reading

Architecture

Partial deployment with feature switches

What

The idea of feature switches is neither new nor complicated; devop’s darlings Etsy and Flickr have been talking about them in the context of continuous deployment for a while.

Essentially, what it boils down to is merging part-complete features into your master code branch before the work is ready for some, or all, users. These features are then kept “in the dark” until such time as the feature is completely ready, when it’s switched on for all to see.

Continue reading

Architecture

NAP::policy: an introduction

What is NAP::policy?

It’s a pragma, or a “policy” module, to help people at NAP write more
uniform code.

The module itself is equivalent to a series of use statements,
that are considered “a good idea” for our needs.

The distribution also contains a few more “good idea” modules, that
are not tied to any particular application, but can help developers.

Continue reading

Architecture

Catalyst::Engine::Stomp after 0.16

We use Catalyst::Engine::Stomp for all our ActiveMQ consumers. It works rather well, and (especially with the addition of our Net::ActiveMQ) makes working with queues mostly painless.

But there is always room for improvement. There were two main missing pieces:

  1. generalisation of the subscriptions and inputs, from “a queue per
    controller” to “one subscription per controller”
  2. dispatching to an action based on the JMSType header, instead
    of the ad-hoc @type body attribute we have been employing

This is the story of how I implemented both.

Continue reading