Image: Looking at the results of Phil Wainewright’s PaaS survey, 10% voted for the DIY approach. Maybe this is a case of what they’d like to do, and not what they should be doing?

In part one of this article I introduced Phil Wainewright’s five layer PaaS model.

Phil asked readers to say which layer they would prefer to use for building a SaaS application. Readers had cast 173 votes by May 15th.

Let’s work though these results and see what they mean for ISVs moving to SaaS.

Layer 1: Do-it-yourself (10%)

At the lowest of the five PaaS layers you build your applications with whatever tools and architecture you want. You select, buy and run the hardware to support your SaaS solution.

Perhaps the 10% is because readers said what they would prefer to do; not what they should do?

Geeks like to play with technology! It seems there are still some who think setting-up racks of servers is a good use of their time.

Facebook can borrow USD100M to buy 40,000 servers.

Salesforce.com can invest tens of millions to run their data centres.

You can’t, however, so forget about it right now.

Layer 2: Managed hosting (18%)

In the second PaaS layer you have full software control, but leave the hardware to a specialist hosting provider. They make some of the hardware decisions, but you are still responsible for most of the technical decisions.

18% is high for this low-level PaaS layer. This could be because the temptation is to buy hosting and offer your on-premise application as a SaaS solution.

The managed hosting providers encourage you to think that migrating your on-premise application to SaaS is a good idea. They are moving quickly from offering commodity cage and pipes and adding services such as security and billing.

Even Sun encourages you to go this route with their recent Solaris On Demand offer.

The new grid-based hosting environments make it easier to provision virtual services and storage. This way you can run multiple instances of your on-premise application; one for each tenant.

This is a quick way to offer something, but there is a critical problem with taking this approach.

You have to be 16 times more efficient

You can probably run an adapted version of your on-premise application, but can you make any money with this approach?

There is a big risk your costs will explode as each new tenant comes on-board. An article from Bob Warfield’s SmoothSpan blog makes this point well.

Assume:

• your annual subscription is about the same as your on-premise licence costs for one year
• your on-premise customers have a 4:1 ratio for the hardware, software and support costs to run your application
• your cost of goods sold must not exceed 25% of your subscription price to make a profit

If you offer your on-premise application as a SaaS solution your costs must be 16 times lower!

If you do not achieve this factor of 16 then you will make a loss with each user. The more tenants you have, the worse it gets. That is not how SaaS should work.

Can you run your on-premise application as a SaaS solution 16 times more efficiently than your on-premise customers?

To be honest, I have my doubts.

Too many application and database instances

Using a managed hosting provider for the application is a better idea that having your own hardware. Even so, your costs will explode as you did not design your on-premise application for SaaS.

Without multitenant support you will need far too many application and database instances running for any given tenant workload. Managed hosting providers price by instance, so this is wasteful and expensive.

That is not your only problem, however.

People costs will kill your margin

The people cost of running and supporting your migrated application will be too large a slice of your subscription revenue.

Remember, your ISV has great skills in building applications, not running them.

This is an inconvenient truth, as operations expertise will be a major contributor to your success with SaaS.

Even with all these problems, your biggest problem is still to come…

80% of your on-premise code is irrelevant

To adapt your on-premise application you must migrate, run and support 80% of your legacy code; code that has no place in your SaaS solution.

You do not need the frameworks, low-level functions and common features. You should use standard services for security, reporting, billing, user management and so on.

The only code you should write for your SaaS solution is for your specific domain. All the rest is a commodity where you should use external services.

Standard SaaS services are easier to setup, use and support than migrating your legacy code. The pay-as-you-go model is also a better match to your future SaaS revenue stream.

Migrating your existing application from on-premise to SaaS might seem at first to be a good idea.

Do not be misled, however, by managed hosting providers who try to make this sound like a good idea.

The more you think about, the clearer it becomes it is not a good idea.

Migrate your domain skills, not your legacy code

If you start down the migration road you soon find you are in a dead-end. You need to take your domain expertise forward, not your legacy on-premise code.

You should build your SaaS application with the latest tools, using external services for all common processes. Then you can focus on creating the best possible experience in your vertical niche.

Do not waste your time on legacy code and the 80% “stuff” you had to do in the past.

SaaS is a unique opportunity to leave the past behind.

Grab this opportunity in both hands and dedicate yourself to your domain. You have the chance to create a SaaS solution to will surprise and delight your customers.

Coming Up…

In part three of this article I will look at the next layer up in PaaS market: cloud computing. This is where it starts to get interesting for ISVs developing SaaS applications…

Do you agree that do-it-yourself is a hopeless choice for SaaS ISVs? If you decided to go the managed hosting route what have been your experiences? Are you trying to migrate your on-premise application to SaaS? If so, what problems have you run into? Given what you now know, would you migrate given a second chance?

Image: Independent analyst Phil Wainewright has a useful 5-layer model to help ISVs distinguish between the different types of PaaS vendors, and to select the right level of technology for their needs.

As an ISV moving to PaaS, you need to understand what choices are available to pick the right one. The Cloud Computing, Saas and PaaS market map is a good high-level view, but does not go into enough detail. To understand PaaS vendor positioning we need something more.

Phil Wainewright has a good five-layer PaaS model on the Software as Services blog that is more helpful. Phil splits the PaaS market into the following five layers:

1. Do-it-yourself. You build your applications with whatever tools and architecture you want. You select, buy and run the hardware to support your SaaS solution.
2. Managed hosting. You have full control of the software, but you leave the hardware to a specialist hosting provider. They make some of the hardware decisions, but you are still responsible for most of the technical decisions.
3. Cloud computing. Utility providers transform compute and storage into abstract services that you use and pay for on-demand. An abstraction layer hides the hardware details so your SaaS solution can use simple APIs.
4. Cloud IDEs. These vendors say you should develop web applications in the same environment you will deploy them. Professional developers use cloud IDEs to design, code, test, deploy, support and maintain SaaS solutions. They bring the SaaS pay-as-you-go model to the complete development lifecycle.
5. Cloud application builders. These go further and focus on specific classes of application with comprehensive frameworks of standard functionality. The cloud application builders are intended more for power users than professional developers.

I think that Phil’s five-layer model is a good basis for understanding the PaaS market and its vendors. I will use these layer names on PaaS Talk.

Coming up…

Phil also asked readers which of the five layers they would prefer to use to build SaaS solutions. In part two of this article I look at how the results match the needs of European ISVs building SaaS solutions for their vertical niche.

What do you think about these five PaaS layers? Is this a good way to classify PaaS vendors? Please share your views in the comments…