Platform-as-a-service will become standard for Web applications. It's time to evaluate your options and plan a migration strategy.
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 ourInformationWeek 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.
Ollie>> We agree, at O4BO.COM we have assembled a single subscription offering that includes PaaS (Rapid Application Development, Infrastructure as a Service, Service Oriented Architecture, Context Aware Rules Engine, Enterprise Service Bus (combined to create an Integration Platform aka iPaaS, along with a suite of Open Source Software as a Service Applications.
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."Ollie>> We agree and we add iPaaS for even better value.
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.Ollie>> Observing this we offer options and will expand those options so you are NOT locked in to any proprietary elements.
>> 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.Ollie>> As part of our Infrastructure as a Service on the IBM SmartCloud, we have images for all the major databases and have minimized the effort needed to choose.
>> 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.Ollie>> We agree and which was a key factor in our choice of IBM SmartCoud.
>> 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.Ollie>> We agree and we have chosen Corent Multi Tenant Server for our true multi tenancy and offer the choice of storage model between shared everything separate schemas and even separate encrypted databases.
>> 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?Ollie>> we have built a strong partner channel to provide a 7x24 coverage from the Ukraine, to the US to Australia and China and of course Hong Kong and the Philippines where we are located
>> 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. Ollie>> our SaaS is open source and we pass that savings along to our subscribers and offer bundles that further reduce costs.
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.Ollie>> Another thing we can do for ISVs is to take your single tenant licensed and installed software and convert it to true Multi-Tenancy, and then integrate it with iPaaS to offer an even richer solution to your customers at a small fraction of the cost of doing it yourself.
Ollie>> We would add one more factor. While most PaaS vendors do NOT offer portability, we do. We based our entire stack on Open Source and Portability, with only our Context Aware Rules Engine as our proprietary IP, everything else is portable and if you so choose we can deploy that stack on your own Cloud image so you can leave at any time if you so choose...the ultimate in portability.