Thursday, March 24, 2011

Simply SaaS (Part 1)

This is part one of a multi part series where I will talk about what it means to develop and deliver a Software-as-a-Service application. I'll be trying to strike a balance between the technical aspects of bringing an app into the cloud and the advantages of using the SaaS approach as an Independent Software Vendor (ISV). I am NOT an expert in SaaS by any means...I'm writing this to educate myself and hopefully any reader that has the same curiosity. Your mileage may vary.

I think it's an understatement to say that the cloud computing term is overused. What does it really mean to deliver an application in the cloud? In recent years developers put together a web application or solution by marrying a database with a development framework and an application server resulting in a technology stack (e.g., LAMP, etc). Once the application was developed using these components it was deployed to a hosted environment or installed on premise to be part of a private enterprise. Ongoing maintenance for the application involved generating patches to fix bugs and supply enhancements. Sounds familiar and perhaps a little boring right? Around 1999 this guy, named Marc Benoiff took a sabbatical from his day job at Oracle (and by sabbatical I mean he was in Hawaii for 3 months and then in India "finding himself" for another 2 months) and started Salesforce.com. This, for historical purposes and to the best of my knowledge, was the start of the cloud buzz.

Marc wanted to offer easy to use enterprise software that didn't cost organizations an arm and a leg to implement and support. He did this by creating a pioneering CRM application that was nothing more than a web application / site that provided access via the Internet instead of the Intranet. Brilliant! Needless to say the application was a huge hit and later spawned the Platform-as-a-Service (PaaS) offering known as force.com.

To me, delivering a SaaS application seems like a smart move for an ISV. You have a low barrier to entry to get started, you can pass on that cost savings to customers, and you don't necessarily need to worry about supporting the infrastructure that runs your app at the end of the day. At a high level this seems like nirvana but you'll quickly find that it's difficult to understand what technologies you should be concerned with (as a developer) and how you will handle the subscriptions (as an ISV). I hope to fill in some of the blanks to developing and delivering a SaaS application by documenting the process I follow as I take an (albeit trivial) app from inception to delivery.

I'm a developer, what tools or frameworks exist to help migrate my project into the cloud?
First off there is a general distinction we need to make. SaaS is a type of software not a technology in particular. There exist a few "on demand" concepts that enable SaaS application developers. These concepts would be Infrastructure-as-a-Service (IaaS) and Platform-as-a-service (PaaS). Think of IaaS as Amazon EC2 - you get access to a hosted virtual machine where you can deploy your application. As your application grows and requires more resources, you can add more iron in your equation to get you that extra horse power. The application developer is still responsible for worrying about things like load balancing and clustering. An example of a PaaS would be force.com. If you haven't looked at this already it's worth signing up for the free developer account and poking around the documentation. Basically force.com allows developers to build apps with a domain specific language (DSL) known as APEX. You build your app using APEX and as you scale your app to customers you are charged a metered rate. Force.com also recently bought Heroku...this is a ruby on rails based PaaS. You build your app in rails, deploy it to the cloud using Heroku gem, and you are billed for your usage as your application scales to meet demand. There are too many PaaS offerings to mention in one post but hopefully you get the idea.

I'm an ISV what does it mean to build a cloud application?
Low barrier to entry for your customers. SaaS supports the idea of Multi-tenancy that allows you to co-mingle customer data (as long as the law doesn't prevent it) and therefore provides your customer with access with a push of a button. Customers pay for the software with a subscription so that they only get what the need instead of paying for countless licenses that ended collecting dust somewhere.

This is great but what if I already built my application? Do I need to re-develop or re-architect it?
Possibly. Apprenda provides a technology called SaaSGrid that can mostly eliminate that concern provided that you have an existing .NET application. SaaSGrid is advertised as an application framework that allows you to migrate your .NET application from a more traditional application service provider (ASP) model to a SaaS offering. The technology provides things like multi-tenancy so all you need to concentrate on is building your application like you normally would. In my opinion if you have a .NET web application that's worthy of the cloud or know .NET and want to build a new application, you should definitely give Apprenda a glance. You can download an express version that will allow you to install it on a server and see how the whole thing works. While I tend to be more of a Java / Ruby guy I definitely see the value in using something that's .NET based. Many enterprise grade SDK's (I'm thinking of ESRI since I'm a GIS geek) play nicely with .NET and maybe aren't fully featured for integration with other technologies like rails or a PaaS DSL such as APEX. This argument won't hold for forever but seems to be logical for the present.

In the next post I will talk about the application that I'm using as an example for this series and how it will benefit from an "on demand" delivery instead of shipped bits. Stay tuned!

No comments: