Will PaaS Cure All Developer Woes?

automation technology

With interest in platform as a service on the rise, what must developers do to avoid falling into old traps?

Continued from page 1

Danger of lock-in

Hewlett-Packard CEO Leo Apotheker recently cited PaaS as a direction HP will soon take. Initially, HP will offer tools supporting PaaS development.

However, think of the developer building code in a specific language and packaging it for deployment to a specific platform — for instance, an EAR (enterprise archive) or WAR (Web application archive) file for a J2EE (Java 2 Platform, Enterprise Edition) container. The platform (i.e., the J2EE container) provides a “contract” about how applications can use the facilities of the platforms (e.g., security, transactional integrity or management), and these facilities are made available at the time of deployment when the application “binds” to them, Purohit said.

For PaaS, the same type of contract is going to be required even if PaaS vendors offer language-agnostic platforms. That way, applications can bind to facilities in the platforms that are common to the applications (even if configured differently for the application).

However, with all the benefits of PaaS, are there any drawbacks? For instance, is lock-in a concern?

“There is a strong danger of lock-in with most PaaS offerings,” Che said. “To avoid lock-in, you must be able to write your app in the framework/language of your choice and deploy on the cloud of your choice. If you can only write to a proprietary API that is only available in one PaaS, you can never move your app somewhere else since those APIs don’t exist elsewhere. Furthermore, you can’t bring existing apps into that PaaS since they weren’t written for those proprietary APIs.”

“Microsoft provides partners and customers the choice and flexibility to leverage the infrastructure they already have in place so they can utilize their existing skills and extend their investments to the cloud,” Ketkar said. “As part of this, we’ve embraced support for open standards and other development environments as a platform principle. This includes support for Java, PHP, Ruby and Python, as well as the same standard protocols that advanced the Web, including HTTP, XML, REST and SOAP.”

“The level of lock-in will depend on the language/environment being run, the database hosting the data, etc.,” Labourey said. “When leveraging a Java PaaS storing its state in a well-known database, the lock-in is typically very weak as it is relatively easy to replicate a compatible environment in-house. However, a PaaS using its own language and storage mechanism (such as Salesforce.com’s own proprietary language and database) will generate a pretty extensive lock-in. But this is similar to a company using something like PowerBuilder for its developments.”

And eXo’s Mestrallet added, “The vendor locking risk is at the IaaS and SaaS layers. With PaaS, vendors try to attract developers.  Whatever the language they use to code, those developers work with open frameworks that PaaS vendors support. If we look at the Java PaaS market, all vendors offer a standard way to deploy Java applications (WARs), and unless the developer is using a dedicated API for storage or caching (which they do not have to in existing PAAS), the applications are portable from one PaaS to another.”

PAAS checklist

What’s important to keep in mind when developing for PaaS?

Kerpan offered a checklist or set of rules that every budding developer contemplating an application-development career or an entrenched one refreshing an existing application development career in the face of the cloud should adhere to:

  • There is no metal.
  • Nothing is where you are.
  • Asynchronous and event-oriented behaviour are everything for your application. API’s are everywhere.
  • Long-running transactions will be part of everything, not an exception.
  • Features and functions that appear across a range of devices (including desktops, kiosks, tablets and smartphones) are collectively THE user interface to your application, not different user interfaces.
  • Frameworks that abstract multiple PaaS platforms (which would be things like Spring will do and Rails will do) might be the place to focus effort.
  • Don’t give up your day job; it will take longer than you think.