Applications on Network Services

 
 
By Darryl K. Taft  |  Posted 2011-03-28 Email Print this article Print
 
 
 
 
 
 
 



Applications will be built on network services. This is already happening.

"The longest pole in the tent is the evolution of the mindset of enterprise IT and of ISVs," Kerpan said. " This is a generational thing and can't be hurried."

And users appear to be buying in. Charles Teague, CEO of Lose It!, maker of a top-selling iPhone weight-loss application, said, "The CloudBees PAAS makes it straightforward for Lose It! to run a high-volume, data-intense Website handling 15,000 reads per minute with very little operational overhead. Their technology and service has allowed us to focus on creating the best product we can."

And Microsoft, whose Windows Azure cloud-computing platform offers elements of IAAS, SAAS and PAAS, also has its appeal to users.

"For a very small investment, we can try a new project and see if it works, close it down tomorrow or ramp it up immediately," said Eugene Shustef, chief engineer of Global Document Outsources at Xerox. "The Windows Azure platform enables us to do that; cloud computing lowers the barrier to innovation."

Using Microsoft technology, Xerox built Xerox Cloud Print, a cloud-based printing service that allows users to route a printing job to any available public printer directly from their mobile devices. Now, when employees are traveling on business, they can do things like quickly printing a presentation for tomorrow's client meeting. By running Windows Azure and SQL Azure, developers were able to build Xerox Cloud Print in just four months, Xerox officials said.

"This is the big advantage to developers," MuleSoft's Mason said. "With PAAS, they can now spin up their newest applications in minutes without going through the usual rigmarole of installing database, application runtime and other third-party software, before writing a line of code. A PAAS also means that patches and upgrades are managed by the PAAS provider, freeing the developer to just think about one thing-their app."

Robin Purohit, vice president and general manager for software products at HP, explained: On one hand, it's the Holy Grail of application development-"just code away and the platform will automatically handle scalability, availability, provisioning, upgrades, monitoring, etc. Conversely, there is no free lunch, so developers who think they can just forget about the --ilities' in their design may be creating an even tougher-to-manage application than previously possible."

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."

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 behavior 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.
 

 




 
 
 
 
Darryl K. Taft covers the development tools and developer-related issues beat from his office in Baltimore. He has more than 10 years of experience in the business and is always looking for the next scoop. Taft is a member of the Association for Computing Machinery (ACM) and was named 'one of the most active middleware reporters in the world' by The Middleware Co. He also has his own card in the 'Who's Who in Enterprise Java' deck.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel