Image: What started as an internal list of cloud computing links by Qrimp’s founder Randall Minter resulted in a portal that’s not sure exactly what it wants to be: an industry resource or a simple technology demo.

I recently came across the Cloud Computing Portal. While the look and feel needs some work, the goal is to become a central source of information on cloud computing. The model is to get user-generated content from the community.

Unlike Wikipedia, it is not obvious at first sight who is behind this portal. The only clue is the URL cloudcomputing.qrimp.com. This tells us that the portal is being hosted by Qrimp, a cloud application builder.

Qrimp is a pre-funding start-up. They introduce their product on their Web site as follows:

Qrimp is a web database without limits. Simple to get started. Easy to use.
Robust and feature rich. Build your web database to collaborate with your team in 5 minutes. The flexible Qrimp Platform grows with you and adapts to your information management requirements. No programming is required, but we have a rich API and AJAX capabilities so you aren’t restricted like with other web databases. Build complex forms, drill downs, and workflows using combinations of data from multiple tables.

Automatically generate rich interfaces for one-to-many (drop downs), many-to-many (checkboxes), self-references (tree views), or dates (calendar). JavaScript input validation is generated automatically for 24 data types including phone numbers, email addresses, zip codes, currency, websites, calculated fields and more. Create mashups with your data and data from other providers.

The initial content of the Cloud Computing Portal seems to have been come from John Willis’ Cloud Vendors A to Z. There does not seem to be much extra content at the time of writing. It is still early days, so there is still plenty of time for this new portal to gain traction.

Let’s see how it develops.

ps: I am not sure whether the Cloud Computing Portal is an application developed by someone using Qrimp, or whether it is an offering from Qrimp themselves. If you know more about the background to this portal then please let us know in the comments. Thanks.

Update. July 6th, 2008: Tara Holfeld from Qrimp got in touch to let me know that the Cloud Computing Portal was created by Qrimp’s founder Randall Minter. It started off as an internal list of links and videos around distributed data storage, and is now being shared with the community. Qrimp will add an About page to the portal to clarify the origins of the site. Thanks to Tara for the prompt update.

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…

Image: Peter Laird, former Chief Architect on the BEA SaaS Platform initiative came up with a useful marker map to help navigate the “as a Service” acronym soup.

Peter Laird, formerly from BEA Systems has been kind enough to publish a market map that, while not claiming to be comprehensive, is a good place to start.

Peter helps us to understand cloud computing, SaaS, PaaS and others by splitting the market into four main areas:

• Cloud Computing. Turning the data centre into a utility service that provides virtual computing and storage services. You buy processing and storage as you need it. The hardware is of no concern; it appears when you need it.
• Software as a Service. Delivering applications as a subscription service over the Internet. The ISV that developed the SaaS application runs it, buying deployment infrastructure as a service from utility providers.
• Platform as a Service. PaaS offers an integrated environment to design, develop, test, deploy and support custom applications. Following the pay-as-you-go model of SaaS, PaaS does not need large up-front investments, and so is a good choice for ISVs.
• Core Cloud Services. Common features such as billing, security and storage all ISVs need to complete their offer. In the past ISVs would have to build such common features within their on-premise applications. PaaS providers bundle them into a complete offer so ISVs do not have to worry about them.

Image: (View full-size)

Peter’s map can only give a first impression of the market structure and the hundreds of existing players. See SaaS Showplace created by Jeff Kaplan from THINKStrategies if you want more details of SaaS vendors and their products. SaaS Showplace currently lists 3,000 SaaS solutions from 650 companies, split into 80 segments.

Image: On-premise ISVs don’t really need to be concerned with what their users are doing. This is not the case for SaaS, where the service provider needs to meet “know your customer” and other legal requirements.

ISVs must consider their jurisdiction, as well as that of their customers, suppliers, processing utilities and data storage providers. Not knowing enough about your customers can be expensive, and could even land you in jail. PaaS providers can add value to European ISVs by abstracting these jurisdiction issues and keeping track of future legal changes.

In Is jetting to Cuba this summer a bad idea for European SaaS ISVs? I reported on how the US Treasury’s Office of Foreign Asset Control (OFAC) can impact non-US companies. A European travel agent appeared on the OFAC blacklist for selling Cuban holidays.

The travel agent’s only US assets were the DNS database registrations for their .com domain names. The domain register froze the .co domains following a call from OFAC; the travel agent’s websites disappeared from the Internet.

New US rules intended to prevent identify theft came into force on January 1st 2008. These new rules are part of the US Fair and Accurate Credit Transactions Act (FACT). The FACT rules cover all companies that keep consumer accounts with personally identifiable information. Companies covered by the new rules must comply by November 1st 2008.

Companies will have to check customers against the FACT list of suspected identity-theft criminals. They must also watch customer’s transactions and report anything suspicious (so-called “red flags”). There are threats of fines and even jail for breaking the reporting rules.

FACT does not just apply to banks and financial institutions. As online service providers, SaaS ISVs will also have to worry about these rules. It will take time, and you face complex questions about jurisdictions.

Welcome to law enforcement

As a SaaS ISV you provide services and have customer accounts involving money and online identity. It is likely you will also have to meet Know Your Customer rules. What’s more, you must identify all suspicious transactions and report these to the proper authorities.

The US is not the only country moving towards privatising law enforcement in this way. The UK also has strict Know Your Customer laws intended to prevent identity theft fraud, money laundering and terrorist financing. Even China now has similar rules.

Many of these laws overlap and could even be in direct conflict. It will be many years before consistent rules apply between the US and EU. Meanwhile you must stay up-to-date with the latest rules in each jurisdiction.

It is not just where you are, but where your customers and suppliers are as well. You have to get it right as the penalties are severe, and ignorance of the law is no defence. Hobby developers might not care about these rules, but business ISVs must.

Jurisdiction-abstraction as a service?

Mapping these new rules to your utility computing and PaaS providers will be a complex, and lasting, problem. However, it is a problem common to all ISVs; it is not different for each vertical niche.

It must be possible to find a common solution. PaaS providers are therefore in an ideal position to provide jurisdiction abstraction features on their platform.

I look forward to seeing how PaaS providers will solve this problem. It is not so much a technical issue, but is critical for SaaS in general and PaaS in particular. Those that can abstract away US, EU and other jurisdiction problems will have a real benefit to talk about.

Image: Here in Germany you do not fall asleep on the Autobahn if you plan to survive for much longer. Ignoring SaaS is just as high-risk. German ISVs must start working on their SaaS solutions while they still have the chance.

A recent survey of 5,200 small to medium-sized German ISVs caught my attention last week. A report by ComputerWoche summarised the findings of a SoftGuide survey on SaaS. SoftGuide is a software and IT services buyer’s guide for the German-speaking market.

• 5% of ISVs do not have a SaaS offer, but plan to launch a SaaS solution soon.
• 49% of ISVs do not have a SaaS offer, and have no plans to add one in the coming year.
• 21% of ISVs already offer a SaaS solution.
• Of this 21%, around half are happy with the way their SaaS sales are growing.

Uwe Annuss, SoftGuide’s Managing Director:

… Most of the companies listed in SoftGuide are small and medium-sized ISVs. The results of our survey show that, for these ISVs, the time for SaaS has not yet arrived.

I find it worrying that so many small to medium-sized German ISVs are ignoring SaaS. It is exactly these ISVs that are at the most risk.

Here in Germany I often hear the view business will carry on as before. There is no urgent need to worry about changing for the future. That attitude will cost many ISV owners their business.

Ignoring SaaS is high-risk — like falling asleep when driving on a German Autobahn, which I also do not recommend.

German ISVs: Wake-up and take control of the (SaaS) wheel!

Start work on your SaaS solution today. Use Platform as a Service to keep costs low. Plan to deploy your first SaaS iteration as quickly as possible to gain visibility and experience. Your future competitors have already started.

Image: Developers have not really given much thought to whether they can trust a locally installed compiler. Can you take the same approach with a PaaS provider, or will you need to follow a “trust, but verify” approach?

We Europeans are complex when it comes to privacy.

At one extreme the UK has probably the world’s highest density of security cameras. At the other, tax returns in Norway have been public information since 1863.

Many share intimate details on Facebook and other social networks. When it comes to business data, however, they expect much more.

Spies are everywhere

Your SaaS solution moves your customers’ data into the cloud, so expect fear and doubt about loss of control. Experience shows that sometimes these fears are real, in others (perhaps) not:

• CIA Caught Spying on Global Banking Network. A secret order forced SWIFT to grant US officials access to copies of bank transfers mirrored to the US. There was uproar in Europe when the New York Times revealed the spying action. A new SWIFT data centre in Zurich means in future only transactions to or from US banks cross US borders.

• French Government Bans Unsecure BlackBerry. The French government banned officials from using the BlackBerry mobile service. They claimed third parties could intercept messages routed through servers in the US and UK. RIM was quick to reassure subscribers there was no basis to French claims; still, doubts remain about Blackberry security.

Create your SaaS security and privacy story with such examples in mind; your customers will have read about them. Reassure them about when and where you store and use their data. Pay particular attention to anywhere their data could be “in the clear”. Also, remember any third-party services you use (direct or indirectly)–they are a potential source of leaks.

Secrets and lies

US legal threats forced SWIFT to hide the spying from their member banks. This is not something unique to the US, however. Many governments try to keep their data mining secret; although these powers sadly end-up used for other purposes.

SWIFT had enough power to demand limited audit controls. How will you react if (or when) a government demands secret access to your SaaS solution? Can you limit access to the data of a single customer, or is the door open to them all?

Who can you believe?

You must trust many providers, most of which your Platform as a Service provider hides from you. That, of course, is the idea behind PaaS. However, ask your PaaS provider detailed questions about security and privacy. Ask them how they will react if they are ever in the same position as SWIFT…

You might never know whether your PaaS provider (and in turn their providers) is telling you the truth. Even so, you must create an end-to-end security and privacy story that is believable enough to reassure customers.

Remember: S-is-for-Service not S-is-for-Spying!

Image: Location independence is a great architectural concept but legal reality for PaaS is radically different You’ll need to keep track of what’s where in the real world if you want to stay out of trouble.

While Cuba is a popular holiday spot for Europeans, a 46-year old trade ban puts Cuba off-limits to Americans. Strictly enforced laws prevent US companies from doing direct or indirect business with Cuba.

The US trade ban became a big problem for travel agent Tour & Marketing International. Although based in Spain, the US Treasury’s Office of Foreign Asset Control (OFAC) added them to a blacklist. Why? For selling Cuban holidays to Europeans (US citizens cannot travel to Cuba).

As a result, their US-based domain register blocked about 80 of their .com domains for Cuba-related websites. The domain register gave no notice and refused to transfer the domains (they must freeze all US-based assets).

Are you breaking US law?

You might not have customers in Cuba, but what about all the subscribers of your SaaS solution:

• Do you know who and where they are?
• Are you sure your information is accurate?
• Could you prove it in a court of law?
• How will you track future changes?

Your PaaS provider could get a call from OFAC to suspend your SaaS application. You get no notice and appealing is difficult. This is not going to be good for your SLA…

Is storing data in Europe enough?

Metadata is also important, not just your application and data. For example, Amazon’s S3 storage service allows you to store your data in Europe, but what about your account data? If it is in the USA, Amazon could get a call from OFAC. While your European-data is still there, you might not be able to use it.

I am not sure that all ISVs building their business on Amazon S3 have fully considered this issue.

Wait for the law to catch-up?

It is not just the US and Cuba; cloud computing and cross-border trade disputes are an accident waiting to happen. The law will take years to catch up with cloud computing.

Until then, you need to know where your PaaS provider is storing your applications, data and metadata.

What can PaaS providers do today?

PaaS providers must make their customers aware of these potential problems. They will not convince European ISVs with an easy “Everything’s in the cloud; do not worry”; PaaS providers must be transparent and make it clear exactly where they are storing applications and data.

Splitting workloads by region could be a good differentiator. This might also open the market to non-US PaaS and utility-computing providers.

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?

Image: ISVs have long used abstraction to isolate applications from technical implementation details. SaaS is based on services that can, and will, disappear just when you need them. Fault tolerance is no longer nice-to-have.

Whether using frameworks, cross-platform toolkits or even application generators, abstraction has worked well for the different combinations of OS, database, networking and user interfaces that confront on-premise developers.

As an SaaS ISV you only have one platform–what technology doubts could you possibly have to worry about?

For SaaS it’s services, all the way down…

SaaS applications are large portfolios of services that extend over the complete hardware and software stacks, including:

• Utility computing services for hardware, data storage and networking
• Common system features, such as billing, subscription management, analytics and service management
• Common application features, including charting, mapping, search and many others

Your customers do not count your technology as a benefit to them. They will not accept premium pricing. As a result, you will only ever have time and money to invest in building services that are core features for your vertical niche.

It makes financial sense to buy-in most of your services; keeping your running costs strictly under control. Your service portfolio can, and should, change in the future as you look for opportunities to swap to something cheaper.

As an SaaS ISV you now have total independence to choose the services you need for your application–where are the technical doubt and implementation differences you need to hide with abstraction?

My service was there a minute ago!

Technical doubt for on-premise products could usually by fully resolved at build-time. Once the customer had installed the product the IT setup changed slowly, if at all.

When a 3rd party supplier disappeared, or dropped support for their product, there was no short or medium term impact on any of the installed applications. These continued to run as before–often for many years. There was enough time to consider replacements (and you abstracted the interfaces anyway).

The services world of SaaS is different–the services you carefully selected can (and will) disappear at run-time! This could simply be from a temporary network outage. More seriously, a provider might close and stop offering their (probably in perpetual-beta) service with little or no warning.

Service outages can impact all of your SaaS customers–and quickly. The buffer that exists in the on-premise world between off-line development and build, and on-line deployment has disappeared.

If a service is unavailable you need to have a plan B in place. You cannot wait and develop a replacement solution in days, weeks or perhaps even months. Your customers have already noticed and they are waiting…

Without your having had any choice in the matter, SaaS throws you head first into the real-time world. You have to build a reliable SaaS application based on a large portfolio of (assumed to be) unreliable services. This is not easy.

Fault tolerance–here comes SaaS, ready or not

You SaaS application must degrade gracefully as services come and go. No matter what happens, you must always deliver the best possible customer experience. How it degrades depends on the missing service or services. An unavailable charting or mapping service clearly has a different impact than a missing database or networking service.

Your SaaS application must handle missing and unavailable services well, and tell your customers what is going on. It cannot just fail because a service is unavailable–even if it is something critical such as your login or security service.

All SaaS outages have an all-too real potential to blow up into a PR disaster. Bad press is not healthy for your reputation or keeping customer trust–both of which are essential for success in the SaaS market.

This time your main technical doubt is not the easy API differences between implementations–the main issue is the concern that any of your chosen services will actually be available from one transaction to the next.

Hiding behind abstraction will not work. You need a more flexible approach that handles unreliable services and guarantees an excellent user experience–no matter what service fails or disappears.

Coming up…

Are you forced to develop this supporting service infrastructure yourself, or are there standard solutions you can use? That is what I will look at in my next post on PaaS Talk: Might Amazon EC2 cloud platform squeeze the profits from SaaS apps?.

Image: Supporting multiple platforms has always been an issue for ISVs. At first sight SaaS washes this problem away once and for all. If only that were true.

SaaS is a dream come true for ISV development managers; finally there is only one platform to worry about. The long years of cross-platform development are over.

The bad old days are over where every customer had a different combination of hardware and software. No more support calls asking you to confirm in writing that you support version x.y of product z.

In the new SaaS world there is only one platform–the one you choose to run your hosted application. Even better, you have total control of your platform. What’s more, not just making the first choice, but for all future upgrades and improvements as well. Luxury, pure luxury!

So what if you choose to develop your application in Erlang, Groovy or even Wasabi? This time your customers don’t care at all about your technology choice. This is new and cool…

So, having got all the good points out of the way, there is still an issue to resolve. What platform do you choose to build and deploy your new SaaS application? Unfortunately it is at this point that platform issues start to intrude on the SaaS clean sheet.

Platforms are not what they used to be

In the on-premise world your customers demanded your application fit seamlessly into their existing IT world. This was a benefit of your application and so rightly flowed into the ROI calculation when evaluating your product.

That all changes with SaaS. Everything to do with your technology platform is now solely part of your internal cost base. No matter how good your technology might be, it will never again be part of the ROI calculation. Platform independence and ease of integration have now disappeared from your benefits list.

Your customers do not care about your technology–it’s your problem now. All they care about is the delivery of the service they have subscribed to. The bits and bytes of how you build it do not interest them. That is one of the attractions of SaaS. This is new and radically changes the ISV business model.

It helps to know the (SaaS) rules

Customers evaluating SaaS applications look at the core features where they see a real value. The other (80%?) of your application is just supporting stuff. While they recognise it, it is not something that they will pay extra to have.

This focus on core features opens the door to new players entering your vertical niche. The barriers to entry drop dramatically if new entrants only have to offer the 10-20% of features customers place a high value on. They can ignore the rest and so be quicker to market.

As with so many other industries, SaaS is driving an unbundling of business application features. Customers will only subscribe to features where there is a clear value proposition. Cross-subsidizing technical frameworks and nice-to-have features will be much more difficult to justify and sell. This unbundling is new and means ISVs must be much more focused on the saleability of each individual feature.

It is the early 1980s again

While SaaS is new, selecting the right platform and tools to build your SaaS application raises issues that would be familiar to an ISV from 30 years ago.

Now, as then, it is a young market with new ideas, technologies, tools and providers. Who will survive? What technologies will become an industry standard? Nobody knows, and that makes planning difficult.

Your customers do not care about your technology. However, If you make the wrong SaaS technology or provider decision then the risk is much higher that someone will notice–and quickly. And once one user notices, it will not be long before everyone knows. This is new for ISVs where there has always been a disconnect between off-line development and the production applications running on-premise.

While SaaS makes it easier to start using your application, it also makes it easier to move somewhere else. It is therefore critical to get your technology decisions right–each and every time.

Investing in technology might not be a good idea

SaaS changes the rules on deciding how to invest in development. Your customers only care about the features that they can see and use. Anything that happens behind the scenes does not contribute to the value of your application as seen by your customers. This raises the question of how much you can and should invest in these hidden features.

For on-premise it made good sense to invest to build a flexible platform to support the customer-specific IT variants. That way of thinking is no longer correct and can lead to financial disaster in the new world of SaaS.

Over investing in technology layers and frameworks just serve to increase your base running costs. Your customers do not care. They will not reward your cool technology with premium prices. Pushing your cost base up you makes your life more difficult and squeezes your margins.

When planning your SaaS technology strategy you must focus your development investments on core application features. Resist all temptation to start building supporting “stuff”. This is new and marks a big change in how we need to think. This will take much getting used to by ISV development managers; even more so by ISV developers.

Will abstraction save the day again?

The ISV’s traditional solution to technology doubt is abstraction. Data abstraction layers handled the doubts about which database would win in the SQL wars. GUI abstraction layers came into play when ISVs first needed to support Windows, Mac, OS/2 and X-Windows.

Does it make sense to take the same approach again and create an abstraction layer between the SaaS application and the underlying platform?

The answer is–it depends! And that is what I will look at in the next post on PaaS Talk: Why hiding behind abstraction is not enough for SaaS applications.