In the last post about Cerebrata, I spoke about our first product Omega.SDSClient and how in a period of 4 months that product completed it’s lifecyle. You can read that post here: https://gauravmantri.com/2012/06/05/cerebrata-story-omega-sdsclient/.
In the post, I will continue from where we left in the last post and talk about the next product we built. As I mentioned in my previous post, we were given heads up about the future of Sql Data Services and how Microsoft canned that product in favor of what is now known as SQL Azure (or Azure SQL Databases). By now I had a team of 6 – 8 people and we had to do something so we thought why now do something with Windows Azure Storage. Just with that notion, we started working on our next product.
Why Windows Azure?
Before I talk about our next product, I do want to mention about why we chose to build products for Windows Azure platform. A lot of folks asked me this question (surprisingly from inside Microsoft as well): Why did you choose to build a product on a platform like Windows Azure. Why didn’t you choose something like Amazon for example. Diplomatic (and full or crap) answer to this question would be something like “Early on we realized that Windows Azure is going to be really big and we wanted to make sure we are a part of it .. Blah Blah Blah” but to be very honest, we did it because we didn’t have any other option. We didn’t do any due diligence or cost-benefit analysis as to whether we should build for Windows Azure or not. We just went straight at it. Given the time we got involved with Windows Azure (it was not even in beta at that time), I’m sure that if we had done any thinking over it we would not have built anything. I think now I can proudly say that we took a gamble and it paid off. Having said that, if one were to ask me this question today my answer would be totally different. The way Windows Azure has evolved since it started out is simply amazing and today it is quite compelling platform for anybody who is thinking about either building products for a cloud platform or thinking about “Cloudifying” their applications.
As far as building something for Amazon platform was concerned, we stayed away from it on purpose. The primary reason was that even then (this was early 2009) there were a lot of players in that market and there were a number of tools (both commercial and open source) available for managing Amazon storage (S3 at that time). We did look at Google as well but I believe only thing supported by Google at that time was either Python or Java which simply was a show stopper for us.
Initial Development
Anyways, coming back to developing the product. Based on the lessons learnt while building Omega.SDSClient, we released the first version of the product in a month’s time with just the functionality to manage Windows Azure Table Storage. The application was built using Silverlight 2 and was made available to all users free of cost (more about that later). This was the 1st product which allowed users to manage the tables and entities (create/update/delete etc.). Again, for promoting the product we depended on MSDN forums. Users started using it and feedback started pouring in. We iterated fast on that feedback, fixed bugs and started adding new features.
In the next iteration, we added support for queues and messages and then in the iteration after that we added support for blobs. All-in-all we worked on that product for about 3 months or so and then stopped working on this product.
Why We Stopped Working On This Product?
There were many reasons why we stopped working on this product.
Harnessing the Power of Desktop
The main reason for that was this product was a browser-based product and given the technology available at that time (it was built in Silverlight 2 and OOB experience in Silverlight came later on) plus some other features that wanted to include in the product, we favored having a desktop application instead of a browser-based application. Our assumption was that we would need an application which would harness the power of desktop. Silverlight 2 was just not there at that time.
Failure to Understand Commercialization
Another main reason for going for a desktop based application instead of continuing with this browser-based application was I completely failed to understand how a browser-based application can be commercialized. The application was free to use and there were a few things I knew that in order for me to commercialize this application, I would need to:
- Offer the application as a Software-as-a-Service (SaaS) application.
- Host it in Windows Azure where I could make use of elasticity and on-demand scalability offered by Windows Azure.
What I didn’t know and thought a lot about was how am I going to charge the users for using this application. I was thinking quite small and wondered about what happens if somebody uses more than other users and how am I going to charge them accordingly. Whenever somebody asked me about it, I ended up putting the blame on the platform itself for not providing a billing/metering API which I could tap into and charge users on exact usage. I continued to think so till I watched a presentation from Steve Marx at TechEd this year where he talked about building SaaS solutions on Windows Azure and that kind of opened my eyes (but then it was kind of late, at least for this application).
Plus it was rather easier to commercialize desktop applications (everybody else was doing it). So weighing in all these things, we decided to build a desktop application for managing Windows Azure Storage.
Demise of Cloud Storage Studio/e
For the reasons stated above, we stopped working on the product after 4 months into development. However we didn’t shut it down for next 2 years. People were still using that application. We finally pulled the plug on this product just before Red Gate acquired us. Come to think about it, we should have done it a lot sooner. Primary reason is that even though the product was offered free of cost, since it was not upgraded we were actually doing disservice to both our users and the platform. We built this product while Windows Azure was in CTP and never upgraded it while the platform evolved a lot. The users who were exclusively using our products never really benefitted from those enhancements because of this (thus disservice to the users). Also to the same users, they never knew about the new features of the platform (this disservice to the platform). I guess, when you’re building an application for an evolving platform it is utmost important that your application keep up with the platform.
Interestingly when we first released this application, we named it Cloud Storage Studio. Once we released the desktop version, we renamed this product as Cloud Storage Studio/e (where “/e” stood for everywhere which we borrowed heavily from Microsoft where in the earlier days they used to call Silverlight as WPF/e).
Lessons Learned
One important thing we learnt apart from the things I mentioned in my previous post is that it is important to keep moving and not getting stuck with just one thing. We failed to realize the commercialization aspects of this application but we moved on to something which we thought we could commercialize.
Summary
So this was the story of our Cloud Storage Studio/e product which paved the way for other products for managing Windows Azure. In the next few posts, I’m going to talk about Cloud Storage Studio which kind of made us famous in the Windows Azure community 
.
So Long and Stay Tuned!!!
