SaaS: All PaaS are Not Created Equal

We’ve given a couple of webinars recently with our partners Apprenda (archived copy here) and OpSource focused on the key issues ISVs need to consider when developing a SaaS product. One of the areas we covered that received a lot of interest was “Platform as a Service” – PaaS and what it can bring to a SaaS product development project.

Let me start out by saying that in the fog of high tech marketing hype – a great number of products are described as “platforms” for SaaS development. I’m not going to try to parse which specific products are or are not “really” platforms – it is too easy to get tied up in semantics and still not reach useful conclusions. In this article, I’m going to break down some of the services that are often called platforms and put them in a SaaS context.

First – let’s define what functions you must perform – somehow – to effectively provide a software application as a service across the Internet:

• Pricing – A pricing engine or methodology must provide accurate, consistent pricing. In order to be really useful the engine or service should be flexible and allow for changes in the pricing system to accommodate new services or promotions.
• Billing & Payment Processing – Because SaaS is generally based on a recurring payment for services, a system or engine needs to be provided to bill clients and process payments. If there are elements of the service that are usage or transaction based, a part of the application needs to be dedicated to measuring and recording those factors.
• Tenant & Subscription Management - Each client account and the services they subscribe to along with their account status needs to be managed and linked to billing and payment processing.
• Service Provisioning – As each new tenant is added to the service, their “instance” needs to be provisioned. How this is accomplished varies a great deal and depends on the “maturity” of the service offering.
• Usage & Performance Monitoring – This is a very broad category of functionality that spans everything from monitoring individual user activities to the infrastructure that underpins the service. It should also include the accumulation of the raw data that will allow metrics to be derived for operations management.
• Subscriber Management & Self-Service – Each tenant should have ways of modifying their subscription, adding users, changing user roles and monitoring their current usage.

We sometimes refer to these functions as “SaaS Plumbing” because they are operationally necessary regardless of the business rules and expertise that defines your specific product. Of course, the best case is for all of this to be handled within the application “stack” in more or less of an automated fashion. In addition, a true multitenant architecture addresses these issues in the context of a single application instance. To develop a SaaS application that includes these functions in a multenant architecture typically takes from 20 to 50% of the whole development effort. If you do not want to incur this overhead in your application, you have two choices – do some or all of the work manually or use some type of service that provides the functionality for you.

With this background, the basis for the various services and platforms that are available to SaaS developers begins to fall into various levels of functionality and value. To help separate the “wheat from the chaff” a little further – let’s consider what the true, multitenant SaaS “stack” looks like:

The layers of the stack include:

• Infrastructure - Network, Servers, Storage, Load Balancing, etc.
• Technology Stack – OS (Windows, Linux, etc), Database, Application Environment (.NET, Ruby, PHP, etc) and associated services.
• SaaS Functionality – The “SaaS Plumbing” and services outlined above.
• Application Logic – The core business rules and functionality of the service to tenants.

With this common understanding of the SaaS stack, we can start to break down platforms and services for SaaS according to the layer(s) of the stack they address.

Most “platforms” are common to all application development. These address infrastructure and technology stack layers in one way or another. A common example would be something like Rackspace Managed Hosting. A platform in this category can include anything from a single dedicated server to a virtualized cluster, along with the OS, environment, database, reporting and monitoring that application installations typically require. Depending on the services the provider offers and you select, these platforms can greatly reduce the overhead in infrastructure and server deployment. They can improve reliability and provide development environments that lower development effort and improve application reliability. But - they do not specifically address the functionality that is required to operate a SaaS application.

This is where we start to run into problems…

The marketing for most products described as “PaaS” for SaaS today includes some combination of the infrastructure and technology levels of the stack and quite often impacts the way the application logic is expressed. They rarely address multitenant architecture or any of the SaaS functionality that impacts the operational needs of your service. Depending on how they are configured, they can often represent a certain amount of risk through “lock-in” to their service. A recent example of this is the Coghead system which provided the infrastructure and deployment services but in the process provided a development environment that was unique to itself and hard to break away from when the service began to close. These factors don’t lessen the advantages of these platforms, but they do shed some light on their utility for SaaS development specifically. They can be invaluable in the SaaS stack but it is critical to assess up front how they will impact service costs, risk and what they leave on the table that still needs to be developed.

At this time, finding a more complete stack is still a bit of a challenge. Apprenda’s SaaSGrid, Force.Com and Zoho Creator are some of the platforms that in one way or another directly address SaaS. Each has its own pluses and minuses in terms of the functionality they provide and the impact they have on application development. Beyond those, you can use services that address SaaS functionality on top of one of the more general application platforms. This brings on another level of risk – you are now piling together the general platform and perhaps services from several other sources – but this is not uncommon in eCommerce or business-to-business applications so you’re not really breaking new ground if you have experience developing applications for the Internet. Each service addresses a specific range of functionality and again – you need to go back to the list of SaaS functionality to see what you are getting in return for the cost and risk. A good place to start is the SaaS Showplace.

In addition, there are hosting providers – like OpSource – that provide a mix of services for SaaS applications as a part of or on top of their infrastructure. This type of offering lowers the risk because they are centrally controlled and generally provided across the data center instead of across the Internet.

In truth however, there is no PaaS that will addresses all the needs of a specific SaaS operation but – we do find repeatedly that using services and platforms allows the product team to focus on the value features of an application, reduces the time-to-market and costs of development. Assessing what is needed and what is of most value is necessary in the front end of every project and quite often the hardest thing to explain to clients until they get into the “plumbing” themselves. Making the decisions necessary takes planning and consideration, but re-architecting a service after it is on the market is – as anyone who has tried it can tell you – not something you “want” to do without serious pain to prod you.

Follow Me on Twitter