If you recall the online/offline debates 5-6 years back when SOA (Service Oriented Architecture) was the buzzword around Silicon Valley, at least I were of the opinion that SOA was more of a marketing gimmick than a technology leap. Most of the money marketing SOA was put by tech giants like IBM, Microsoft, TIBCO, Amazon etc. Though I still believe that SOA classifies as a philosophy of Software Architecturing, am I becoming a fan every passing day. I remember the first lesson of programming I had twelve years back ‘not to re-invent the wheel’. SOA is a perfect example of why ‘reusing the wheel’ is a great idea, engineering-wise and business-wise.
We were recently challenged at work to design and develop a next generation multi-media messaging system for a fortune corporate. The requirements were very interesting. Starting with cross platform support i.e. iPhone, Andriod, BB, WP7 and Web, the system was also required to record live audio and video and send as real-time attachments. The diaspora of media support in different mobile platforms is quite big thus the need of inter-format media encoding. Additional features were PUSH notifications upon message receive, and coupling with client’s proprietary LDAP. We planned a stage-wise release that is starting from a group of hundred users to acceptance-test the system, we targetted a 2nd release to 10K users and then eventually to full scale i.e. 30K users. the anticipated load on the system was 30 TPS resulting from 4-5 new message check calls from every user per second.
During the design phase of the system, we faced the question of choosing between non-SOA approach (do-it-yourself) versus a services based architecture for features like media encoding, PUSH messages and file storage. Though the decision of not doing-it-yourself means lesser control, lesser customization, dependency on a third company but thanks to SOA buzz created many years ago, plenty of smart people have founded SAAS companies that cater to most users needs of media encoding, storage and notifications. So our engineering team and client decided smartly and chose the SOA approach. We evaluated different options and settled with Encoding.com for media encoding, UrbanAship for notifications and S3 for media storage. One of the reason of choosing Encoding.com was its capability of solid integration with S3 storage.
The decision of following an SOA approach helped us in many ways. First and far-most we saved so much time. Rather setting up our own server for solutions like ffmpeg and then handling scaling and reliability, we shipped all the media encoding burden on encoding.com’s shoulders. Although they do have some scalability and video rotation issues but overall they have solid services to offer. PUSH notifications are generally not fully relied upon, but UrbanAship has been pretty solid delivering notifications. As I think of the time and effort we have saved in building our next generation messaging system by choosing an SOA architecture, its quite amazing. Not tp mention the savings in cost of development for the client!
As we move forward and add new interesting features to our system, we want to build upon the already ‘handy’ SOA architecture. Our next targets are addition of great Analytics for system usage. We have boiled down the list of available services to Google Analytics and Flurry. The range of analysis provided by both are quite interesting and we are inclined to use one of these SAAS providers than building our own analytics solution.
