I've been brainstorming about maximum efficiency, performance, and scalability in regards to web application frameworks; none of them really seem up to the task. After reading a stackoverflow.com post about ZeroMQ (www.zeromq.org), it got me thinking about distribution of specific tasks or concepts to "mini-apps" and how that could be done.
The following mindmap shows how I've broken up a typical web application into its component concepts.
By using a technology like ZeroMQ, each concept could exchange data loosely with another. For example, the Web Application could send a message requesting an SEO header and the Tracking Concept could do something with that message and trigger a Google Analytics event, the Monitoring Concept could intercept the Google Analytics event and log it, then the Reporting Concept could ask the Monitoring Concept about its latest log and process a report. All this could happen asynchronously and in the background where even the Web Application doesn't know everything that's going on.
This idea is completely language and location agnostic. ZeroMQ can connect nearly any language "mini-app" to any other language. Let's say you have a legacy Java application and your current team of developers knows python or ruby better. Your developers could wrap the functions you want accessed in the Java application with ZeroMQ and connect using python or ruby. Also, lets say you want to leverage the processing power of many distributed computers across the United States, located in multiple colo facilities. You could run mini-apps in all the locations and as long as they have a network connection, they can talk to each other.
Imaging using a message queue to build an interface between a C#.NET 4.0 application maintained by an outside vendor using Lua or python without worrying about dlls or COM wrappers.
I am going to explore this idea a little further this weekend. Maybe there'll be a new GitHub project started using this idea... maybe...
1 comment:
Scott, yes. You'll find that the grouping of concepts to tasks may change, but this approach lets you design an elastic architecture that will scale from 1 to 1000's of cores. As you've pointed out it's language neutral and you can implement different parts in different languages depending on need.
Post a Comment