By Richard Seroter, Senior Product Manager. Find Richard on Twitter

It will surprise no one to say that Software-as-a-Service (SaaS) is a hot topic. Really hot. In 2010, Gartner reported that 95% of organizations are planning to grow or maintain their SaaS investment. According to the influential technology blog GigaOm, the valuation of SaaS companies is skyrocketing compared to more traditional enterprise software vendors. While most organizations are increasing their use of SaaS products, some are looking for ways to offer their own software in a SaaS delivery model. What does it mean to “SaaS your app”? This series of articles will walk through the considerations and techniques for creating (or converting) an application for a SaaS offering. In this first article, we will lay the foundation for the series by identifying the critical aspects of SaaS and what you should look for when planning and architecting your software.

Comparing Application Hosting vs. Software as a Service

Isn’t SaaS just a rebranding of the products and services offered by Application Service Provider (ASPs)? The answer is a resounding NO, but it’s easy to become confused when you find so many products with “cloud!” slapped on their label. To be fair, SaaS is an extension of the ideas introduced by ASPs, but there are fundamentals differences.

Let’s do a quick comparison between the two delivery models.

In essence, ASPs operate software environments for customers while SaaS vendors let you rent their software in a scalable, self-service environment.

SaaS Your App - Verify the Architecture

Before an application can be delivered in a SaaS style, it has to be evaluated for architectural readiness.

Stateless web servers. In order to cleanly scale horizontally and easily provision new machines, it’s critical to build web applications that don’t maintain any local state. The web servers should rely on some sort of shared database for their configuration. To truly offer a cloud-friendly application, then the architecture must support no-touch elasticity which can’t happen if you have web servers with local state.

No hard coded connections. If your application has web servers that has hard coded values (e.g. IP addresses) for database connection strings or server-to-server communication, you’ll have problems when you migrate your application to the cloud. These things can be tricky to trace, but you really want to make sure that each individual layer of your application can scale independently without breaking connections between the tiers.

Extensible data model. This comes into play if you foresee subscriber-specific customizations taking place. Should customers be able to extend existing data objects, add new ones, or apply unique validation logic? If so, then it makes sense to design the data repository in such a way that customer extensions can take place.

Multi-tenant support. This isn’t as straightforward as it may seem. One of the key principles associated with SaaS is putting multiple customers, or tenants, on a single server or software instance. The benefit of this model is that the software provider gains operational efficiencies because they don’t have to uniquely maintain each customer’s environment. That said, multi-tenancy could happen at multiple layers of your application. Three viable options include:

• Provision unique web applications and databases for each customer. While the underlying infrastructure may be shared among tenants, it is feasible to carve out unique application environments for each customer. The benefits include physical separation from other tenants (which may matter in some industries like healthcare) and the option to upgrade each tenant on their own schedule. This starts to blend back towards an ASP model, but well designed software coupled with a highly automated application provisioning process can still make this delivery model sustainable.
• Have customers share an application (version) but maintain their own unique databases. In this case, a single version of software is installed, but each customer configuration includes a reference to their own database. Here, physical data segmentation still exists and features like per-customer encryption or direct database tunneling are possible, but overall application maintenance is simpler.
• Finally, you could use a Salesforce.com-like model where all tenants share both an application version AND database. Data is logical separated, but physical co-mingled.

Surfaced configurations. If someone is expected to rent your software as-is with absolutely no changes, then there’s limited need to expose user-driven configuration points. However, if you want customers to have the flexibility to extend the data model, change the application look-and-feel, define organization-specific workflows and set up security users/groups, all in a self-service fashion, then it will be key to design your software to support user-driven configuration changes. A critical principle of SaaS is “self service” and not requiring users to call up a service provider in order to implement any changes. By exposing supported, user-driven configuration in your architecture, you make self-service a reality and keep application support costs down.

APIs. If you aren’t offering APIs, then you aren’t offering a real cloud application. Applications without APIs become siloed and more difficult to integration with or manage from afar. Good API design requires work, but the payoff is immense for the customers of the SaaS application.

Thoughtful security architecture. Clearly security is a major consideration when building an application that may be “shared” by hosts of diverse users. In this case, “security” refers to items such as how you identify (authenticate) and assign permissions (authorize) to users, encrypting data at rest, securing data in transmit, providing audit trails and more. Ideally, your application allows Single Sign On (SSO) through a standard mechanism like SAML which then requires one less password for users to create and maintain.

Integration with other cloud platforms. While not a necessity, it’s powerful when cloud applications embrace other cloud applications. Would users of your SaaS application benefit from integration with Google Docs or Microsoft’s SharePoint Online? What about providing a federated identity story using a user’s Facebook or Twitter ID?

While not exhaustive, this list of focus areas should help you identify where you may want to revisit the architecture of the application before offering it up as a SaaS solution.

SaaS Your App - Find the Hosting Environment

So you have a great SaaS-friendly application architecture. Congrats. How do you deploy it in a way that maximizes reliability while minimizing support costs? You will want to find a mature Infrastructure-as-a-Service (IaaS) provider with a mature, elastic environment that has the following capability areas.

Metered Billing. Pay-as-you-go is a key aspect of SaaS software and you want to make sure that you can easily capture usage metrics that can factor into the monthly cost. While you may simply charge a flat price per application user (and forego chargebacks for individual infrastructure costs such as storage, bandwidth and CPU cycles), it will be useful for your hosting provider to show you a clean breakdown of the costs associated with your SaaS application.

Quick horizontal/vertical scale. Sometimes you need more horsepower for a given application server and increasing RAM or CPU makes sense. But recall that “cloud” is associated with easy horizontal scale of commodity hardware. The platform beneath your SaaS application needs to be able to rapidly scale both automatically and through a self-service interface.

Access to web-based installers. Instead of leveraging virtual machine snapshots and rehydrating them when you need more servers, consider building the servers automatically when scaling is required. If you use VM snapshots, you still have to deal with patching and managing them so that they are usable when you need them. Instead, if you have access to the application source code (or web installers for packaged software), you can use any number of tools to quickly and reliably build new servers.

Active monitoring. In order to be able to support a large number of customers on your application, you’ll need to be able to quickly respond to the inevitable issues that arise with the hardware or software. Your SaaS hosting platform needs to be vigorously watching the health of its servers and not only be able to notify you of problems, but also be able to perform prescribed responses (e.g. reboot server, take offending server offline, add more servers).

Global deployment options. One value of SaaS software is that it’s on the public internet! This means that the application may be accessed by users across the globe. If there’s a chance that your SaaS application would be used by global users, consider hosting providers that have an international presence and support provisioning across global data centers.

One-click provisioning. A cloud application architecture may not be simple. Your software may have numerous front end web servers, a web service layer, distributed database system, batch job processing servers and more. If possible, try and find an IaaS provider who allows for “templating” a solution stack and supports a single-click deployment option.

Robust backup and restore options. Disasters happen. Even the best cloud environment experience unexpected issues that can take down an entire data center. You want to make sure that your application data can be readily (and regularly) persisted in a location outside the primary data center. Disaster recovery planning is serious business and ideally, your hosting partner has lots of experience in this arena and can provide both the thought leadership and tools that make this a reliable capability.

A well-architectured application that is stuck in a sub-par hosting environment will quickly result in customers fleeing your service. Unless your service provides unparalleled (and necessary) functionality, the customers will simply flock to competitor solutions that exist on a more reliable foundation.

SaaS Your App - Provide Registration, Management and Billing Services

If the application is well built, and hosted on world-class infrastructure, all that’s left is to make it simple for customers to consume it. In order to build a maintainable platform that requires minimal manual intervention, you should address the following areas.

Sign up pages. This may seem obvious, but you will want to carefully construct a straightforward way for customers to quickly get started with your software. If your sign up process requires someone to call a phone number, you’re doing it wrong.

Management dashboard. Earlier we discussed the value of surfacing application configuration values that allow the customer to make certain changes to the appearance or functionality of the application. Your customer shouldn’t have to make these changes by executing a series of shell scripts or REST API calls, but rather, they must have an effortless way to view and edit configurable values. Likewise, a good management dashboard also exposes key capabilities like security role definitions (and user provisioning) and billing services.

Data import/export services. Congrats, someone decided to use your SaaS product. Now how are they going to migrate their old data into it? If your answer is “key it in by hand,” then you have already started off on the wrong foot. Data import tools make it possible to start using an application right away, and, create some instant data gravity along the way. Just as important as supporting easy data import capabilities, you need to offer a way to pull data out of your application. While the natural inclination may be to lock people into your platform, you’re both harming your customer AND making simple integration scenarios harder.

Spend some time thinking about how you can make it easy for customers (or potential customers) to evaluate, buy and get started quickly with your application.

What’s Next

This first article is meant to get your mind rolling and set up the conversation for the subsequent articles in this series. Coming up, we’ll talk about how you can use Tier 3’s world class environment to quickly create blueprints of your SaaS-ready applications and deploy them to a robust environment. Read the next article in the series: Blueprinting your application.