Budget, internal resources pivotal in biz PaaS choice

Companies shouldn't commit to platform-as-a-service due to existing vendor relationships but on whether service will serve needs, having right people to maximize usage and budget to deploy, urge analysts.
Written by Jamie Yap, Contributor

The platform-as-a-service (PaaS) arena is still evolving and in a flux, so companies looking to migrate their software to these platforms need to be mindful of their business requirements, resources and ability to integrate with existing IT infrastructure, analysts advise.

Robert McNeill, research vice president of cloud services and IT outsourcing at HfS Research, attributed the ongoing flux in the PaaS space to "[service] provider innovation". He said apart from pureplay PaaS providers, other vendors such as IBM, Oracle and Red Hat have also recently entered the market to facilitate cloud-based delivery.

Additionally, infrastructure-as-a-service (IaaS) providers such as Amazon Web Services are also adding PaaS functionalities, while software-as-a-service (SaaS) vendors such as Salesforce.com are moving down the stack to provide toolkits for app development via its Force.com offering, he noted.

Steve Hodgkinson, Asia-Pacific research director of IT at Ovum, added that these new offerings bring with them complexities for enterprise customers.

He explained that it is a bigger step up for enterprises to adopt PaaS compared to the other public cloud offerings such as IaaS and SaaS, because IT departments will need to make a strategic commitment to the chosen platform based on factors such as enterprise architecture, application integration requirements, and development language skills.

Make strategic evaluations
Given the considerable confusion surrounding PaaS for enterprise customers currently, Dane Anderson, vice president, research director and region manager at Forrester Research, urged them to be "very diligent" before committing to any platform.

According to him, there are two common mistakes companies often make in picking their PaaS offering--making the decision without proper evaluation, and being led by an existing supplier to commit to its offering though the vendor's strength is in a different area.

Hodgkinson agreed, noting that a company's decision to adopt PaaS is often based on leveraging existing investments and knowledge accumulated from the use of IaaS and SaaS products. For example, customers that are using Salesforce.com's CRM application will likely adopt Force.com as their platform of choice as it is a "natural evolution" of their relationship with the vendor, he said.

However, the Ovum analyst said companies should avoid basing their decisions on vendor relationships but make the decision on integration requirements with their existing on-premise apps as well as their IT departments' skillsets.

Companies should also undergo rigorous cost modeling in order to estimate the costs of the increasing commitment to the PaaS service based on a range of scenarios, he said.

"It is a mistake not to consider the wider aspect of contracts, service level agreements (SLAs), a pre-nuptial agreement on data, and a tested Plan B--to protect the organization against unintended lock-in to the PaaS provider," Hodgkinson pointed out.

McNeill also advised companies not to jump on the PaaS bandwagon because of market hype but assess why they need these offerings and whether they can afford to deploy it.

"Have companies assessed the economics of developing and delivering applications via the cloud and evaluated the risk concerns and tradeoffs?" he questioned, adding that vendors' assertions of their products' capabilities need to be taken with a grain of salt.

To mitigate the unknown, he suggested companies can get their in-house developers to play with these offerings within a sandbox environment to get their feedback.

"Critical issues [to consider] include how much data goes back and forth from [the PaaS offering] to on-premise systems as this can substantially drive the cost of the service," he cautioned.

McNeill also called on organizations to look at the development languages supported on these platforms, such as Java, Ruby, PHP or other proprietary alternatives.

This is an important factor in the long run as companies will need access to employees with the right skills to develop apps and maintain their operations, which would then have an impact on their overall business flexibility and costs, he added.

Editorial standards