Well, since Countly Community Edition is open source we don't offer any SaaS from our server just yet. Countly Cloud will be the SaaS solution and I believe a micro instance won't do any good after the first week :) But a micro instance is powerful enough to host a website or a blog, even to open up your service for private beta.
I've been mulling over whether to take a dive into EC2 to launch a public beta actually so thanks for your comment. I've been trying to decide between EC2 or getting another 512 Linode to start. I think I will go for EC2 now mostly just to learn a few new skills and sharpen some old ones. Thanks.
Correlating the data with marketing efforts would be nice and definitely provide more value but the apps we analyzed have little to no marketing budget (although there are some popular ones). This analysis actually shows the importance of marketing and promotion efforts since without them this is how an app ends up.
We will be doing similar analysis in the following weeks and hopefully will provide more detailed insights.
Yeah its just App Store. We didn't really have a chance to bundle such stats for Android apps yet but I'm pretty sure the results will be pretty similar.
The main point of my blog post was to show our positive experience by using something new to build something new. I'm not talking about renewing your existing backend, changing your perfect PHP implementation to Node.js, I'm talking about our story of choosing a platform for our new project and suggesting people out there to be open to trying new platforms according to their needs. I know the feeling, I did the same before. I have used PHP for projects that I had better alternatives for, just because it felt comfortable and hassle-free.
In our case we have tried several other platforms/languages and the best fit was Node.js for us. “Do the research, be a developer not just an X language developer” would probably sum up my whole point.
I think there was some really awesome benefits of nodejs that are worth mentioning. I recently finished migrating our old .NET API to NodeJS and found:
1) persistant connections, we deal with massive concurrency and remote connections to just about anything external (even on same network) could be saturated and overwhelmed so quickly
2) pseudo-caching data in the background, things like game configuration etc we just keep loading over and over on an interval so wherever possible we just have whole mongo collections and db tables sitting there in ram always fairly fresh
3) mirroring our application-wide redis cache locally on each server in the background so whenever we do get a cache hit it's insanely fast
These are probably the coolest things I found moving our analytics api to nodejs.
You can take a look at http://count.ly if you are looking for an open source solution. It has a Node.js + MongoDB server and Android & iOS SDKs. (Yes I'm the developer)
It only matters that the client is open source (note I didn't say free software). This is so you can read the code and be proactive about issues in it. For example the mixpanel client for Android caused one thread to be created whose sole purpose was to fire a timer event every 60 seconds, which was used in a second thread to see if there was any work to do. It is a lot easier to figure out stuff like that is happening from the source than to try and work out who is responsible for extra threads showing up in the debugger. If there is a suitable license then you can at least modify and redistribute the changed code.
We do actually do our import and custom processing in MongoDB, so that side is covered.
