Ever since I took some very interesting classes about parallel computing (thanks to Dr Clemens Grelck) I am interested in high-performance and low latency computations. Unfortunately, most of the topics back then were academical as the there was only limited access to parallel computers and affordable multi-core (desktop) processors were far from being available.
But nowadays things look a bit different ...
As I am always in search for interesting problems in the ecommerce domain, I recently found myself asking the question: why do most of our products process inbound shop requests in a sequential manner? While executing these calls, precious resources are being blocked since the application awaits a response to its query. So, is there a serious reason not to switch from synch to async non-blocking communication and - beside that - apply some of my previously academical knowledge in a beloved field?
In order to answer that question, I started a little open-source project called iServices which is available on GitHub and actually serves as repo for my own proof-of-concept implementation and further ideas on that topic.
At its core the platform is based on AKKA and provides an ecommerce specific runtime on top it (well, actually it is ecommerce driven, but we will see where the road leads to ;-)). It makes use of functional interfaces and functional messages being passed around. The whole platform is stateless and thus highly scalable to serve large numbers of parallel messages.
One of the major reasons to switch the underlying communication model is to enhance the use of available hardware resources which in turn reduces operational costs compared to sync'ed solutions when it comes to constantly rising number of requests. As the retail market always is in search of ways to save money and increase the margin, this project is a try to proof that the demand can be supported by such an architecture.
But each coin has two sides .... getting a sync'ed application mastered by the developers as well as the application management is much easier than the same applied to an asynchronous solution. The reasons are complex communication structures and information flow behavior that sometimes might seem arbitrary.
The next blog entry will discuss whether to let the platform define functional processes or provide these to the messages and let the platform just react on that.
