Image: 27% voted for cloud computing in Phil Wainewright’s recent PaaS survey. This sounds like the easy option, but is everyone really clear on what they are letting themselves in for? SaaS is not going to be pretty for many ISVs.

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.

In part two I looked at layer one: do-it-yourself and layer two: managed-hosting. Neither is suitable for SaaS ISVs. In part three I move up to PaaS layer three: cloud computing. Might this be more suitable for ISVs building SaaS solutions?

Cloud computing was the most popular choice of Phil’s readers. 27% said they would prefer it to develop a SaaS application. I wonder how many of them realise that cloud computing, just like banking, relies on a simple confidence trick…

Hardware is a now an API

Cloud computing presents physical servers and storage as abstract services. You can now create a secure and reliable virtual data centre with a few simple API calls.

The market leaders have not yet revealed the size of their clouds. For the moment they just say their clouds are plenty large enough to meet whatever your needs might be.

This cannot be true, of course, because virtual resources must eventually map to finite physical hardware. We know that Google, Amazon, Microsoft, Sun, CA AppLogix (formerly 3Tera), Mosso, Joyent, Nirvanix and other providers have a lot of hardware, but it is not infinite.

The (unstated) limits are probably huge. However, there is always a risk the cloud cannot provide you with server or storage when you need them. Is the all-you-can-use confidence trick something you need to worry about, or is this more a theoretical than real problem?

Confidence tricks are not always bad

Banking could not exist without a confidence trick: that you can always get your money back when you want it. We know that this cannot be true. If too many savers want their money then no bank can honour every withdrawal.

We know what happens during a run on a bank. Even knowing this, we still accept the risk because banking is so useful to us.

The same risk and reward trade-off applies to cloud computing. We know resources are not infinite; but that they are infinite enough most of the time. As long, of course, as most users use reasonable levels of resources most of the time.

The benefits of cloud computing for SaaS ISVs more than outweigh the risk of a full cloud. You can safely ignore the cloud computing confidence trick, just as you ignore the confidence trick banking needs to survive.

Cloud computing beats managed-hosting hands-down

Cloud computing is a great hardware solution; far better that managed-hosting or do-it-yourself for SaaS ISVs. You only pay for what you need and you can easily scale as your SaaS business grows.

Your data is more secure that it would be on your own server, as the never-ending press coverage of lost and stolen data reminds us. The cloud computing provider takes care of the underlying hardware (which you never get to see or touch).

Even with these benefits, you need to cover the full application lifecycle, not just the deployment hardware. You have no time to set up test clouds, rolling-updates, active support, change control and so on.

Automation tools including RightScale and Scalr can help. But even so, this is not your core competence and you should stay well away.

The cloud is not as opaque as you might think

Providers prefer opaque clouds to better balance their workloads. Ideally it should not matter where your servers or storage are. Unfortunately, this utopia will not happen: national laws and jurisdictions from the real world have already intervened.

Data protection laws in Europe restrict how you can store and process customer’s data. As a result, the cloud is not as opaque as it might first seem. The cloud computing providers recognise this and have announced support for different jurisdictions.

Salesforce.com is adding data centres in Asia soon, with Europe to follow so customers can keep data and processing out of the US.

Amazon’s availability zones allow you to store your data in Europe today; server instances running in Europe will follow.

Coming up…

Cloud computing is too low-level for you to worry about. Focus on your domain; do not waste your time on (virtual) hardware (no matter how interesting this might be).

The next level up in the PaaS market model is level four: cloud IDEs. These build on the cloud computing platform, adding development and deployment tools. The idea is you can focus on your SaaS solution and not worry about anything else.

Next time on PaaS Talk I will take a first look at cloud IDEs. This is where PaaS starts to get really interesting; I look forward to seeing you in part four of this article.

What’s your view of cloud computing? Have you run into any problems separating test from production? How much time are you spending on operations? Are you using automation tools?

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…