PaaS (Platform-as-a-Service) Comparison

More than 80% of large organizations are actively evaluating enterprise Platform as a Service (PaaS) and conducting a PaaS comparison for development in public, private, and hybrid clouds.* As a foundational software layer and an application run-time environment, enterprise PaaS removes the complexities of building and delivering applications and enable organizations to turn ideas into innovations faster.

Conducting a PaaS comparison among vendors is essential for procurement, yet little guidance is available on the decision workflow. The following guidelines can help organizations that are looking at PaaS to find the best solution.

1. Research the Market: A handful of vendors have emerged as leaders in the enterprise PaaS space. According to Gartner, more than 85% of enterprise apps are written in .NET and Java. For .NET, enterprises typically only research Apprenda. For Java, organizations usually investigate three vendor products:

As part of this process, enterprises invite vendors to demo their products and form contacts that can help with ongoing questions as the organization moves forward.

2. Formulate Technology and Business Drivers: After researching the market, organizations need to determine the business needs that drive the enterprise PaaS initiative. An enterprise PaaS buyers guide is available to help establish the cost-benefit analysis of enterprise PaaS. Once the organization reviews the buyers guide, it should form a cloud-focused team that can collect and define the company’s technology criteria.


3. Run a Preliminary Test of Enterprise PaaS:
In parallel with efforts to define the business requirements and evaluation criteria, organizations need to begin trials of enterprise PaaS platforms to gain a high-level understanding of the solution. A full Proof of Concept (POC) is needed to properly assess the technology, but an initial hands-on experience provides a valuable first impression.

4. Conduct a Proof of Concept (POC): It is essential that organizations run full-scale pilots of the PaaS software to make sure it actually meets technology requirements. This process ensures the product can be installed on premise and integrates with critical existing technologies such as identity management, databases, current apps, and operating system images.

The POC pilot should be confined to less than a month, including an installation of the product, and should entail the vendors coming on site to smooth the installation process. There also should be clear criteria for judging successful outcomes, such as pushing an app to the platform.

After the POC, some organizations solicit RFPs or scorecards. A purchasing decision is often done without formal RFPs or scorecards, but it is not advised to move forward without a POC since the evaluation criteria in RFPs and scorecards can be open to interpretation, while technology outcomes cannot. Enterprises should be sure to evaluate dependencies on APIs and also dependencies the enterprise PaaS has up and down the technology stack. Switching enterprise PaaS vendors may be near to impossible if there is a reliance on another essential technology by the vendor somewhere else in the stack.

5. Start Arranging Services and License Procurement: After a technology evaluation and PaaS comparison, the typical vendor procurement procedures should commence with the winner(s)—there are often two (rather than one) enterprise PaaS services. It is crucial to define goals when scoping the services on apps that will be on-boarded for a given time frame—e.g., 20 apps on the platform in the first six months—and when scoping the existing tech that the PaaS will integrate with—e.g., Active Directory.

The winning enterprise PaaSes should have a workflow that can guarantee success in migrating any number of applications to the platform within a timeline defined by the end-user. Thus, a successful PaaS comparison comes to a close with the selection and implementation of one or two enterprise PaaSes.

* http://www.prnewswire.com/news-releases/detecting-a-red-shift-in-enterprise-software-development-278652181.html