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: Buying CPU and services from cloud providers gives you less control over your costs. Work on the basis you’ll want to swap cloud providers in the future. Anyone up for some cloud arbitrage?

As an SaaS ISV you can’t build a data centre; CPU cycles must come from utility providers. Amazon’s EC2 cloud computing platform is the current market leader. Microsoft is coming soon; Google and IBM will likely follow.

Relying on one CPU service provider, no matter who it is, is a bad idea. There is a risk a future monopoly provider could lock you in. Running your SaaS applications is a major part of your running costs. If your CPU service provider can lock you there’s a good chance your costs will increase.

It’ll be difficult to pass cost increases on to customers; thereby squeezing your margins. There’s a risk you’ve a successful SaaS application, but one you can’t run profitably! If you allow your CPU utility to lock you in; the future profitability of your business may be in serious doubt.

Utility providers will never be 100% reliable

If your CPU utility is up and running, but your user cannot reach it across the network, then to them your application is down; the technical reason does not matter to them at all. The uptime of your CPU service provider can never fully compensate for everything that could go wrong. You need to incorporate this reality into your business model.

• Availability Does Matter. Early adopters might put up with beta downtime; the early majority will not. Exploit system availability as a competitive differentiator and build service portability into your core architecture.
• Unreliability is Guaranteed. CPU services come and go: networking issues, unplanned downtime, even squirrels! There is always something to go wrong, so expect the unexpected and do not rely on any one service always being available.
• Spread Your Workload. You cannot rely 100% on any one CPU utility. Spread your workload across two or more providers to increase stability and availability. You can better react to unexpected events; even to moving processing from one country to another to avoid unwarranted intrusions.

Build your negotiating power

You will always be a small fish in the big pond of utility customers. As you become more successful, and so need more capacity, you risk that your utility will put you under pricing pressure. You must build your negotiating power by being able to move workloads. If not, you risk losing your margins and a squeeze on your profits.

• Your Utilities Are Not Free. You want to control any ads that appear in your application; you do not want to have to display ads for who-knows-what from your utility providers. Plan to pay real cash for your CPU services. Effectively managing that cash cost will be a major part of your future business.
• Create a Believable Threat. As you become more dependent, some utilities may seek to increase your prices. Your only real threat is the ease of moving some or all of your workload with little or no extra effort.
• Protect Your Margins. Relying on a single utility risks having any profit sucked out of your business through predatory pricing. Plan from day one to be able to move; and show that you mean it by never allowing yourself to rely on a single CPU utility.

Exploit arbitrage opportunities

New utility players will introduce new business models to drive down costs. To take financial advantage of these market developments you must be able to shift your workload easily. Intelligently exploiting future price and service differentials between providers can be a major contributor to your success.

• Exploit New Players. While Amazon EC2 is the current leader, Microsoft, Google and others are coming soon. You can profit from these changes and drive down costs as new offers become available–but only if you can actually move some of your workload to those new players.
• Find Off-peak Tariffs. Vertical application demand varies a lot by hour and day. You can exploit this by running some of your workload at CPU utilities in different time zones. Utilities will create off-peak tariffs to keep the level of use high enough to justify their investment.
• Plan For Agile Sourcing. CPU services will become a significant and growing running expense of your SaaS business. Plan to be eventually able to move slices of your workload between your utilities in real time. Finding the right blend of price, performance and availability will be a core business skill for the future.

Build operating skills

It does not help to have a great SaaS application if you cannot run if profitably! Running on-premise products was not your problem–with SaaS it is. You must invest in building the new operating skills you will need to source services cost-effectively. You will then be able to exploit the utility market as it grows and develops.

• Build New Operating Skills. Running an application cost-effectively is different from developing it. You must invest time and money to build the operating excellence that you will need to run your application. There are tools that will help, but knowing what you are doing will make all the difference.
• Decouple Development and Operations. Your developers build the application to consume services; operations must be responsible for sourcing them from your utility providers. Be fanatical about keeping this clear separation of roles.
• Start as You Mean To Go On. Relying on only one CPU service during start-up and then hoping to add others when necessary will be expensive. It is also likely to fail–provider assumptions have already contaminated your application. Your only chance is to force yourself to work with at least two utilities from day one. It sounds like more work but this is an investment you must make to protect your future.

Having more than one CPU service provider sounds like a good idea, but how sensible is this in the real world?