Thursday, November 8, 2012

What am I working on... deja vu

For the past year or so, I have been focusing on transforming our service and messaging technology.   Fortunately, I have been able to really role my sleeves up and dive deep into the technology.  Coming from my last company, this has been a welcome change.   At prior companies, technology evaluation meant lining up a group of vendors and picking the most compatible suitor.  In many instances, it felt like an arranged marriage where you really didn't know what you were getting into.  My current company has provided the opportunity to really understand the technology, its implications and how it fits the business goals.  As an architect, I couldn't be happier.   Okay, for the most part as there is always something to bitch about but all and all good.

In financial services, particularly around money movement and trading platforms, most things are done asynchronously.  Swipe your card at Wal-Mart, its asynchronous.  Go to the ATM for  some fast cash, its asynchronous.  Execute that trade on eTrade, its asynchronous.   Go to your nearest branch and deposit a check, clearly asynchronous.  In reality, most of us have a synchronous (request/reply) experience with our financial institutions but the implementation behind the experience is most likely asynchronous.  

With that in mind,  a lot of the focus is the messaging platforms that financial systems depend on.  How to scale, how to make them faster, how to make them more stable, etc.   The options have been around for a while in the likes of IBM MQ Series, TibcoRv, etc.  The main issue with these is that they are proprietary.  There is no common wire protocol, API or even a well defined interaction model.  As result, we all wrote wrappers to encapsulate the interaction or just dealt with it.   So, when posed with the same question in my new role, I ran back to mama per se.  However, the constraints were different. 

  • Strongly prefer Open Source
  • Cross language support; Java, C++, Python (No Cobol or Assembly!)
  • Extremely low latency
  • Flexible & extensible security model
  • Open interfaces & wire protocols
So, the usual suspects were drawn into the fray but a couple of new ones or not so new ones as well; ActiveMQ, RabbitMQ and Apache Qpid.  With different constraints, I was drawn to Apache Qpid which is where I have been spending a lot of my free R&D time.   

Funny part, I remember nearly this exact same conversation with Brian Stevens & Joe Ferrell at RedHat a few years back during an executive briefing.  So, guess its come full circle that I would be working on Qpid.  Or is it deja vu?

No comments:

Post a Comment