Why PaaS Is The Future

The vast majority of Web applications will eventually run on platform-as-a-service, or PaaS. The shift will be slower than to infrastructure-as-a-service (IaaS) because finding the perfect PaaS fit will take effort, and there's significant loss of control over hardware and software. Many IT departments will resist. But it will happen, so to help you evaluate options and plan a migration strategy, we sent out a questionaire with more than 70 factors to consider to major PaaS providers. You can download a full set of responses at our InformationWeek PaaS comparison site.

The PaaS value proposition is simple: Bring your code, and we'll handle everything else for you -- Internet connectivity, power, hardware, operating system, software, monitoring, backup, restore, failover, scaling and more. IT can focus on writing code to solve business problems and leave the mechanics of infrastructure and operations to the vendor. In theory, you get a best-practices deployment, including security and business continuity, at a lower cost and better quality versus having your own staff do the work.

We say, "in theory" because these are still early days, and vendors provide so many different services -- with so many moving parts -- that it will take time to demonstrate stability to CIOs. However, we're convinced that PaaS is the future, and that companies that fail to consider it will be at a disadvantage.

The 7 Factors To Consider

A PaaS implementation requires two main elements: a platform and a service that runs the platform for you. For a PaaS vendor to be included in our comparison, it must both sell software or software-as-a-service for deploying Web applications and provide an infrastructure on which to run these applications. After all, if a vendor doesn't provide the underlying infrastructure in addition to the platform software, you're not getting the full value of PaaS because you lack "one throat to choke."

PaaS Comparison

Report Cover

Get This And All Our Reports

Comparing PaaS vendors is more difficult than comparing IaaS or SaaS vendors because there are so many disparate elements. We discuss evaluation strategies in depth in our full report. Here, we'll walk through the seven major elements to evaluate when choosing a PaaS provider.

>> Programming languages and frameworks: IT generally has a preferred programming language, and providers that don't support that language are rarely in the running. There is one exception: proprietary PaaS, where the customer is buying based on other factors and is willing to use whatever language is required. The best example is Salesforce.com's Force.com, which uses a proprietary language but offers the upside of a robust ecosystem that can give application developers a big head start compared with conventional application development platforms.

>> Databases: Generally, PaaS database server support is similar to programming language support -- buyers come to the table with a preference. However, most modern application development is done in such a way as to ease migration to a different database server. Several PaaS providers also support so-called "next-generation" databases, such as Xeround, that provide an interface identical to a widely used database, like MySQL, but are offered as a service. It's important to verify the database security features offered by PaaS vendors to ensure that they conform to your regulatory and security policy requirements.

>> Availability: After narrowing your list based on programming language and database support, the next defining criterion should be how comfortable you are ceding control over application uptime. To that end, we asked a number of questions around availability to understand what happens when servers and software fail. The service-level agreement is important, but SLAs almost never adequately reimburse a company for application downtime. The best IT can hope for from an SLA is that it costs the vendor enough revenue that the vendor shares some of your pain, and that it clearly defines vendor roles and responsibilities about the services it's responsible for.

>> Security: Security and regulatory compliance are critical when selecting any infrastructure vendor, and PaaS is no different. Keep in mind that, for the majority of providers, multitenancy is a way of life -- PaaS vendors drive down costs and maintain high availability by spreading applications and data across a large number of shared servers. This makes PaaS most appropriate for applications and information that fall outside of regulatory oversight, although many vendors have ways to address common regulated scenarios such as storing credit cards.

3 PaaS Models

>> Services: Many PaaS vendors provide extra services through third-party add-ons. Examples include code repository integration (to launch applications from source code repository branches), caching services (to save database query results to speed application performance), logging services (to consolidate logs across all application copies) and payment services (to outsource acceptance, processing and storage of credit card numbers in a PCI-compliant environment). If an add-on is important, ask how the PaaS vendor handles support. No one wants to navigate interactions between the PaaS provider and services vendor.

>> Customer care: PaaS vendors build layers between and around various services (such as application-to-database transactions) that necessitate a much closer relationship between developer and vendor than with other hosting options. Verify that availability is as claimed. Do experts respond to questions on forums in a timely fashion? Do the people staffing the phones have both a clue and the power to help?

>> Price: While cost is always important, select based on the above criteria and whether the PaaS model is more cost effective than other options such as in-house or IaaS. Include migration in your calculation if you already have an existing deployment. There's rarely much difference in price among comparable PaaS services. Get the best fit for language, database and add-on support, as well as security and availability.

Also note that it's difficult to look at a PaaS price menu and translate that into your actual costs. If you have highly optimized application code, you might pay significantly less than someone with inefficient code. Similarly, the way your app runs on one provider may require that you purchase more units of service than on another, with no way to know before deploying the application. Fortunately, most PaaS vendors offer free trials. Take them up on it. Finally, ensure that you can port your application to a different provider in the event of price increases or service outages.